A retailer applied an AWS CloudFormation update to a production stack, but a resource failed to update and the automatic rollback then failed as well because a database resource could not return to its previous configuration, leaving the stack in UPDATE_ROLLBACK_FAILED. The stack is now locked and no further updates can be applied, blocking the team's repeatable pipeline releases. The engineers have manually corrected the underlying database out of band so it matches the last known good state, and they need to return the stack to a stable, fully managed state so normal deploys can resume with the least disruption. Which action BEST recovers the stack?
- ADelete the stack entirely and recreate it from the last known good template in a fresh CloudFormation stack, accepting the recreation of the production database and the associated downtime so the new stack starts in a clean CREATE_COMPLETE state.
- BEnable drift detection on the stack and then import the corrected database resource into a new stack, leaving the original stack in its failed state as a record while the pipeline points at the freshly imported stack going forward.
- CCall ContinueUpdateRollback on the stack and pass the logical ID of the resource that could not roll back in the list of resources to skip, so CloudFormation completes the rollback and returns the stack to UPDATE_ROLLBACK_COMPLETE. Correct
- DRun a stack update with the last known good template and rely on CloudFormation to detect that the stack is stuck and reconcile it back to that template, applying the previous configuration to every resource in a single corrective deployment.
Why A is wrong: Deleting and recreating the stack would tear down and rebuild the production database and other resources, causing exactly the major downtime the team wants to avoid when a targeted recovery of the existing stack is available.
Why B is wrong: Drift detection only reports differences and resource import builds a separate stack rather than recovering the original, so this abandons the blocked stack and fragments management instead of returning it to a stable, fully managed state.
Why C is correct: ContinueUpdateRollback resumes a failed rollback, and skipping the resource the engineers already fixed out of band lets CloudFormation finish reverting the remaining resources and move the stack to UPDATE_ROLLBACK_COMPLETE so normal updates can resume.
Why D is wrong: A stack in UPDATE_ROLLBACK_FAILED rejects new update operations until the failed rollback is resolved, so issuing an update-stack call is not permitted and cannot move the stack out of the failed rollback state.