Developers building a new microservice for licensing renewals proposed baking long-term IAM access keys into the container image. What credential hygiene should the architecture require instead?
Select an answer to reveal the explanation.
Short Explanation
The container should wear a role badge it can pick up at runtime—not carry a permanent metal master key glued inside the image. Long-term keys in layers get copied, leaked, and never forgotten.
Full Explanation
Baking long-term IAM access keys into a licensing-renewals microservice image is a credential hygiene failure. Runtime tasks should assume IAM roles—instance profiles, ECS task roles, or IRSA-style bindings—and long-term access keys in images should be forbidden. Keeping long-term keys in the image but rotating every five years still embeds durable secrets in distributable artifacts. Sharing one IAM user access key across microservices and committing it in plaintext CI variables multiplies blast radius. Printing access keys into application logs at startup aids attackers who read logs. Exam caveat: role trust policies and permission boundaries must prevent privilege escalation from a single compromised task. Operational check: scan images and buildspecs for AKIA-pattern keys, deploy with a task role only, confirm STS temporary credentials in use, and deny CreateAccessKey for runtime roles via SCP or permissions boundary. In municipal cloud governance, record the owners, success metrics, and rollback or restore contacts beside this technical choice so the next incident, budget review, or audit does not rediscover the decision from scratch under time pressure. In municipal cloud governance, record the owners, success metrics, and rollback or restore contacts beside this technical choice so the next incident, budget review, or audit does not rediscover the decision from scratch under time pressure.