DOP-C02 Resilient Cloud Solutions 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.

• ✗

  Deploy a separate test environment with identical configuration and run load tests

  Why it's wrong here

  A separate test environment with identical configuration cannot reproduce the real production traffic mix, user behavior, or the state of dependent services (database, caches, third-party APIs) that create transient ALB latency. Provisioning and validating that environment takes time, and even perfectly matched hardware and software only models steady-state behavior, not the specific production incident metrics and access logs you need to compare against. Consequently, load-test results will not identify the actual request patterns or target responses causing the reported slowness.

• ✗

  Enable EC2 detailed monitoring and SSH into each instance to run top and iostat

  Why it's wrong here

  Enabling EC2 detailed monitoring gives CPU, memory, disk, and network utilization at 1-minute intervals, but those metrics ignore the HTTP layer entirely. SSH'ing into instances to run `top` or `iostat` only captures instantaneous snapshots, cannot correlate with historical ALB latency peaks, and is typically blocked by security groups or SSM policies in production. It also fails to reveal how the ALB distributes traffic across targets or whether a specific target is healthy and responding on the application side.

• ✓

  Enable detailed CloudWatch metrics on the ALB and analyze ALB access logs

  Why this is correct

  Enabling detailed CloudWatch metrics on the ALB provides high-frequency measurements such as TargetResponseTime, RequestCount, and TargetConnectionErrorCount, and analyzing ALB access logs offers per-request timestamps, target processing time, request time, client IP, and target status codes. This combination yields a historical, request-level view of latency from the client through the ALB to the target without adding any agents or scripts to the EC2 instances. It also lets you filter for slow requests, group by URL or target, and determine whether delay occurs in the ALB-to-target hop or in the target application itself.

• ✗

  Run tcpdump on all EC2 instances and analyze packet captures

  Why it's wrong here

  Running `tcpdump` on all EC2 instances captures raw packets at the network layer, so it adds substantial CPU, memory, and disk I/O overhead to production workloads, which can alter the very latency you are diagnosing. The capture volume under production traffic can easily reach tens of gigabytes per minute, requiring careful buffer tuning and time-consuming `tshark` or `tcpdump` analysis to aggregate connection and TLS-related timing. Because it operates outside the HTTP or application layer and lacks the ALB's view of request routing, it does not cleanly isolate request-level latency or provide the instant historical record that ALB metrics and logs offer.

Go deeper

Related to this question