A company uses AWS CloudFormation templates to manage infrastructure for a public-facing application in its development, pre-production, and production environments. The company needs to scale for…

Question

Options

• AThe new instance type specified in the CloudFormation template is invalid
• BThe database was deleted or modified manually outside of the CloudFormation stack
• CThere is a syntax error in the CloudFormation template
• DThe developer has insufficient IAM permissions to provision an instance of the specified type

• A
  17% (6)
• B
  71% (25)
• C
  9% (3)
• D
  3% (1)

Explanation

UPDATE_ROLLBACK_FAILED occurs when CloudFormation tries to roll back a failed update but cannot - this happens when the real-world resource state has drifted from what CloudFormation expects, which is exactly what occurs when someone manually deletes or modifies a resource outside the stack (option B). CloudFormation's rollback attempts to restore the previous state, but if the resource no longer matches its last known configuration, the rollback itself fails.

Why the distractors are wrong:

• A (invalid instance type): An invalid type would cause an UPDATE_FAILED error during the update attempt itself, not an UPDATE_ROLLBACK_FAILED - the stack would simply fail to update and roll back successfully.
• C (syntax error): A template syntax error is caught at validation/parse time before the update even begins, so the stack would never reach a rollback state.
• D (insufficient IAM permissions): Permission errors also cause UPDATE_FAILED, and CloudFormation can typically roll back successfully from them since no changes were made.

Memory tip: Think of UPDATE_ROLLBACK_FAILED as "CloudFormation is confused about reality" - it only happens when the actual AWS resources no longer match what CloudFormation has on record, almost always due to out-of-band (console/CLI) changes. If CloudFormation knows what went wrong (bad template, bad permissions), it can roll back cleanly.

No community discussion yet for this question.