A new benefits portal stores database usernames and passwords for its application tier. Security forbids secrets in environment files or container images. Which credential approach best fits?
Select an answer to reveal the explanation.
Short Explanation
Secrets Manager is the locked drawer that changes the locks on a schedule—the app asks for the current key with its role badge. Parking passwords in .env files or wikis is leaving the drawer open in the hallway.
Full Explanation
A benefits portal must not keep database usernames and passwords in environment files or container images. Storing credentials in AWS Secrets Manager or an equivalent secrets service with rotation enabled, retrieved at runtime via IAM roles, meets security policy while supporting automated rotation. Committing a plaintext .env with production passwords into Git exposes secrets in history. Hard-coding the DBA password in a public contractor wiki is equivalent to publishing production access. Emailing passwords to on-call lists on every launch spreads unmanaged copies. Exam caveat: applications need retry and caching behavior around secrets APIs, and rotation must update both secret and database user in a coordinated window. Operational check: remove secrets from images and env files, grant the task role GetSecretValue on the specific secret, launch the portal, confirm DB connect after a forced rotation, and scan the repo for residual credentials. 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.