DVA-C02 Development with AWS Services Practice Question
A developer is deploying a microservices architecture on Amazon ECS with Fargate. Each service needs to store sensitive configuration data such as database passwords. The developer wants to avoid hardcoding secrets in the application code. Which approach should the developer use?
⚠ Common exam trap
Watch out — candidates often choose Option B (environment variables in the task definition) because it seems simple and works in development, but they overlook that the task definition is stored in plaintext and accessible via the ECS API, making it insecure for production secrets.
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
✓
Store the secrets in AWS Systems Manager Parameter Store or AWS Secrets Manager and reference them in the ECS task definition using the 'secrets' parameter.
AWS Systems Manager Parameter Store and AWS Secrets Manager are purpose-built services for securely storing and managing sensitive configuration data. By referencing secrets via the `secrets` parameter in the ECS task definition, the secrets are injected into the container at runtime without being exposed in the application code, task definition plaintext, or Docker image. This approach integrates natively with ECS Fargate and supports automatic rotation of secrets.
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 secrets in an Amazon S3 bucket and use a pre-signed URL to download them at startup.
Why it's wrong here
Storing secrets in an Amazon S3 bucket, even with pre-signed URLs, is not a secure secrets management solution. S3 is an object storage service, not designed for the lifecycle management, rotation, or fine-grained access control typically required for sensitive secrets. Relying on pre-signed URLs introduces additional complexity in managing URL expiry and access, and the secrets themselves remain static objects without the inherent security features of dedicated secret management services.
- ✗
Define the secrets as environment variables in the ECS task definition.
Why it's wrong here
Defining secrets directly as environment variables in an ECS task definition is a significant security vulnerability. These variables are plainly visible to anyone with permissions to view the task definition and can also appear in container logs, making them susceptible to accidental disclosure or unauthorized access. This method bypasses secure secret injection mechanisms and is not compliant with best practices for handling sensitive information in production environments.
- ✗
Encrypt the secrets using AWS KMS and store the encrypted blob in a configuration file within the Docker image.
Why it's wrong here
While encrypting secrets with AWS KMS is a good practice, storing the encrypted blob directly within a Docker image or a configuration file inside the image still presents security risks. The encrypted data becomes a static artifact within the image, meaning if the image itself is compromised or accessed, the encrypted secret is exposed. This approach also complicates secret rotation and management, as any change would necessitate rebuilding and redeploying the entire Docker image.
- ✓
Store the secrets in AWS Systems Manager Parameter Store or AWS Secrets Manager and reference them in the ECS task definition using the 'secrets' parameter.
Why this is correct
This is the most secure and recommended approach for managing secrets in ECS. AWS Systems Manager Parameter Store (especially `SecureString` parameters) and AWS Secrets Manager are purpose-built services for securely storing and managing sensitive data. By referencing these services in the ECS task definition's `secrets` parameter, ECS automatically retrieves and injects the secrets into the container's environment at runtime, leveraging the task's IAM role for secure, granular access. This ensures secrets are never hardcoded, are not visible in task definitions or logs, and can be rotated independently of application deployments.
Go deeper
Related to this question
About these practice questions
Courseiva writes every DVA-C02 question from scratch — 724 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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.