Task 1.4: Implement deployment strategies for instance, container, and serverless environments.

• AAdd s3:GetObject on the revision bucket to the IAM service role that CodeDeploy uses for the deployment group

  Incorrect

  The revision is downloaded by the agent on the instance, with the credentials of the instance profile, not by the CodeDeploy service role.

• BAllow the new instance profile's role to read objects in the revision bucket and to decrypt with the customer managed KMS key

  Correct

  The instance profile gives the agent its permission to download the revision from Amazon S3, and an encrypted revision also needs access to the KMS key that encrypted it.

• CChange the deployment configuration from CodeDeployDefault.OneAtATime to CodeDeployDefault.AllAtOnce for the deployment group

  Incorrect

  A deployment configuration sets how many instances are updated at a time. It does not change what the instances may read.

• DReinstall the CodeDeploy agent through the user data of the new launch template and restart the agent service on each instance

  Incorrect

  The agent is already running, because it is writing the access denied errors. Its credentials come from the instance profile.

On EC2, the CodeDeploy agent uses the instance profile to talk to CodeDeploy and to fetch the revision. A new instance profile must carry the same S3 access and, for SSE-KMS objects, permission to use the KMS key.

• AType Linear10PercentEvery10Minutes, the error alarm in Alarms, and the smoke test function as the PreTraffic hook

  Incorrect

  A linear type shifts traffic in equal steps of 10% every 10 minutes, so it does not move all traffic after the first 10 minutes.

• BType Canary10Percent10Minutes, the error alarm in Alarms, and the smoke test function as the PostTraffic hook

  Incorrect

  A PostTraffic hook runs after traffic shifting completes, so the smoke test would not gate the first shift.

• CType AllAtOnce, the error alarm in Alarms, and the smoke test function as the PreTraffic hook

  Incorrect

  AllAtOnce moves all traffic at once, so there is no 10% stage of 10 minutes.

• DType Canary10Percent10Minutes, the error alarm in Alarms, and the smoke test function as the PreTraffic hook

  Correct

  This canary type shifts 10% and the rest 10 minutes later, PreTraffic runs before shifting starts, and an alarm in Alarms rolls the deployment back.

SAM uses CodeDeploy for gradual Lambda deployments. The type picks the shape of the shift (canary, linear or all at once), the hooks run checks before and after shifting, and alarms trigger an automatic rollback.

• AEnable the deployment circuit breaker with the rollback option on the service

  Correct

  The circuit breaker counts tasks that fail to reach RUNNING, marks the deployment as failed at its threshold, and with rollback returns to the most recent COMPLETED deployment.

• BSet minimumHealthyPercent to 100 and maximumPercent to 200 in the service's deployment configuration

  Incorrect

  These values set how many tasks must stay running and may run during a rolling deployment. They neither detect a failed deployment nor roll it back.

• CEnable Container Insights and create an alarm on RunningTaskCount that notifies the team through Amazon SNS

  Incorrect

  The alarm would tell people faster, but someone would still have to roll back by hand.

• DAdd an EventBridge rule for stopped tasks that invokes a Lambda function to update the service to the previous task definition

  Incorrect

  This needs custom code, which the team wants to avoid, and the circuit breaker already provides the same behavior.

For services that use the rolling update controller, the deployment circuit breaker decides whether a deployment reaches a steady state. With rollback turned on, a failed deployment is replaced by the last deployment that completed.

• AChange the deployment group to blue/green deployments and use a custom deployment configuration with zonal configuration turned on

  Incorrect

  Zonal configuration is supported only with in-place deployments to EC2 instances. Blue/green deployments and on-premises instances cannot use it.

• BTurn on automatic rollback when a deployment fails, and keep the error rate alarm only as a notification to the on-call team

  Incorrect

  This rolls back only a deployment that fails. A release whose lifecycle events succeed is not failed by a rising error rate, and an alarm that is not associated with the deployment group does not stop the deployment.

• CCreate a custom deployment configuration with zonal configuration turned on and a monitor duration of 2,700 seconds, and use it for the group

  Correct

  Zonal configuration deploys to one Availability Zone at a time, and the monitor duration is how long CodeDeploy waits after a zone before it starts the next one.

• DTurn on zonal configuration in CodeDeployDefault.HalfAtATime and set its monitor duration to 2,700 seconds

  Incorrect

  Zonal configuration is not supported with the predefined deployment configurations. It needs a custom deployment configuration.

• EAssociate the error rate alarm with the deployment group and turn on automatic rollback when alarm thresholds are met

  Correct

  An associated alarm that goes into ALARM stops the deployment, and the rollback setting then redeploys the last known good revision as a new deployment.

Zonal configuration turns an in-place deployment into a zone-by-zone rollout with a bake time between zones, and it exists only in custom deployment configurations. The bake time is useful only if something watches it: alarms on the deployment group stop the release, and the alarm-based rollback setting brings back the last known good revision. Note that such a rollback runs on hosts across the Region, not zone by zone.

• ACreate a new numbered launch template version, set it as the version the group uses, and let normal scale-out and scale-in events replace the running instances over time

  Incorrect

  The group uses the launch template version when it launches instances. Running instances are not replaced, and there is no pause or rollback.

• BSet a maximum instance lifetime of one day on the group so that every instance is replaced with the new AMI within a day

  Incorrect

  Maximum instance lifetime replaces instances by age. It offers no checkpoints and no rollback when an alarm goes off.

• CStart an instance refresh to the new AMI with $Latest as the launch template version, auto rollback turned on, and a 20% checkpoint

  Incorrect

  Rollback is not available when the group is configured to use the $Latest or $Default launch template version.

• DCreate a new numbered launch template version and start an instance refresh with checkpoints at 20 and 100%, a 30-minute delay, auto rollback, and the 5xx alarm

  Correct

  Checkpoints pause the refresh at the given percentages for the delay you set, and auto rollback reverts to the previous numbered version if the refresh fails or a listed alarm goes into ALARM.

An instance refresh replaces instances in a controlled way. Checkpoints add pauses for observation, and auto rollback with CloudWatch alarms undoes the change. Rollback needs a specific numbered launch template version on both sides.

• ASet the maximum percent to 200 so that new tasks can start before old tasks are stopped

  Correct

  With both values at 100, ECS can neither stop an old task nor start an extra one, so a higher maximum percent lets it start new tasks first.

• BSet the minimum healthy percent to 100 and the desired count to 1 for every deployment

  Incorrect

  Reducing the desired count to 1 removes capacity during each deployment.

• CTurn on the deployment circuit breaker so that the deployment is rolled back when it is stuck

  Incorrect

  Rolling back does not let the deployment progress under the same configuration.

• DIncrease the health check grace period of the service so that new tasks are marked healthy later

  Incorrect

  No new tasks can start, so the grace period does not matter.

minimumHealthyPercent is the lower limit and maximumPercent the upper limit on running tasks during a rolling update. The two values must leave room for ECS to stop or start tasks.

• ARevert the commit and let the pipeline build, test and publish the previous code as a new version behind the live alias

  Incorrect

  This is the lasting fix, but a pipeline run takes minutes while bad orders keep arriving, and deploying code overwrites the unfinished work in $LATEST.

• BSet the function's reserved concurrency to zero so that no invocation runs until a fixed version is ready

  Incorrect

  Reserved concurrency of zero throttles the function within seconds, but it stops every order instead of returning to working code.

• CStart a CodeDeploy deployment of the live alias from version 12 to version 11 with LambdaLinear10PercentEvery1Minute

  Incorrect

  Linear shifting moves 10 percent of traffic each minute, so most requests reach the faulty version for several more minutes.

• DUpdate the live alias to point to version 11 and leave version 12 published for the investigation

  Correct

  An alias is a pointer to a version that can be updated, so callers using the alias ARN reach version 11 at once, and published versions stay unchanged.

Published Lambda versions are immutable snapshots, and an alias is an updatable pointer to one of them. Moving the alias back is the fastest rollback that keeps clients unchanged and leaves the faulty version in place for analysis.

• AApplicationStop

  Incorrect

  ApplicationStop runs the previous revision's scripts and does not run on the first deployment to an instance.

• BDownloadBundle

  Incorrect

  DownloadBundle is reserved for the CodeDeploy agent and cannot run scripts.

• CBeforeInstall

  Correct

  BeforeInstall is meant for preinstall tasks such as decrypting files and backing up the current version.

• DInstall

  Incorrect

  Install is when the agent copies the revision files, and it cannot run scripts.

For EC2 in-place deployments, scripts run in hooks such as ApplicationStop, BeforeInstall, AfterInstall, ApplicationStart and ValidateService, while DownloadBundle and Install are reserved for the agent.

• A.platform/hooks/prebuild/

  Incorrect

  Prebuild files run after the source bundle is extracted, before the application and web server are set up.

• B.platform/hooks/predeploy/

  Correct

  Predeploy files run after the platform sets up the application and web server, before they are deployed to their final runtime location.

• C.platform/hooks/postdeploy/

  Incorrect

  Postdeploy files run after the application and proxy are deployed.

• D.platform/confighooks/predeploy/

  Incorrect

  Confighooks run during configuration deployments, not application deployments.

Linux platform hooks under .platform/hooks run during application deployments in the prebuild, predeploy and postdeploy stages, while .platform/confighooks run during configuration deployments.

• AWeighted records for both load balancers with health checks, adjusted in steps

  Correct

  Weighted routing sends traffic in proportion to the weights, a weight of 0 stops traffic to a record, and records whose health checks fail are not returned.

• BFailover records with the green stack as primary and the current stack as secondary, each with a health check

  Incorrect

  Failover routing avoids an unhealthy stack automatically, but it is active-passive and sends all traffic to one stack at a time.

• CMultivalue answer records for both load balancers, each linked to a health check

  Incorrect

  Multivalue answers return only healthy records, but at random, so the team cannot set or step the share of traffic.

• DLatency records for the two load balancers, each with a health check

  Incorrect

  Latency routing is for resources in several Regions and picks the one with the best latency, not a chosen percentage.

Weighted routing associates multiple resources with one name and sets how much traffic each receives, which suits gradual blue/green shifts at the DNS level. Health checks keep an unhealthy stack out of the answers.