DOP-C02 Incident and Event Response Practice Question

A company uses AWS CloudFormation to deploy infrastructure. During an incident, a stack update fails with a stack rollback. The engineer needs to prevent the stack from rolling back on future failures and instead retain the resources for debugging. Which CloudFormation feature should the engineer use?

⚠ Common exam trap

Many exam-takers confuse change sets (which preview changes) with the ability to prevent rollback, or mistakenly think drift detection or StackSets can alter rollback behavior, when only the `--disable-rollback` flag directly controls whether resources are retained on failure.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Use the '--disable-rollback' option when updating the stack

The `--disable-rollback` option (or `DisableRollback` in the CloudFormation template) instructs AWS CloudFormation to leave the stack in its current state (with the failed resources intact) instead of automatically rolling back to the last known good state. This allows engineers to retain the resources for debugging without the stack being torn down on failure.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Enable drift detection on the stack
Why it's wrong here
Drift detection evaluates whether a stack's actual resources differ from the declared template, operating as a detective control that runs after deployment. It does not intercept a failed update or alter CloudFormation's default rollback behavior; the service still reverts the stack to its last successful state when an update error occurs. Therefore, enabling drift detection cannot prevent rollback; it only flags configuration mismatches post-hoc.
✓
Use the '--disable-rollback' option when updating the stack
Why this is correct
The `--disable-rollback` flag on `aws cloudformation update-stack` instructs CloudFormation to leave the stack in its failed state instead of reverting to the previous successful template. This is the correct way to prevent rollback because it preserves the partially updated resources—including any S3 buckets, EC2 instances, or custom resources—for root-cause analysis and manual remediation. The stack status becomes `UPDATE_FAILED`, and the original resources remain untouched until you intervene.
✗
Use AWS CloudFormation StackSets to deploy the stack
Why it's wrong here
AWS CloudFormation StackSets extends a single template across multiple accounts and AWS Regions, using a `StackSet` to centrally provision stack instances. It does not control the lifecycle or failure handling of an individual stack update; rollback behavior is per-stack and governed by the update command's parameters, not by StackSets. Hence, using StackSets does not address the need to prevent rollback on a failed update.
✗
Create a change set before updating instead of direct update
Why it's wrong here
A change set provides a visual, itemized preview of how resource properties, additions, and removals will be executed, letting you review risks before applying the update. However, it only stages the declaration; once the change set is executed, the resulting update is subject to the standard rollback process if any resource fails to create or update. Thus, change sets improve planning safety but do not modify the subsequent update's rollback policy.

Go deeper

DOP-C02 Incident and Event Response Practice Question

Why each option matters

Option-by-option breakdown

Related to this question