A security review finds that the organization's golden virtual machine image, used to launch hundreds of instances, contains an embedded SSH private key that grants administrative access. What is the best corrective action?
Select an answer to reveal the explanation.
Short Explanation
Baking a key into a golden image is like stamping your house key into every brick of the building. Every copy carries it, so you rebuild the image clean, rotate the exposed key and hand out credentials at launch instead. Encrypting the image or moving the port just hides the problem; the key still works.
Full Explanation
Golden images are cloned at scale, so any secret embedded in them is replicated into every instance, every snapshot and every copy shared with other accounts. Correct image hygiene keeps images free of credentials: build from a hardened, scanned baseline, then supply secrets at launch time from a secrets manager or through short-lived credentials tied to the instance's workload identity. Because the key has already been distributed, it must be treated as compromised and rotated, which means removing its public counterpart from every authorized key list, and existing instances must be redeployed or cleaned. Restricting who can launch the image does nothing about the hundreds of instances already running with the key, nor about anyone who has copied the image or a snapshot. Encrypting the boot volume protects data at rest in storage, but every launched instance decrypts the volume at boot, so the key is readable inside each running system. Changing the SSH port is obscurity; scanners find nonstandard ports quickly, and the valid key still grants access. Exam caveat: secrets in images, code or templates are a recurring cloud weakness; scanning images for secrets should be a build gate. Operational check: run a secrets scan on the rebuilt image and confirm the old public key no longer appears on any instance.