An update to a CloudFormation stack failed and CloudFormation attempted to roll back, but the stack is now stuck in UPDATE_ROLLBACK_FAILED because one resource could not be returned to its previous state. The team needs the stack to reach a stable, updatable status again so they can resume normal deployments, ideally after fixing the offending resource by hand. What is the appropriate recovery step?
- AFix the failed resource manually, then call continue update rollback, optionally skipping that resource, so the stack returns to UPDATE_ROLLBACK_COMPLETE. Correct
- BDelete the whole stack and recreate it from the template, since UPDATE_ROLLBACK_FAILED leaves no supported path back to a usable state.
- CRun drift detection on the stack so CloudFormation repairs the failed resource and moves the stack out of the UPDATE_ROLLBACK_FAILED status.
- DCreate a change set against the failed stack so CloudFormation recalculates the rollback and clears the UPDATE_ROLLBACK_FAILED status automatically.
Why A is correct: Continue update rollback is the supported recovery for UPDATE_ROLLBACK_FAILED; correcting the resource out of band and then resuming, skipping it if needed, lets the rollback finish and the stack reaches a stable updatable status.
Why B is wrong: Deleting and recreating destroys healthy resources and risks data loss for a recoverable condition, and it is unnecessary because CloudFormation provides a continue rollback path out of UPDATE_ROLLBACK_FAILED.
Why C is wrong: Drift detection only reports differences between live resources and the template and never modifies resources or stack status, so it cannot move a stack out of UPDATE_ROLLBACK_FAILED.
Why D is wrong: A change set cannot be executed against a stack in UPDATE_ROLLBACK_FAILED because the stack is not in an updatable state, so it neither recalculates the rollback nor clears the failed status.