A warehouse patch must be reversible by returning to the previous machine image. Operators currently install that patch on the live instances with a remote command. Which deployment gives that rollback?
Select an answer to reveal the explanation.
Short Explanation
You want a spare tire you can put back on, not a patch glued onto the one you are driving. Bake the change into a new AMI and roll the group onto it so rollback is the previous image. Patching the live hosts leaves you with no prior image to launch.
Full Explanation
An AMI is the artifact a new instance launches from. Baking the patch into a new AMI and moving the Auto Scaling group onto it means rollback is selecting the previous AMI and replacing instances, which returns the fleet to the image you already trusted. A snapshot taken after the live command captures the mutated disk, not the previous image, so restoring it brings the patch back. Changing user data and rebooting the same hosts still modifies those hosts. It does not launch the prior image, and user data does not by itself become an image-level rollback. A running instance has no AMI identifier you can edit to swap its root image. The image is chosen at launch. Caveat: instances already running the new AMI keep it until the group replaces them, so rolling the launch template back includes refreshing or replacing those instances. Operational check: launch one instance from the new AMI, confirm the patch is present, and confirm a test rollback launches from the previous AMI id rather than rerunning the remote command.