Question

Difficulty: MediumAWS CloudFormation Stack and Drift Management

A SysOps administrator initiates an update on a production AWS CloudFormation stack. The update fails during the modification of a database resource, triggering an automatic rollback. During this process, the stack status transitions to `UPDATE_ROLLBACK_FAILED`. Upon reviewing the stack events, the administrator discovers that CloudFormation cannot delete an old security group because it is still associated with an EC2 instance that was manually launched by a developer outside of CloudFormation. Which action should the SysOps administrator take to resolve the `UPDATE_ROLLBACK_FAILED` state and return the stack to a stable configuration?

  1. Run the `continue-update-rollback` CLI command with the `--resources-to-skip` parameter to skip the security group, then manually disassociate it from the EC2 instance once the stack is stable.Answer
  2. B
    Modify the local CloudFormation template to remove the security group resource, and execute a stack update using the updated template to force the rollback to finish.
  3. C
    Delete the entire CloudFormation stack while selecting the option to retain the security group, then redeploy the stack from the previous template.
  4. D
    Add the `iam:PassRole` permission to the CloudFormation execution role's policy to grant CloudFormation the authority to detach the security group from the manually launched EC2 instance.

Answer

Run the `continue-update-rollback` CLI command with the `--resources-to-skip` parameter to skip the security group, then manually disassociate it from the EC2 instance once the stack is stable.
The correct action is to run the `continue-update-rollback` CLI command with the `--resources-to-skip` parameter specifying the logical ID of the blocked security group. When a resource rollback fails because of an external dependency (such as an active association with a manually created EC2 instance), CloudFormation blocks the rollback. Skipping this resource allows CloudFormation to complete the rollback for the remaining resources and return the stack to a stable `UPDATE_ROLLBACK_COMPLETE` status, after which the administrator can clean up the manual resource dependency.

Step-by-Step Solution

1
Identify the resource blocking the rollback by checking the stack event log in the CloudFormation console or using the CLI command `describe-stack-events`.
The log reveals that the security group cannot be deleted because it is still in use by an external EC2 instance.
Before resolving the rollback failure, you must identify which specific resource is blocking CloudFormation from reverting to the previous state.
2
Execute the `continue-update-rollback` CLI command (or use the equivalent action in the AWS Console) specifying the logical ID of the blocked security group in the `--resources-to-skip` parameter.
CloudFormation sets the status of the skipped security group to `UPDATE_COMPLETE` and resumes rolling back the rest of the stack resources.
Skipping the blocked resource allows the stack to successfully transition out of the failed rollback state to a stable `UPDATE_ROLLBACK_COMPLETE` status.
3
Once the stack is in `UPDATE_ROLLBACK_COMPLETE` status, manually detach the security group from the non-stack EC2 instance to clean up the configuration drift.
The security group is no longer associated with the external EC2 instance, allowing future clean stack updates to succeed.
Manually resolving the dependency post-rollback ensures that the infrastructure state is cleaned up without blocking immediate stack recovery.

Key Concept

Handling stack rollback failures by skipping resources that cannot be deleted or updated due to external dependencies.
Rate this question