New VMs for a city help-desk fleet keep launching from a six-month-old golden image that predates many critical patches. What image lifecycle practice should operations adopt?
Select an answer to reveal the explanation.
Short Explanation
If the cookie cutter is dirty, every new cookie comes out dirty. Refresh golden images regularly so brand-new VMs are not born already behind on patches.
Full Explanation
Golden images are lifecycle artifacts that should be rebuilt or updated on a defined cadence aligned with patching strategy so newly launched VMs start from a currently patched baseline. When city help-desk fleet VMs keep launching from a six-month-old image that predates many critical patches, operations must refresh the golden image pipeline; otherwise every scale-out reintroduces known vulnerabilities into the civic environment.
Never updating golden images so every VM matches a historic baseline forever institutionalizes drift into the past. Patching only long-lived VMs while forbidding image refresh leaves the launch path unsafe. Allowing each user to upload personal untested ISOs as the new golden standard destroys provenance and change control.
Exam caveat: image refresh cadence complements but does not replace patching already-running instances. Sign and scan images; track versions immutable-style for rollback.
Operational check: rebuild the golden image with current patches, run CIS/vulnerability scans, publish a new image version to the launch templates/ASGs, prevent launches from the stale image, and verify a newly launched help-desk VM shows expected patch levels. Document image ownership and refresh SLA for the city platform team.