Jeff’s Note #
Unlike generic exam dumps, ADH analyzes this scenario through the lens of a Real-World Lead Developer.
For DVA-C02 candidates, the confusion often lies in how to securely manage database credentials for AWS Lambda functions while ensuring automatic rotation. In production, this is about knowing exactly which AWS service provides seamless secret storage with built-in rotation support and SDK integration. Let’s drill down.
The Certification Drill (Simulated Question) #
Scenario #
DevCo, a fintech startup, is building a serverless microservice using AWS Lambda to connect to its Amazon Aurora MySQL cluster. The lead developer needs to securely store database credentials within the Lambda environment. Additionally, the database user password must be rotated automatically without manual intervention, to align with security best practices and auditing requirements.
The Requirement: #
Implement a solution that securely stores and encrypts the database credentials and supports automated password rotation compatible with Lambda accessing the database.
The Options #
- A) Store the database credentials as environment variables for the Lambda function. Set the environment variables to rotate automatically.
- B) Store the database credentials in AWS Secrets Manager. Set up managed rotation on the database credentials.
- C) Store the database credentials in AWS Systems Manager Parameter Store as secure string parameters. Set up managed rotation on the parameters.
- D) Store the database credentials in the X-Amz-Security-Token parameter. Set up managed rotation on the parameter.
Google adsense #
leave a comment:
Correct Answer #
B
Quick Insight: The Developer Imperative #
For DVA-C02, knowing when to use AWS Secrets Manager over Parameter Store (despite both offering encryption) is key. Secrets Manager is purpose-built for secrets and supports automatic password rotation, which Parameter Store does not natively provide. This distinction is critical for secure serverless applications accessing RDS.
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 B
The Winning Logic #
AWS Secrets Manager is designed specifically for managing secrets such as database credentials. It encrypts secrets at rest with KMS, integrates seamlessly with Lambda via SDK calls, and—crucially—supports built-in managed rotation of credentials through Lambda rotation functions. This eliminates manual rotation overhead and security risk from stale credentials.
The Lambda function can retrieve the current secret value securely at runtime by calling Secrets Manager’s GetSecretValue API. The database password rotation runs independently, and Secrets Manager integrates with RDS to update passwords transparently.
The Trap (Distractor Analysis): #
-
Why not A? Environment variables are not designed for secure secret storage. They are stored in plaintext (albeit encrypted at rest) and cannot be rotated automatically. Rotation “automatically” on environment variables is not a native feature.
-
Why not C? Parameter Store supports encrypted secure strings but does not provide managed rotation for credentials out of the box, so automated password rotation must be custom implemented.
-
Why not D? The
X-Amz-Security-Tokenis part of AWS temporary credentials (STS), not meant for storing or rotating database passwords.
The Technical Blueprint #
# Example CLI command to create a secret with rotation enabled (assuming RDS MySQL)
aws secretsmanager create-secret \
--name DevCo/dbProdCredentials \
--secret-string '{"username":"admin","password":"password123"}' \
--description "Prod DB credentials for Lambda" \
--kms-key-id alias/aws/secretsmanager
# Enable managed rotation (rotation Lambda provided by Secrets Manager)
aws secretsmanager rotate-secret \
--secret-id DevCo/dbProdCredentials \
--rotation-lambda-arn arn:aws:lambda:region:account-id:function:SecretsManagerRotationLambda \
--rotation-rules AutomaticallyAfterDays=30
The Comparative Analysis #
| Option | API Complexity | Performance | Use Case |
|---|---|---|---|
| A | Very Low (Env vars direct) | Fast access, no API calls | Simple, but insecure, no auto rotation |
| B | Moderate (Secrets Manager SDK calls) | Minimal latency, secure | Best practice for secret rotation and security |
| C | Moderate (Parameter Store calls) | Slightly slower due to API calls | Secure storage without built-in rotation |
| D | Misuse of Security Token | Not applicable | Invalid approach for secrets storage |
Real-World Application (Practitioner Insight) #
Exam Rule #
For the exam, always pick AWS Secrets Manager when you see automatic secret rotation as a hard requirement.
Real World #
In some non-critical cases, Parameter Store Secure Strings are sufficient if rotation is handled externally. But for production-grade secrets, Secrets Manager’s managed rotation greatly reduces operational burden and risk.
(CTA) Stop Guessing, Start Mastering #
Disclaimer
This is a study note based on simulated scenarios for the DVA-C02 exam.