DVA-C02 Development with AWS Services Practice Question
A company is using AWS Elastic Beanstalk to deploy a web application. The application uses an Amazon RDS MySQL database. The development team wants to ensure that database credentials are not exposed in the application code. Which THREE actions should the team take to securely manage and retrieve database credentials? (Choose three.)
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Configure Elastic Beanstalk to pass the secret ARN to the application as an environment property.
To securely manage database credentials in Elastic Beanstalk, the team should store credentials in AWS Secrets Manager (option E). Then, configure Elastic Beanstalk to pass the secret ARN as an environment property (option B) so the application can retrieve the secret at startup (option C). This avoids hardcoding credentials in code or environment variables. Option A (S3 bucket) is less secure and not best practice; Option D (hardcoding) is insecure and should never be done.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Store the credentials in an S3 bucket with a bucket policy that restricts access to the application.
Why it's wrong here
Storing database credentials in an S3 bucket with a restrictive bucket policy is not a secure or appropriate design because S3 is an object storage service, not a purpose-built secrets manager. Even with a policy that limits access to the application, the credentials remain plaintext objects, lack automated rotation, and require you to manage separate IAM roles or access keys for every consumer. AWS Secrets Manager exists specifically for this use case, offering built-in encryption, rotation, and audit integration with other AWS services.
- ✓
Configure Elastic Beanstalk to pass the secret ARN to the application as an environment property.
Why this is correct
Passing the secret ARN as an environment property in Elastic Beanstalk is a secure pattern because the actual credential value is never embedded in code or environment configuration. The application retrieves the secret from AWS Secrets Manager at runtime using the ARN, while the Elastic Beanstalk instance profile supplies the necessary IAM permissions. This keeps the secret itself hidden and ensures the application always uses the current value, even if the secret is rotated.
- ✓
Modify the application code to retrieve the credentials from Secrets Manager at startup.
Why this is correct
Modifying the application code to retrieve the database credentials from AWS Secrets Manager at startup is a runtime-based approach that works well when you want to avoid putting secret material in configuration files. The application uses the AWS SDK to call GetSecretValue or a similar API, with permissions coming from the IAM role attached to the Elastic Beanstalk instances. This gives you fine-grained control over when and how secrets are fetched, and you can cache the secret in memory to reduce API calls and cost.
- ✗
Hardcode the credentials in the application code and use environment variables to override them.
Why it's wrong here
Hardcoding database credentials in application code is fundamentally insecure because the secrets remain visible in source control and are extremely difficult to rotate or revoke without redeploying code. Even if environment variables are allowed to override the hardcoded defaults, the hardcoded values are still an exposure, and environment variables are also visible to anyone with access to the Elastic Beanstalk environment configuration. This approach completely negates the benefits of using a managed secrets service like AWS Secrets Manager.
- ✓
Store the database credentials in AWS Secrets Manager.
Why this is correct
Storing database credentials in AWS Secrets Manager is the correct first step for this scenario because it centralizes secret material in a dedicated service with encryption at rest, automatic rotation for supported AWS services like RDS, and granular IAM access control. Secrets Manager also integrates directly with Elastic Beanstalk via the instance role, making it easy for the application to retrieve the latest credentials without embedding them in the deployment bundle. This directly addresses the security concern of hardcoded credentials while enabling ongoing rotation and revocation.
Quick reference
AWS S3 Storage Class Comparison
| Storage Class | Min Duration | Retrieval | Use Case |
|---|---|---|---|
| S3 Standard | None | Immediate | Frequently accessed data |
| S3 Standard-IA | 30 days | Immediate | Infrequent access, rapid retrieval |
| S3 One Zone-IA | 30 days | Immediate | Non-critical infrequent data |
| S3 Intelligent-Tiering | None | Immediate–hours | Unknown or changing access patterns |
| S3 Glacier Instant | 90 days | Milliseconds | Archive with instant retrieval |
| S3 Glacier Flexible | 90 days | Minutes–hours | Archive, flexible retrieval |
| S3 Glacier Deep Archive | 180 days | Hours | Long-term compliance archive |
Go deeper
Related to this question
About these practice questions
This DVA-C02 question is part of Courseiva's 724-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This DVA-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DVA-C02 exam.