AWS DVA-C02 Drill: RDS Password Automation - Secrets Manager vs. Custom Lambda Logic

Jeff’s Note

#

“Unlike generic exam dumps, ADH analyzes this scenario through the lens of a Real-World Lead Developer.”

“For AWS DVA-C02 candidates, the confusion often lies in how to generate and securely inject dynamic secrets like DB passwords during automated CloudFormation deployments. In production, this is about knowing exactly which AWS service handles secret generation and integration seamlessly with least custom code. Let’s drill down.”

The Certification Drill (Simulated Question)

#

Scenario

#

TechWave Software is migrating its database provisioning to Amazon RDS and wants to embed the entire deployment process in a CI/CD pipeline using AWS CodePipeline and CloudFormation for consistency and auditability. As part of this automation, the primary master password for each RDS DB instance must be generated automatically and securely during the deployment workflow—developers want to eliminate any manual password provision or insecure hardcoding.

The Requirement

#

Which of the following solutions meets the requirement to automate secure password generation during CloudFormation stack creation, by minimizing developer effort and complexity?

The Options

#

• A) Create an AWS Lambda-backed CloudFormation custom resource. Implement Lambda code that generates a strong password, return it as a data attribute in the custom resource response, and retrieve that value with the intrinsic function Fn::GetAtt for the DB password parameter.

• B) In the AWS CodeBuild stage of the CodePipeline, run the AWS CLI command aws secretsmanager get-random-password to generate a password string. Pass that value as a CloudFormation parameter with the NoEcho attribute set to true, and refer to it when creating the DB instance.

• C) Create an AWS Lambda-backed CloudFormation custom resource. The Lambda function generates a secure password, saves it as a secret in AWS Secrets Manager, and returns metadata. Use a Secrets Manager dynamic reference to retrieve the stored password secret for the DB instance password.

• D) Use the CloudFormation resource type AWS::SecretsManager::Secret to generate and store a password directly as a secret in Secrets Manager. Then use the Secrets Manager dynamic reference in the DB instance resource to fetch and use the generated password.

Google adsense

#

leave a comment:

Correct Answer

#

D

Quick Insight: The Developer Imperative

#

• Automating secret generation is best handled by AWS Secrets Manager’s native integration with CloudFormation. This avoids writing and maintaining custom Lambda code.
• Using AWS::SecretsManager::Secret to generate and store the password leverages Secrets Manager’s built-in password generator.
• Dynamic references ({{resolve:secretsmanager:secretId:SecretString:password}}) securely surface secrets in stack templates without exposing values.
• Options involving custom Lambda functions introduce unnecessary development overhead and complexity.

Content Locked: The Expert Analysis

#

You’ve identified the answer. But do you know the implementation details that separate a Junior from a Senior?

The Expert’s Analysis

#

Correct Answer

#

Option D

The Winning Logic

#

Option D represents the cleanest, lowest maintenance approach. The CloudFormation resource AWS::SecretsManager::Secret supports automatic password generation through built-in password policies. You can configure length, character sets, and rotation options in the secret resource itself. This integration fully offloads the secret creation to AWS, avoiding any custom code or manual process.

During stack creation, the DB instance resource can then use Secrets Manager dynamic references ({{resolve:secretsmanager:secretId:SecretString:password}}) in the MasterUserPassword field. This ensures the password is never exposed in plaintext CloudFormation parameters or logs and is managed entirely by AWS services with minimal developer intervention.

The Trap (Distractor Analysis):

#

• Why not A? Writing a Lambda-backed custom resource to generate passwords adds operational complexity, needs custom error handling, permission management, and increased maintenance.

• Why not B? While CodeBuild’s AWS CLI call can generate a password, passing it as a CloudFormation parameter still risks exposure without perfect handling, and adds scripting overhead outside CloudFormation itself.

• Why not C? Although storing the password in Secrets Manager is good practice, adding a Lambda custom resource to generate and store the secret is redundant. The AWS::SecretsManager::Secret resource handles generation natively.

The Technical Blueprint

#

# Example snippet showing dynamic reference usage in CloudFormation

MasterUsername: adminUser
MasterUserPassword: '{{resolve:secretsmanager:MyRdsSecret:SecretString:password}}'

Resources:
  MyRdsSecret:
    Type: AWS::SecretsManager::Secret
    Properties:
      GenerateSecretString:
        PasswordLength: 16
        ExcludeCharacters: '"@/\ '
        RequireEachIncludedType: true
      Name: MyRdsSecret
  MyRdsInstance:
    Type: AWS::RDS::DBInstance
    Properties:
      DBInstanceIdentifier: mydbinstance
      Engine: mysql
      MasterUsername: !Ref MasterUsername
      MasterUserPassword: !Join ['', ['{{resolve:secretsmanager:', !Ref MyRdsSecret, ':SecretString:password}}']]
      # Additional required properties omitted for brevity

The Comparative Analysis

#

Real-World Application (Practitioner Insight)

#

Exam Rule

#

“For the exam, always prefer AWS::SecretsManager::Secret with dynamic references when you need automated secure secrets during CloudFormation stack creation.”

Real World

#

“In your pipelines, custom Lambda functions for generating secrets add operational burdens and potential security risk. Let AWS Secrets Manager handle password generation, storage, and secure retrieval.”

(CTA) Stop Guessing, Start Mastering

#

Disclaimer

This is a study note based on simulated scenarios for the AWS DVA-C02 exam.