DVA-C02 Deployment Practice Question
A company uses AWS Elastic Beanstalk to deploy a web application. The application uses an Amazon RDS database. The developer wants to ensure that the database connection string is not hard-coded in the application code. Which THREE methods can the developer use to pass the connection string securely? (Choose THREE.)
⚠ Common exam trap
DVA-C02 often tests the difference between secure secret storage (Secrets Manager, Parameter Store) and insecure embedding (config files, tags) — the trap is picking a config file because it 'isn't in the code' even though it is still in the deployment bundle.
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
✓
Use AWS Secrets Manager.
Option B is correct because AWS Secrets Manager is purpose-built to store and retrieve secrets such as database connection strings, supporting encryption at rest with KMS and fine-grained access via IAM, so the application can fetch the string at runtime instead of hard-coding it. Option C is correct because Elastic Beanstalk environment properties are injected into the application as environment variables (for example, RDS_HOSTNAME, RDS_USERNAME, RDS_PASSWORD that Beanstalk itself sets for attached RDS instances), letting the code read the connection string from the environment rather than embedding it. Option E is correct because AWS Systems Manager Parameter Store can hold the connection string as a SecureString parameter encrypted with KMS, and the application can retrieve it via the SSM API or the EC2/Beanstalk instance role. Option A is not appropriate because RDS tags are metadata for resource organization, cost allocation, and access control, not a secure mechanism for delivering secrets to an application. Option D is not appropriate because a configuration file inside the application bundle is still effectively hard-coded and travels with the source artifact, so it does not securely externalize the connection string.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Read the connection string from Amazon RDS tags.
Why it's wrong here
Amazon RDS tags are key-value metadata used for cost allocation, resource organization, and filtering—they are not exposed to the application at runtime. Even if the application reads tags via the RDS API, tags are stored in plaintext and visible to anyone with DescribeTags permission, making them unsuitable for a connection string containing credentials. Elastic Beanstalk also does not automatically inject RDS tags into environment variables, so this approach would require custom code and still leak the secret.
- ✓
Use AWS Secrets Manager.
Why this is correct
AWS Secrets Manager is purpose-built for this task: it stores the connection string as a secret encrypted by a KMS key, provides fine-grained access control through IAM policies, and natively supports automatic rotation for Amazon RDS credentials. The application can retrieve the secret at runtime using the AWS SDK, and you can even integrate it with Elastic Beanstalk via a custom resource or startup script. This minimizes human exposure and lets you change credentials without rebuilding or redeploying the application.
- ✓
Use Elastic Beanstalk environment properties.
Why this is correct
Elastic Beanstalk environment properties are key-value pairs defined in the environment configuration that Elastic Beanstalk injects into the application as environment variables. This keeps the connection string out of source code and the application bundle, making it a valid way to pass runtime configuration. However, these values are stored in plaintext within the environment configuration and are visible to anyone with access to the Elastic Beanstalk console or APIs, so they are less secure than a dedicated secret store.
- ✗
Store the connection string in a configuration file in the application bundle.
Why it's wrong here
Storing the connection string inside a configuration file that ships in the application bundle—for example, in the WAR or source zip—means the credential is embedded in the artifact that the environment deploys. This makes it easy for the secret to end up in version control, shared build outputs, or logs, and rotating the credential requires producing and deploying a new artifact. It violates the principle of separating configuration from code and is insecure.
- ✓
Use AWS Systems Manager Parameter Store.
Why this is correct
AWS Systems Manager Parameter Store supports SecureString parameters that are encrypted with AWS KMS, and access can be controlled with IAM policies just like Secrets Manager. It is a lightweight, cost-effective alternative for storing the connection string, and the application can retrieve it using the AWS SDK or have it written to the environment during deployment. Unlike Secrets Manager, it lacks built-in automatic rotation for RDS credentials, but it remains a credible way to keep the secret out of the application code.
Go deeper
Related to this question
About these practice questions
This DVA-C02 question is part of Courseiva's 1,135-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 →
Same concept, more angles
3 more ways this is tested on DVA-C02
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A company uses AWS Elastic Beanstalk to deploy a web application. The application requires a database connection string that is different for each environment (development, staging, production). The developer wants to set these values without hardcoding them in the application code. Which configuration method should the developer use?
medium- A.Use the .ebextensions configuration files with environment-specific snippet files
- ✓ B.Use environment properties in the Elastic Beanstalk console
- C.Use Amazon RDS within Elastic Beanstalk
- D.Use AWS Systems Manager Parameter Store with an IAM instance profile
Why B: Elastic Beanstalk environment properties allow you to inject configuration values (like database connection strings) into your application at deployment time without hardcoding them. These properties are set per environment in the Elastic Beanstalk console or via CLI, and the application retrieves them as environment variables, making them environment-specific. While database connection strings are sensitive, environment properties are the simplest configuration method within Elastic Beanstalk for such values. AWS Systems Manager Parameter Store (Option D) is more secure for secrets but is not a native Elastic Beanstalk feature and requires additional setup; the question specifically asks for a configuration method within Elastic Beanstalk's native capabilities.
Variation 2. A company is deploying a Node.js application on AWS Elastic Beanstalk. The application uses environment variables for configuration. The development team wants to ensure that the environment variables are not exposed in the source code or in the deployment logs. Which TWO actions should the team take? (Choose TWO.)
medium- A.Enable detailed logging for the Elastic Beanstalk environment and filter out sensitive data.
- B.Set environment variables using Elastic Beanstalk environment properties in the console.
- ✓ C.Store sensitive environment variables in AWS Systems Manager Parameter Store and retrieve them at runtime.
- ✓ D.Use AWS Secrets Manager to manage secrets and reference them in the application code.
- E.Embed the environment variables in the application package as a .env file.
Why C: Option C is correct because AWS Systems Manager Parameter Store provides a secure, centralized place to store configuration data and secrets, and the Node.js application can retrieve them at runtime using the AWS SDK or the Parameter Store API, keeping them out of source code and deployment logs. Option D is correct because AWS Secrets Manager is purpose-built for managing sensitive values such as credentials and API keys, and referencing secrets in code via the Secrets Manager API or SDK means the actual values are never embedded in the application package or printed in deployment logs. Option A is not appropriate because enabling detailed logging and filtering sensitive data still risks exposure and does not prevent secrets from being present in the environment or logs. Option B is not sufficient because Elastic Beanstalk environment properties are visible in the console and may appear in configuration outputs, so they do not meet the requirement of keeping sensitive values out of source code and logs. Option E is incorrect because embedding a .env file in the application package places the secrets directly in the deployment artifact, which is exactly what the team wants to avoid.
Variation 3. A developer is using AWS Elastic Beanstalk to deploy a Node.js application. The application requires an environment variable that contains a secret (e.g., a database password). The developer wants to store the secret securely and make it available to the application instances. Which Elastic Beanstalk feature should be used?
medium- A.Store the secret in an environment property with the value set in plaintext.
- ✓ B.Use the AWS Secrets Manager integration in Elastic Beanstalk.
- C.Use an .ebextensions configuration file to set the environment variable.
- D.Use Elastic Beanstalk platform hooks to retrieve the secret at startup.
Why B: To securely store and retrieve secrets (such as database credentials) in AWS Elastic Beanstalk, the best practice is to use a dedicated secrets management service like AWS Secrets Manager or AWS Systems Manager Parameter Store. The application's EC2 instances are assigned an IAM instance profile. By granting this instance profile permission to read the secret, the application code can securely retrieve the secret at runtime using the AWS SDK, avoiding the need to store sensitive information in plaintext in environment properties or source code.
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Amazon Web Services exam blueprint
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.