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.)
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.
To pass the database connection string securely without hard-coding it, developers can use AWS Secrets Manager (B) to store and retrieve secrets programmatically, Elastic Beanstalk environment properties (C) to inject configuration into the application environment, and AWS Systems Manager Parameter Store (E) to securely store strings and secrets. Option A is incorrect because RDS tags are not designed for sensitive data like connection strings. Option D is incorrect because storing the connection string in a configuration file within the application bundle would expose it in the source code and deployment package.
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 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 →
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: Options C and D are correct. Storing environment variables in AWS Systems Manager Parameter Store (C) or AWS Secrets Manager (D) prevents exposure in source code or logs, as they are retrieved at runtime via SDK calls. Option A (detailed logging) does not prevent exposure; it may actually log the values. Option B (Elastic Beanstalk environment properties) stores values in plaintext in the environment configuration, which can be viewed. Option E (embedding in .env file) exposes them in the source code and deployment artifacts.
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 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.