How to manage Amazon RDS database users consistently across multiple AWS accounts?

Why Option B is Correct

The key requirement here is to define and manage database users consistently across three AWS accounts with the most operational efficiency. Amazon RDS does not expose database-level user management (such as CREATE USER or GRANT statements) as native AWS CloudFormation resource types. Therefore, a standard CloudFormation template cannot directly create or update users inside the database engine.

A CloudFormation custom resource allows you to execute custom logic (typically via an AWS Lambda function) during stack creation, update, or deletion. By embedding a custom resource in the CloudFormation template, you can:

• Run arbitrary code (e.g., SQL commands) to create or update database users.
• Keep the entire infrastructure definition—including database users—in a single CloudFormation template.
• Deploy the same template across all three accounts, ensuring consistency and operational efficiency.
• Automatically handle updates when the template changes.

Why Option A is Incorrect

Option A suggests declaring users directly in the CloudFormation template and "attaching" them to the database. However, CloudFormation does not support RDS database users as a native resource type. You can create the AWS::RDS::DBInstance resource, but you cannot define internal database users (like MySQL or PostgreSQL users) within the template. This makes Option A technically invalid.

Why Option C is Incorrect

Option C involves writing a script and deploying an Amazon EC2 instance in each account to run it. While this would technically work, it introduces significant operational overhead:

• You must manage, patch, and monitor three additional EC2 instances.
• Scheduling and ensuring the script runs correctly adds complexity.
• It violates the principle of operational efficiency by introducing unnecessary infrastructure.

Why Option D is Incorrect

Option D suggests using a single AWS Lambda function with details of all three accounts. While Lambda is a valid execution environment for the custom logic, this approach lacks the Infrastructure as Code benefits of CloudFormation. You would need to:

• Manually manage the Lambda function's deployment and configuration.
• Handle cross-account permissions and secrets separately.
• Lose the ability to track database user state as part of a CloudFormation stack.

Community Consensus

The community overwhelmingly agrees that Option B is correct (100% of votes). Commenters correctly point out that CloudFormation itself does not natively manage database users within RDS, and a custom resource is required to bridge this gap while maintaining IaC best practices.