Question

Difficulty: HardAWS CloudFormation

A developer manages an AWS CloudFormation stack for a production application. The stack defines an Amazon S3 bucket with the `DeletionPolicy` attribute set to `Retain`. To update the application's storage architecture, the developer modifies the CloudFormation template to change the name of the S3 bucket, which requires resource replacement. Before executing the stack update, the developer manually deletes the original S3 bucket out-of-band using the AWS CLI. During the stack update, a name collision error occurs for the new S3 bucket, causing the update to fail and begin rolling back. The rollback fails because the original S3 bucket no longer exists, and the parent stack becomes stuck in the `UPDATE_ROLLBACK_FAILED` state.

Which sequence of actions must the developer take to resolve this failure and successfully complete the name change?

  1. A
    Manually delete the parent stack to clean up the failed resources. Recreate the stack from scratch using the new template containing the unique bucket name, and copy the application data to the new S3 bucket.
  2. B
    Enable drift detection on the stack to automatically synchronize the physical state of the deleted S3 bucket with the template definition. Once the drift status is marked as synchronized, trigger a stack update using the new template containing the unique bucket name.
  3. Invoke the `ContinueUpdateRollback` action and select the original S3 bucket as a resource to skip. Once the stack returns to a stable state, update the template to use a globally unique name for the new S3 bucket, and then run the stack update again.Answer
  4. D
    Convert the S3 bucket name parameter to a dynamic reference pointing to an AWS Secrets Manager secret. Update the secret value with the new bucket name, and run the update operation to automatically bypass the rollback lock.

Answer

Invoke the `ContinueUpdateRollback` action and select the original S3 bucket as a resource to skip. Once the stack returns to a stable state, update the template to use a globally unique name for the new S3 bucket, and then run the stack update again.
The correct answer is to use the `ContinueUpdateRollback` action and skip the deleted S3 bucket. Because the original bucket was deleted manually, CloudFormation cannot recreate it or revert its state during the rollback, which blocks the stack. Skipping the resource during the rollback process lets the stack reach a stable status (`ROLLBACK_COMPLETE` or `UPDATE_ROLLBACK_COMPLETE`). From there, the template can be fixed with a unique bucket name to avoid collision and update successfully.

Step-by-Step Solution

1
Perform the ContinueUpdateRollback operation.
The stack skips rolling back the deleted S3 bucket and successfully transitions to the `ROLLBACK_COMPLETE` state.
When a stack update rollback fails due to a missing resource, skipping that resource allows CloudFormation to bypass the block and bring the stack to a stable state.
2
Modify the CloudFormation template to specify a globally unique name for the new S3 bucket.
The template is prepared with a unique resource name that will not cause a name collision.
The initial stack update failed due to a name collision, so a unique name is required for successful creation.
3
Initiate a new stack update using the updated template.
The stack updates successfully, creating the new S3 bucket and completing the replacement.
Since the stack is now in a stable state, it can accept new update commands to apply the corrected configuration.

Key Concept

CloudFormation update rollback recovery and handling resource replacement drift
Rate this question