An AMI for the parks payment listener was baked with TLS private keys in the image for "convenience." Every new instance clone now carries those keys. What is the secure fix?
Select an answer to reveal the explanation.
Short Explanation
Baking TLS private keys into an AMI is like photocopying the office master key onto every new laptop image — every clone inherits the leak. Keep images clean and pull secrets at boot from Secrets Manager or SSM instead.
Full Explanation
TLS private keys baked into an AMI for a parks payment listener are inherited by every instance launched from that image, so AMI copies and shared launch templates multiply exposure. The secure fix is to remove private keys from the AMI and inject secrets at runtime from AWS Secrets Manager or SSM Parameter Store (SecureString), using the instance or task role for least-privilege retrieval. Clean machine images plus runtime secret injection is the standard municipal pattern: golden images stay reusable, and key rotation does not require rebaking every AMI.
Sharing the AMI publicly so auditors can inventory embedded keys fails because public sharing broadcasts the compromised material instead of containing it. Increasing the AMI root volume size fails conceptually—more disk space does not add cryptographic entropy or remove embedded secrets. Committing the same private keys into the application Git repository fails because version control becomes a second distribution channel for long-lived credentials.
Exam caveat: after removing secrets from the AMI, rotate any keys that were previously embedded—deletion of the bad AMI alone does not invalidate material already launched. Operational check: scan new AMIs for private key file patterns, confirm bootstrap pulls from Secrets Manager/SSM, and verify IAM policies grant GetSecretValue or ssm:GetParameter only to the payment listener role.