Task 3.4: Deploy code by using AWS Continuous Integration and Continuous Delivery (CI/CD) services

• ABeforeInstall

  Incorrect

  BeforeInstall runs preinstall tasks, such as decrypting files or backing up the current version, before the new revision is in place.

• BValidateService

  Correct

  ValidateService is the last deployment lifecycle event and is used to verify that the deployment completed successfully.

• CAfterInstall

  Incorrect

  AfterInstall is for tasks such as configuring the application or changing file permissions. It runs before ApplicationStart, so the new version is not running yet.

• DApplicationStop

  Incorrect

  ApplicationStop runs even before the revision is downloaded, to stop the running application gracefully.

The scriptable hooks of an in-place EC2 deployment include, in order, ApplicationStop, BeforeInstall, AfterInstall, ApplicationStart and ValidateService; health checks belong in the last one.

• AAll at once

  Incorrect

  All at once deploys to every instance at the same time, and all instances are out of service for a short time.

• BRolling with additional batch

  Incorrect

  This keeps full capacity, but it updates the existing instances batch by batch, which can leave a partially completed rolling deployment when the new version fails.

• CBlue/green, with a CNAME swap to a cloned environment

  Incorrect

  Blue/green deploys to a separate environment and then swaps the environment URLs, which the requirement rules out.

• DImmutable

  Correct

  An immutable deployment launches a full set of new instances in a separate Auto Scaling group alongside the old ones. If it fails, rollback only terminates the new instances.

Immutable deployments never touch the running instances: new ones are added, checked, and either kept or terminated.

• AThe source action's BranchName set to a branch named release

  Incorrect

  BranchName defines a single branch, so every ordinary commit pushed to that branch would still start the pipeline.

• BA manual approval action in front of the production deploy stage

  Incorrect

  An approval action stops a running execution until someone approves or rejects it. The pipeline would still start for every commit.

• CA push trigger with a Git tag filter that includes v*

  Correct

  Push triggers can be filtered on Git tags, so the pipeline starts only when a matching tag is pushed.

• DA pull request trigger filtered on the main branch

  Incorrect

  Pull request triggers react to pull requests being opened, updated or closed, and they filter on branches and file paths, not tags.

V2 pipelines support trigger filters on branches, file paths and Git tags, which is how tags drive release pipelines.

• AA DeploymentPreference with Type set to Linear10PercentEvery10Minutes

  Incorrect

  A linear configuration shifts 10 percent every 10 minutes until all traffic has moved, which takes far longer than one ten-minute step.

• BA DeploymentPreference with Type set to Canary10Percent10Minutes

  Correct

  This canary configuration shifts 10 percent of traffic first and the remaining 90 percent ten minutes later.

• CDeploymentPreference Alarms that list the function's error alarm

  Correct

  CodeDeploy watches the listed CloudWatch alarms during the deployment and rolls back automatically if one of them is triggered.

• DA ProvisionedConcurrencyConfig for the live alias

  Incorrect

  Provisioned concurrency keeps execution environments initialized. It does not control how traffic moves between versions.

• ERemoval of AutoPublishAlias so that traffic goes straight to $LATEST

  Incorrect

  AWS SAM gradual deployments shift traffic on the alias that AutoPublishAlias creates and points at each new version, so removing it works against the requirement.

In AWS SAM, AutoPublishAlias plus DeploymentPreference (type, alarms, optional hooks) hands traffic shifting and rollback to CodeDeploy.

• ADeletionPolicy set to Retain

  Incorrect

  DeletionPolicy applies when a resource is deleted from the stack, for example when it is removed from the template. It does not apply to a resource that is replaced during an update.

• BTermination protection turned on for the stack

  Incorrect

  Termination protection only blocks deleting the stack. It does not keep a resource that an update replaces.

• CA stack policy that denies Update:Replace on the table

  Incorrect

  A stack policy prevents the replacement from happening at all, so the update the team wants could not go ahead.

• DUpdateReplacePolicy set to Retain

  Correct

  UpdateReplacePolicy keeps (or, in some cases, backs up) the existing physical resource when an update replaces it, so the old table stays in the account.

DeletionPolicy covers deletion from the stack; UpdateReplacePolicy covers replacement during an update. Changing TableName requires replacement.

• AAWS Amplify Hosting connected to the repository and its branches

  Correct

  Amplify Hosting provides a Git-based workflow with continuous deployment to a global CDN, and branches can map to environments.

• BAmazon S3 static website hosting with manual uploads

  Incorrect

  Manual uploads are not continuous deployment, and a website endpoint alone is not a global CDN.

• CAWS Elastic Beanstalk with a single-instance environment

  Incorrect

  Beanstalk runs application servers; it is not a Git-based CDN hosting workflow for static front ends.

• DAn Amazon EC2 instance running a web server, updated over SSH after each push

  Incorrect

  This needs manual server management and gives no automatic deployment on push.

Amplify Hosting gives front-end teams Git-based continuous deployment with per-branch environments.

• ARolling

  Incorrect

  Rolling updates existing instances batch by batch; it does not send a set share of traffic to new instances for a test period.

• BAll at once

  Incorrect

  All instances switch at the same time, with no canary period.

• CTraffic splitting

  Correct

  Traffic splitting sends a percentage of client traffic to new instances for an evaluation period before completing the deployment.

• DRolling with additional batch

  Incorrect

  This keeps full capacity during a rolling update but does not split traffic by percentage.

Elastic Beanstalk traffic splitting provides canary testing as part of a deployment.

• AThe SUPERSEDED execution mode

  Incorrect

  In SUPERSEDED mode, the default, a more recent execution can overtake an older one, which is the current problem.

• BThe PARALLEL execution mode

  Incorrect

  PARALLEL runs executions at the same time and independently, not one at a time in order.

• CA manual approval action at the start of each stage

  Incorrect

  Approvals pause executions for people; they do not change how executions are ordered.

• DThe QUEUED execution mode

  Correct

  In QUEUED mode, executions are processed one by one in the order they are queued; it requires a V2 pipeline.

CodePipeline execution modes control whether executions are superseded, queued or run in parallel.

• AA CodePipeline pipeline created by hand in the console

  Incorrect

  A hand-built pipeline must be edited by hand when new stages or stacks are added.

• BCDK Pipelines

  Correct

  CDK Pipelines are self-updating; when stages or stacks are added, the pipeline reconfigures itself to deploy them.

• CA cron job that runs cdk deploy on a build server every hour

  Incorrect

  A scheduled job deploys on a timer rather than on changes, and it lacks pipeline stages.

• DCloudFormation drift detection on the application stacks

  Incorrect

  Drift detection finds manual changes to deployed resources; it does not deploy anything.

CDK Pipelines keep the pipeline definition in code and update the pipeline as the app grows.

• ATurn off encryption for the artifact bucket

  Incorrect

  Removing encryption weakens security and is not the documented way to share artifacts across accounts.

• BCopy the artifacts into a bucket in account B with a script after each build

  Incorrect

  A copy step adds work outside the pipeline; the documented approach shares the artifacts through a key both accounts can use.

• CUse a customer managed KMS key that account B may use

  Correct

  Cross-account pipelines use a customer managed KMS key in place of the default key, with permissions for the other account to use it.

• DTurn on automatic rotation of the default key

  Incorrect

  Rotation does not change who may use the key.

For cross-account deployments, encrypt pipeline artifacts with a customer managed key that the target account is allowed to use.