SOA-C02 Deployment, Provisioning, and Automation Practice Question

Answer analysis

Option-by-option breakdown

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

• ✓

  Identify and resolve the resource issue that caused the rollback failure, then continue the rollback.

  Why this is correct

  The correct first action is to inspect the stack events and any associated resource status reasons to identify why the rollback itself failed. CloudFormation will not proceed past the UPDATE_ROLLBACK_FAILED state until the underlying resource issue is resolved, because resources that could not be rolled back remain in a state that blocks further stack operations. After fixing the resource problem, such as deleting a non-CloudFormation-managed dependency or manually updating an unresponsive resource, you can use the "Continue update rollback" operation to drive the stack to a stable UPDATE_ROLLBACK_COMPLETE state. This is the only recovery path that preserves the stack and any successfully rolled-back resources without forcing a destructive teardown.

• ✗

  Wait for CloudFormation to automatically retry the rollback.

  Why it's wrong here

  CloudFormation does not implement any automatic retry mechanism for failed rollbacks; a stack that enters UPDATE_ROLLBACK_FAILED remains in that terminal failure state until an administrator takes action. The only way to trigger additional rollback attempts is to manually call the ContinueUpdateRollback API operation, and that operation also does not retry automatically—it executes only a single rollback attempt per call. Waiting, therefore, leaves the stack indefinitely unusable and blocks subsequent update or delete operations, so passive waiting is not a valid resolution strategy.

• ✗

  Execute a new stack update to overwrite the failed resources.

  Why it's wrong here

  Attempting a new stack update while the stack is in the UPDATE_ROLLBACK_FAILED state is not permitted because CloudFormation requires the stack to be in a stable, non-failed state before accepting an update request. Even if you were able to submit an update, the failed resource that caused the rollback to fail would likely still block the update because CloudFormation cannot reliably change or overwrite a resource in an unknown or inconsistent state. A new update would also risk compounding the problem by introducing new resource changes on top of a partially rolled-back and unrecoverable stack, rather than addressing the root cause the rollback failed to clean up.

• ✗

  Delete the stack and recreate it from the template.

  Why it's wrong here

  Deleting the stack in the UPDATE_ROLLBACK_FAILED state is often blocked by CloudFormation for the same reason that updates are blocked—the failed resource cannot be destroyed or removed cleanly, so the delete operation would likely fail. If you force deletion by first manually removing or altering resources outside of CloudFormation, you risk orphaning the stack's logical resources and potentially causing data loss, especially for stateful resources such as databases or S3 buckets that are protected by the stack's resource policy. Additionally, recreating the stack from the template is unnecessary and may not succeed if the environment still contains remnants of the failed rollback, such as manually deleted resources that CloudFormation still references, making resolution of the underlying issue the more appropriate and less destructive path.

Go deeper

Related to this question