A permitting fleet must upgrade reliably. Leadership prefers images that are baked in CI over long-lived golden images patched in place. Which pattern should the architect choose?
Select an answer to reveal the explanation.
Short Explanation
Treat servers like sealed bottles from the plant, not pets you nurse with SSH. Bake the AMI in CI, launch fresh, and retire the old ones—upgrades and rollbacks stay clean.
Full Explanation
Permitting fleets upgrade more reliably when machine images are immutable artifacts produced in CI rather than long-lived golden AMIs patched in place for years. Baking AMIs in the pipeline and replacing instances with new image versions makes each release a known, tested filesystem state and avoids configuration drift that accumulates when operators SSH-patch production pets. Multi-year golden AMIs that are SSH-patched weekly recreate the snowflake problem inside an AMI label and complicate audit of what actually runs during an incident response. Disabling AMI versioning so every launch uses an unnamed latest image removes reproducibility and makes rollback ambiguous for citizen-facing services. Hand-editing production filesystems without capturing a new AMI guarantees drift between documentation and reality for inspectors and operators alike. Exam caveat: immutable replacement still needs warm pools or rolling policies so citizen-facing capacity is not drained during instance refresh. Operational check: bake an AMI from CI, launch a canary instance, verify patch and config inventory match the pipeline metadata, then roll the Auto Scaling refresh and confirm the prior AMI remains available for quick reversion if health checks fail.