Question 202 of 724
DVA-C02 Troubleshooting and Optimization Practice Question
A web application runs on Amazon EC2 instances behind an Application Load Balancer (ALB). During peak hours, users report receiving HTTP 503 (Service Unavailable) errors. The developer checks Amazon CloudWatch metrics and finds that the ALB's request count is high but below the limit, and the target group's healthy host count drops to zero intermittently. The Auto Scaling group for the instances is configured with a minimum of 2, maximum of 10, and a simple scaling policy to add 2 instances when CPU utilization exceeds 70% for 5 consecutive minutes. What is the most likely cause of the 503 errors?
⚠ Common exam trap
Watch out — candidates often assume 503 errors are always due to capacity limits (Option C) or misconfigured health checks (Option D), but the real issue is the cooldown period's impact on scaling responsiveness during rapid traffic spikes.
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 Auto Scaling group's cooldown period prevents new instances from being added quickly enough during rapid traffic spikes
The 503 errors occur because the simple scaling policy has a cooldown period (default 300 seconds) that prevents the Auto Scaling group from launching new instances during rapid traffic spikes. When CPU exceeds 70% for 5 minutes, the policy adds 2 instances, but the cooldown blocks further scaling actions until it expires, even if the newly launched instances are still initializing and the healthy host count drops to zero. This mismatch between traffic demand and scaling responsiveness causes the ALB to have no healthy targets, resulting in 503 errors.
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 Auto Scaling group's cooldown period prevents new instances from being added quickly enough during rapid traffic spikes
Why this is correct
During a rapid traffic spike, an Auto Scaling group's cooldown period, typically 300 seconds by default, prevents additional scaling activities from initiating immediately after a previous one. This delay means that even if the scaling policy is triggered multiple times, new instances cannot launch quickly enough to meet the escalating demand. Consequently, existing instances become overloaded and unhealthy, leading to 503 Service Unavailable errors as the application cannot process requests.
- ✗
The ALB's idle timeout is set too low, causing dropped connections
Why it's wrong here
An Application Load Balancer's idle timeout setting dictates how long a connection can remain inactive before the ALB closes it. If set too low, it can prematurely terminate long-lived or slow client connections, resulting in client-side connection errors or incomplete requests. However, this mechanism primarily affects individual connection persistence and does not directly cause a widespread 503 Service Unavailable error across an entire application due to a lack of healthy backend instances.
- ✗
The Auto Scaling group's maximum capacity of 10 is insufficient
Why it's wrong here
While a maximum capacity of 10 instances might seem limited for extremely high traffic, it is generally sufficient to handle significant loads for many web applications. The problem described, involving intermittent 503 errors during spikes, points more towards a responsiveness issue in scaling out rather than an absolute ceiling being hit. If the maximum were truly insufficient, the application would consistently return 503s once that limit was reached and sustained, not just during rapid, transient spikes.
- ✗
The health check grace period is preventing instances from being marked healthy
Why it's wrong here
The health check grace period in an Auto Scaling group provides a configurable window during which newly launched instances are not immediately subjected to health checks. This allows sufficient time for applications to fully initialize and become ready to serve traffic without being prematurely marked unhealthy. While an improperly configured grace period could delay new instances from joining the healthy pool, it would not cause existing, already healthy instances to suddenly become unhealthy and lead to widespread 503 errors during a traffic spike.
About these practice questions
Courseiva creates original exam-style practice questions with explanations and wrong-answer analysis. It does not publish real exam questions, exam dumps, or protected exam content. Learn why practice questions differ from exam dumps →
Last reviewed: Jun 11, 2026
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.
Question Discussion
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
Sign in to join the discussion.