A city application stores Amazon RDS credentials that must change every 30 days without manual ticket chaos. Which design implements that credential security control?
Select an answer to reveal the explanation.
Short Explanation
Passwords that never change are welcome mats. Secrets Manager rotation flips the RDS password on a timer and keeps apps reading the secret—no monthly AMI rebuild theater. Emailing Mondays or committing secrets to git is how leaks start.
Full Explanation
A city application that must rotate Amazon RDS credentials every 30 days without ticket chaos should store the password in AWS Secrets Manager and enable automatic rotation that updates both the secret value and the database credentials on schedule. Applications retrieve the current secret at runtime (or via cached short TTLs), so rotations do not require AMI rebuilds or manual DBA emails. This pattern is the standard AWS control for managed credential hygiene in municipal CRMs and similar systems.
Hard-coding the password in an AMI and rebuilding instances monthly couples secret rotation to image pipelines, leaves old passwords in historical AMIs, and scales poorly. Emailing the DBA the current password each Monday for manual updates is error-prone, auditable poorly, and invites human delay. Keeping a never-rotated password in a public CodeCommit repo for “transparency” is an explicit secret leak.
Exam caveat: Secrets Manager rotation (often with Lambda rotation functions) is the go-to answer for automated DB credential rotation; Parameter Store can store secrets but Secrets Manager is the rotation-centric service in most exam items. Operational check: enable a 30-day rotation schedule against a non-production RDS instance, confirm the app still connects after rotation, inspect rotation Lambda logs, and deny plaintext secret embedding in task definitions or userdata.