DVA-C02 Deployment Practice Question
A company is using AWS CodeDeploy to deploy a web application to an Auto Scaling group. The deployment fails with the error: 'The overall deployment failed because too many individual instances failed deployment, too few healthy instances are available, or some instances in your deployment group are experiencing problems.' The application is deployed to a t2.micro instance with 1 GB of RAM. The deployment uses an in-place update with a deployment configuration that has a minimum of 1 healthy host. What is the most likely cause of the 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 uses too much memory, causing the instance to become unhealthy during deployment.
The most likely cause is option A: the application uses too much memory, causing the instance to become unhealthy during deployment. The t2.micro instance has only 1 GB of RAM. If the web application consumes significant memory, deploying a new version can trigger out-of-memory (OOM) errors, leading the instance to fail health checks. The deployment configuration requires a minimum of 1 healthy host, so when the instance becomes unhealthy, the deployment fails with the error about too few healthy instances. Option B (insufficient disk space) is unlikely because t2.micro instances typically have at least 8 GB of EBS storage, which is usually sufficient for downloading application revisions. Option C (CodeDeploy agent timeout) would produce a different error, such as 'deployment timed out,' not a message about healthy instances. Option D (insufficient IAM permissions) would result in authorization failures, such as 'AccessDenied' errors, not a health-related failure. Therefore, memory exhaustion due to the small instance size is the best explanation.
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 application uses too much memory, causing the instance to become unhealthy during deployment.
Why this is correct
A t2.micro instance has only 1 GB of RAM, which is a very limited resource for many modern web applications. If the application, especially during startup or initial load after deployment, consumes memory beyond this capacity, the operating system may become unresponsive or critical services could crash. This resource exhaustion would cause the instance's health checks, monitored by CodeDeploy and potentially an associated Load Balancer or Auto Scaling Group, to fail, leading to a deployment rollback or failure.
- ✗
The instance does not have enough disk space to download the application revision.
Why it's wrong here
While a t2.micro instance typically comes with a default 8 GB EBS root volume, this is generally sufficient for downloading and storing most application revisions for web applications. A disk space issue would manifest as a 'No space left on device' error during the download or installation phase, rather than a health check failure after the application attempts to start. CodeDeploy would report a lifecycle event hook failure related to disk operations, not an instance health status change.
- ✗
The CodeDeploy agent timed out because the deployment took longer than 30 minutes.
Why it's wrong here
A CodeDeploy agent timeout typically occurs if a deployment step, such as a lifecycle event hook script, runs for an excessively long period without completing, exceeding the configured timeout (default 60 minutes, not 30). This would result in a specific 'Script timed out' or 'Deployment timed out' error message in the CodeDeploy console and logs, distinct from an instance health check failure. The problem statement indicates an unhealthy instance, not a script execution timeout.
- ✗
The IAM role for the CodeDeploy agent does not have sufficient permissions to deploy the application.
Why it's wrong here
Insufficient IAM permissions for the CodeDeploy agent would typically manifest as 'Access Denied' errors when the agent attempts to perform AWS API calls, such as downloading the application revision from S3 or interacting with other AWS services. These errors would be explicitly logged by the CodeDeploy agent and reported in the deployment events, indicating a permission failure rather than the instance becoming unhealthy due to application behavior. The deployment would likely fail early in the process.
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
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.