DOP-C02 - Incident and Event Response (14% of the exam) - Section 5.4

Troubleshoot deployment and pipeline failures using AWS CloudFormation stack rollback, AWS CodeDeploy automatic rollback, deployment alarms and pipeline failure states.

Diagnose failed CloudFormation stack updates by inspecting rollback triggers and stack events, and configure CodeDeploy automatic rollback to revert to the previous revision when a CloudWatch alarm fires during a deployment. Identify the correct corrective action - manual rollback, redeploy from a clean state, or pipeline re-run - based on the failure mode observed.

CloudFormation rollbackCodeDeploy automatic rollbackRollback triggersPipeline failures

Practice question for this objective

Free sampleIncident and Event Responsehard

A payments service is released through an AWS CodeDeploy blue/green deployment on Amazon ECS. The team wants traffic shifted to the green task set gradually, and they want CodeDeploy to abort the shift and send all traffic back to the original blue task set the moment a CloudWatch alarm on the 5xx response rate fires during the canary window. They consider this rollback non-negotiable for any future deployment. Which configuration MOST directly enforces alarm-driven rollback during the traffic shift?

AUse an AllAtOnce traffic-shifting configuration and add a BeforeAllowTraffic hook that validates the green task set, so the release is checked before any production traffic ever reaches the new tasks.
BChoose a canary traffic-shifting configuration, associate the 5xx CloudWatch alarm with the deployment group, and enable automatic rollback when a deployment alarm is triggered so traffic returns to blue. Correct
CChoose a canary traffic-shifting configuration and enable automatic rollback when the deployment fails, relying on the ECS deployment circuit breaker to detect the elevated 5xx rate and fail the deployment.
DChoose a linear traffic-shifting configuration and configure an Amazon EventBridge rule on the alarm that invokes a Lambda function to call StopDeployment, so the function halts the shift when 5xx rates rise.

Bind a CloudWatch alarm to a CodeDeploy blue/green deployment group with automatic rollback so a canary shift reverts to blue when the alarm fires. Associating a CloudWatch alarm with a CodeDeploy deployment group and enabling automatic rollback on alarm makes CodeDeploy monitor the metric during a canary or linear shift; if the alarm enters ALARM, CodeDeploy aborts the shift and routes all traffic back to the original task set without custom code.

Why A is wrong: AllAtOnce shifts every request at once and a BeforeAllowTraffic hook runs before live traffic, so neither watches the production 5xx rate during a gradual shift nor triggers the rollback the requirement demands.

Why B is correct: A canary shift exposes a slice of traffic first, and an associated CloudWatch alarm with automatic rollback enabled aborts the shift and routes all traffic back to the blue task set the moment the 5xx alarm fires.

Why C is wrong: Rollback on deployment failure reacts to the deployment status rather than the 5xx alarm, and the ECS circuit breaker is a separate mechanism, so this does not bind the rollback to the specified CloudWatch alarm.

Why D is wrong: A Lambda calling StopDeployment only halts the shift rather than routing traffic back to blue, and it adds custom code where the native deployment alarm with automatic rollback already performs the reroute.

See more DOP-C02 practice questions, answers explained.

Exam traps in Incident and Event Response

Answers that look right on this material and are not. Each one is a distractor from a different question in the DOP-C02 bank for this domain.

Delete the stack and recreate it from the same template, accepting the recreation of all resources so the new stack starts in a clean CREATE_COMPLETE state ready for future updates.
Why it is wrong: Deleting and recreating the stack is the most disruptive option and destroys resources the requirement says to preserve; UPDATE_ROLLBACK_FAILED can be resolved without tearing the stack down.
Add an AfterAllowTraffic lifecycle hook whose validation script queries the error-rate metric and exits non-zero so the deployment is marked failed, prompting an operator to begin the manual rollback once they are paged.
Why it is wrong: An AfterAllowTraffic check can flag a bad build, but the scenario asks for hands-off reversion and this design still funnels recovery through a paged operator rather than triggering an automatic rollback.
Add a WaitCondition with a handle to the template so the update pauses until a signal arrives, letting an external monitor decide whether to send success or trigger a rollback based on the alarm state.
Why it is wrong: A WaitCondition only blocks on an external signal and provides no alarm monitoring after resources change, so the team must build the alarm-watching and rollback logic themselves rather than using a native feature.

Examworthy is not affiliated with or endorsed by Amazon Web Services. Original, blueprint-aligned practice material only.