A rolling CloudFormation update replaces Auto Scaling instances that never start the application, and the stack still finishes successfully. The template does not wait for a success signal from those instances. What should the template require so a failed boot rolls the update back?
Select an answer to reveal the explanation.
Short Explanation
You would not call a bus trip finished because the bus left the garage. A rolling update needs a success signal from each new instance, and without it CloudFormation treats a dead boot as done. Wait for cfn-signal so a missing signal rolls your stack back.
Full Explanation
A CreationPolicy tells CloudFormation to wait until cfn-signal reports success from the new instances. On an Auto Scaling rolling update, WaitOnResourceSignals makes that same wait part of the update, so an instance that never becomes ready fails the resource update. With rollback left enabled, CloudFormation then returns the stack to the previous template instead of recording a successful update. A DeletionPolicy of Retain only decides whether a resource is kept when it is removed. It does not judge whether a new instance booted. DependsOn orders resource creation. It does not receive a success signal from the operating system. UpdateReplacePolicy Snapshot applies when a resource is replaced and does not turn a failed boot into a stack rollback. Caveat: the new instances must be able to reach CloudFormation for the signal to arrive, and an update started with rollback disabled stops in a failed state instead of rolling back. Operational check: deploy a deliberately bad boot once, confirm the stack reaches update rollback complete, and confirm the group is launched from the previous template again.