A company runs an application on Amazon EC2 that connects to an Amazon RDS for PostgreSQL database using a username and password. Security policy requires that the database password be changed automatically every 30 days with no manual steps and no application downtime. Which approach meets these requirements with the least operational overhead?
- AStore the credentials in AWS Secrets Manager and enable managed rotation with a 30 day schedule so the password is updated in both the secret and the database automatically. Correct
- BStore the credentials as a SecureString parameter in Systems Manager Parameter Store and write a scheduled Lambda function to overwrite the value monthly.
- CStore the credentials in AWS Systems Manager Parameter Store as a standard parameter and rely on parameter version history to track each monthly password change.
- DStore the database password directly in the EC2 instance user data script and replace the launch template version every month to introduce a new password.
Why A is correct: Secrets Manager natively rotates RDS credentials on a defined schedule, updating both the database and the stored secret without manual effort or downtime, meeting the requirement with the least overhead.
Why B is wrong: Parameter Store SecureString encrypts the value but has no native rotation, so you must build and maintain the entire rotation workflow yourself, which is more operational overhead than required.
Why C is wrong: Standard parameters store values in plaintext and version history only records changes, so this neither secures the password nor performs any rotation against the database automatically.
Why D is wrong: User data is readable from instance metadata and is not encrypted, so embedding a password there exposes it and still requires manual launch template edits each month.