Golden AMIs for a fleet are updated by an engineer copying files by hand onto running instances. Which automation should be prioritized?
Select an answer to reveal the explanation.
Short Explanation
Stop hand-carving snowflakes—bake AMIs in a pipeline and refresh the fleet. Patching by SSH folklore guarantees drift; baking secrets into the image guarantees incidents.
Full Explanation
Hand-copying files onto running instances to update golden AMIs creates drift and irreversible snowflakes across a municipal fleet. Automating AMI baking in a pipeline and rolling forward with Auto Scaling instance refresh—or equivalent fleet replacement—replaces in-place mutation with immutable, tested images. That automation works because every instance boots from a known artifact, patches are reproducible, and rollback is prior AMI plus refresh—not SSH archaeology. Continuing irreversible manual edits on long-lived production instances as the only patch path fails by guaranteeing configuration drift and uneven CVE exposure. Forbidding AMI updates for twelve months after any CVE is announced fails conceptually: delaying remediation increases exploit window for citizen-facing fleets. Storing credentials inside the AMI in plaintext so refreshed instances boot pre-authenticated fails as a secrets anti-pattern baked into every launch. Exam caveat: instance refresh still needs ASG health checks, connection draining, and capacity headroom; baking without vulnerability scanning can mass-produce vulnerable images. Operational check: put AMI bake in CI, scan the artifact, launch a canary ASG refresh in nonprod, confirm Session Manager access without baked secrets, then schedule production refresh with a rollback AMI ID documented.