DOP-C02 Monitoring and Logging Practice Question

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 has too many instances, causing increased network overhead

  Why it's wrong here

  This misidentifies the scaling dynamic: an Application Load Balancer distributes each request to the least loaded healthy target, so adding instances generally reduces per-instance queueing and lowers response latency, not increases it. Only if the application performs heavy inter-instance communication or relies on a shared stateful store would more nodes add meaningful overhead, but that is not inherent to Auto Scaling. Network overhead from additional instances is negligible compared to the latency caused by a slow downstream dependency.

• ✗

  The ALB is routing requests to instances in different Availability Zones, increasing latency

  Why it's wrong here

  For an Application Load Balancer, cross-zone load balancing is enabled by default, meaning each ALB node actively distributes requests to healthy targets across all Availability Zones in the region. Within a region, AZ-to-AZ traffic travels over AWS's redundant, high-bandwidth backbone—typically adding less than a millisecond—so it cannot be the source of a perceptible slowdown. A request would have to cross regions to experience real network latency impact, which is not the case here.

• ✓

  The application is waiting on a slow database query or external API call

  Why this is correct

  Synchronous dependencies like database queries and external API calls are the classic cause of elevated application latency; the end-user response time becomes the sum of all blocking calls in the request path, and a single slow query (e.g., missing index, lock contention, or throttled API) holds up the entire page. This pattern usually shows as high response times with low CPU and network utilization on the application instances, because threads are parked waiting for the downstream I/O to complete. In an Auto Scaling environment, simply adding instances won't help while the database or API service remains the bottleneck.

• ✗

  The ALB idle timeout is set too low, causing connections to be dropped

  Why it's wrong here

  ALB idle timeout controls how long a connection may remain inactive before the load balancer closes it; setting it too low would terminate idle keep-alive connections, causing clients to see connection resets or 502/504 errors on the next request—not high latency during an active request. The timeout does not affect how quickly an in-flight request is processed, since it is based on inactivity, not request duration. Therefore, a low idle timeout cannot explain a slow web application; it would manifest as sporadic connectivity failures instead.

Go deeper

Related to this question