How to Rotate RDS Administrator Passwords Annually and Most Efficiently?

Answer Correct answer: A — Store the RDS credentials in AWS Secrets Manager and enable its native automatic rotation every 365 days.

A compliance team requires all administrator passwords for Amazon RDS DB instances to be changed at least annually. Which solution meets this requirement in the MOST operationally efficient manner?

  1. Store the database credentials in AWS Secrets Manager. Configure automatic rotation for the secret every 365 days. Correct Answer
  2. Store the database credentials as a parameter in the RDS parameter group. Create a database trigger to rotate the password every 365 days.
  3. Store the database credentials in a private Amazon S3 bucket. Schedule an AWS Lambda function to generate a new set of credentials every 365 days.
  4. Store the database credentials in AWS Systems Manager Parameter Store as a secure string parameter. Configure automatic rotation for the parameter every 365 days.

Community Insight

The question tests whether you know Secrets Manager natively rotates RDS credentials — the trap is assuming a Parameter Store SecureString rotates itself or that custom Lambda code is required.

Amazon RDS administrator credentials must be rotated at least yearly, and AWS Secrets Manager has native, built-in rotation support for RDS databases. This page confirms that Secrets Manager rotation (A) is the most operationally efficient answer compared with custom Lambda scripts, S3 storage, or Parameter Store workflows.

The most common wrong pick is Parameter Store (D), because a SecureString sounds equally secure, but Parameter Store has no native RDS rotation and would require you to build and maintain custom Lambda rotation logic.

Community Discussion (1 comments)

Bad_Mat 👍 1 Selected: A
Why Option A is CorrectNative Integration: AWS Secrets Manager has built-in, native support to manage and automatically rotate credentials for Amazon RDS databases without requiring custom code or infrastructure.Operational Efficiency: It eliminates the need to write and maintain custom scripts, database triggers, or scheduled functions, making it the most automated and operationally efficient choice among the options.

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Expert Analysis

Why the Answer Is Correct

AWS Secrets Manager was purpose-built to store and rotate database credentials, and it ships with a native rotation capability specifically for Amazon RDS (including the master user password). Enabling rotation with a 365-day schedule satisfies the compliance requirement with no custom code, no database triggers, and no self-maintained Lambda functions. Secrets Manager also updates the password in both the secret and the RDS instance atomically, so applications reading the secret keep working. That combination of managed rotation plus zero operational overhead is exactly what "MOST operationally efficient" points to.

Why the Other Options Are Wrong

Option B puts credentials in an RDS parameter group, which is a configuration container for engine parameters — credentials do not belong there and a database trigger cannot rotate the RDS master password it is authenticating with. Option C stores secrets in a private S3 bucket and uses a scheduled Lambda to generate new credentials, which means you own the code, the error handling, the RDS password change call, and the retry logic — far less efficient than a managed rotation function. Option D looks strong because Parameter Store SecureString encrypts values with KMS, but Parameter Store offers no native RDS rotation; you would have to write and maintain the rotation Lambda yourself, so it is not the most operationally efficient solution.

Community Comment Notes

As Bad_Mat noted, Secrets Manager provides "built-in, native support to manage and automatically rotate credentials for Amazon RDS", which removes the need for custom scripts, database triggers, or scheduled functions. That framing mirrors the exam's efficiency language: the deciding factor is not whether a store is encrypted, but whether rotation is a managed, turnkey feature. Community consensus on this question lines up behind the Secrets Manager option for that reason.

Operational Considerations

A 365-day rotation schedule is the minimum the compliance team accepts; Secrets Manager also supports shorter schedules and multi-user rotation strategies if the team tightens the policy later. The rotation Lambda that Secrets Manager invokes can reach the database through a VPC, so ensure the rotation function has network access to the RDS instance before you enable the schedule.

Official Reference

Exam Strategy

When a question asks for the MOST operationally efficient way to rotate database credentials, eliminate any option that requires you to write or schedule custom code. Then choose the fully managed service that has native rotation support for the specific database engine named in the question.

Frequently Asked Questions

Does Parameter Store support native rotation for RDS credentials?

No. SecureString parameters are encrypted but not rotated natively; you must build and schedule your own Lambda rotation, which is less operationally efficient than Secrets Manager.

Why is a scheduled Lambda with an S3 bucket less efficient than Secrets Manager?

You would own the rotation code, RDS password change call, retries, and error handling, while Secrets Manager provides a managed RDS rotation function out of the box.

More SOA-C03 FAQ →

Related Analysis

Practice All SOA-C03 Questions

Access 100 questions with complete answers and detailed explanations.

View Full SOA-C03 Practice Test →

← Back to SOA-C03 Study Guide