DVA-C02 Deployment Practice Question
A developer is deploying an application on Amazon ECS using the Fargate launch type. The application needs to read configuration data from an Amazon S3 bucket. How should the developer securely provide the S3 bucket name to the container at runtime?
⚠ Common exam trap
The trap here is that candidates often over-engineer the solution by choosing AWS Systems Manager Parameter Store for all configuration data, even when the value is not sensitive and a simpler environment variable suffices, leading to unnecessary complexity and potential startup delays.
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
✓
Define an environment variable in the ECS task definition with the bucket name.
Defining an environment variable in the ECS task definition is the simplest and most secure way to inject the S3 bucket name into the container at runtime. Environment variables are passed to the container when it starts, and they can be stored in the task definition itself or referenced from AWS Secrets Manager or Systems Manager Parameter Store for sensitive values. This approach avoids hardcoding and keeps the configuration decoupled from the application code.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Define an environment variable in the ECS task definition with the bucket name.
Why this is correct
Defining the bucket name as an environment variable within the ECS task definition is the recommended practice for injecting configuration. This approach decouples the application code from environment-specific details, allowing the same container image to be used across development, staging, and production environments. The containerized application can then easily access this value at runtime through standard environment variable retrieval mechanisms, promoting flexibility and maintainability without requiring code changes or image rebuilds.
- ✗
Hardcode the bucket name in the application code.
Why it's wrong here
Hardcoding the S3 bucket name directly into the application code is a poor practice that introduces significant operational and security risks. It tightly couples the application to a specific environment, making it difficult to deploy across different stages (e.g., dev, prod) without modifying and recompiling the code. Furthermore, hardcoding sensitive or environment-specific values can lead to security vulnerabilities if the code repository is compromised, and it necessitates a full redeployment for any configuration change.
- ✗
Use AWS Systems Manager Parameter Store and retrieve the bucket name at startup.
Why it's wrong here
Using AWS Systems Manager Parameter Store to retrieve the bucket name at startup is a secure method for storing configuration, but it typically requires the application code to make an API call to Parameter Store. While secure, this approach adds complexity by coupling the application directly to the Parameter Store API and requiring the container's IAM role to have `ssm:GetParameter` permissions. Parameter Store is excellent for centralising application configuration and secrets, and it would be a correct choice if the question were about *where* to store the bucket name securely, especially when combined with ECS task definitions that inject these values as environment variables directly into the container, decoupling the application from the retrieval mechanism.
- ✗
Store the bucket name in the container image's environment file.
Why it's wrong here
Storing the S3 bucket name within an environment file embedded inside the container image itself is inflexible and counterproductive to containerization principles. Any change to the bucket name, even a minor one, would necessitate rebuilding the entire Docker image and redeploying it, which is inefficient and slows down development cycles. This method also tightly couples the image to a specific configuration, hindering its reusability across different environments without creating multiple image variants.
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
One of 724 original DVA-C02 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.