A game studio keeps creating the next production AMI by snapshotting a live EC2 instance that operators patch by hand. Last month that image shipped a temporary debug package and one person's SSH key. Which change makes every new instance start from a known build?
Select an answer to reveal the explanation.
Short Explanation
Picture the live server as a counter that collects whatever people set down during the shift. You do not want tomorrow's launch to be a photo of that counter. EC2 Image Builder runs a versioned recipe and a test, so a debug package cannot ride along into the AMI.
Full Explanation
An AMI taken from a running production host freezes whatever drifted onto that host: extra packages, temporary keys, and unpublished edits. EC2 Image Builder starts from a source image, applies a versioned recipe, and can run a test component before it distributes the AMI, so the launch template points at a build you can recreate. A weekly snapshot of the same live instance repeats the drift; the schedule does not add a recipe. An email approval before the capture still photographs the drifted host, and the approval trail is not a build definition. A bootstrap script in a public bucket is not a known image, it runs after boot, and a public object is a poor place for instance setup. Caveat: user data is still useful for instance-specific values, but it should not be the only place the baseline exists. Operational check: open the Image Builder pipeline, confirm the recipe version and test component, and confirm the Auto Scaling launch template references the AMI that pipeline produced.