DVA-C02 Development with AWS Services Practice Question
A developer is deploying a web application using AWS Elastic Beanstalk. The application uses an Amazon RDS MySQL database. The developer wants to ensure that database credentials are not stored in the application code or environment variables. The solution must automatically rotate credentials every 90 days. The developer has created a secret in AWS Secrets Manager containing the database credentials. The Elastic Beanstalk environment is configured with an IAM instance profile that has permission to read the secret. However, when the application is deployed, it fails to connect to the database. The developer checks the application logs and sees a 'Host not found' error. The RDS instance is in a private subnet, and the Elastic Beanstalk environment is in the same VPC. What is the MOST likely cause of the connection failure?
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
✓
The application code is not retrieving the secret from Secrets Manager at startup.
The correct option is B: the application code is not retrieving the secret from Secrets Manager at startup. Since the credentials are no longer in code or environment variables, the app must call the Secrets Manager API (e.g., GetSecretValue) at runtime to obtain the DB host, username, and password; if it never does so, it has no host to resolve, producing the 'Host not found' error. Option A is wrong because environment properties are explicitly not used for credentials here, and the failure is a missing hostname, not a misreferenced property. Option C is wrong because the instance profile already has read permission to the secret, so an access-denied error would occur instead. Option D is wrong because a cross-region secret would cause an access/not-found error for the secret, not a 'Host not found' database connection error.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The secret is not correctly referenced in the Elastic Beanstalk environment properties.
Why it's wrong here
Elastic Beanstalk environment properties are primarily for passing configuration values to the application, such as database endpoints or feature flags. While you could store the ARN of a Secrets Manager secret in an environment property, this merely provides the *identifier*. The application code itself must still explicitly use this ARN to make an AWS SDK call to the Secrets Manager service (e.g., GetSecretValue) to retrieve the actual secret content. Simply referencing the secret's ARN in environment properties does not automatically inject the secret's value into the application's runtime.
- ✓
The application code is not retrieving the secret from Secrets Manager at startup.
Why this is correct
For an application running on Elastic Beanstalk to utilize a secret stored in AWS Secrets Manager, its code must contain specific logic to programmatically fetch that secret. This involves using an AWS SDK to instantiate a Secrets Manager client and then calling the GetSecretValue API operation, passing the secret's ARN or name. If this retrieval step is missing or improperly implemented, the application will attempt to connect to the database with undefined or placeholder credentials, inevitably leading to authentication failures.
- ✗
The IAM instance profile does not have the necessary permissions to access the secret.
Why it's wrong here
The problem statement explicitly indicates that the developer has already verified the IAM instance profile associated with the Elastic Beanstalk environment possesses the necessary secretsmanager:GetSecretValue permissions. Therefore, attributing the database connection failure to insufficient IAM permissions directly contradicts the given information. While incorrect permissions are a common troubleshooting point, in this specific scenario, we must assume this aspect is correctly configured.
- ✗
The secret is stored in a different region than the Elastic Beanstalk environment.
Why it's wrong here
While it is generally a best practice to store Secrets Manager secrets in the same AWS region as the consuming application, it is technically possible for an application to retrieve a secret from a different region. This requires the application's AWS SDK client for Secrets Manager to be explicitly configured with the correct target region. The problem description does not provide any details suggesting a region mismatch or a misconfigured SDK client, so this cannot be assumed as the root cause of the connection issue.
Visual reference
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 →
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.