Courseiva
Monitoring and Logging →mediumMultiple Choice

Using AWS X-Ray to Pinpoint Microservice Latency

A DevOps team is troubleshooting a slow application. They enabled AWS X-Ray tracing and see that one of the downstream services has a high average response time. However, the traces show that the service itself is fast; the delay is in the network call from the upstream service. Which X-Ray feature should the team use to identify the root cause?

⚠ Common exam trap

The trap here is that candidates might focus on the downstream service's segment (Option C) thinking the delay is inside that service, when the trace map is specifically designed to reveal inter-service communication latency that is not captured by individual segment durations.

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

✓

Examine the trace map to see the connection between services.

The trace map in AWS X-Ray provides a visual representation of the service graph, showing the connections and latency between services. Since the delay is in the network call from the upstream service to the downstream service, the trace map can highlight the specific edge where the high latency occurs, allowing the team to pinpoint whether the issue is due to network congestion, DNS resolution, or a slow HTTP connection. This is the most direct way to identify the root cause of the inter-service communication delay.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • ✓

    Examine the trace map to see the connection between services.

    Why this is correct

    The AWS X-Ray trace map is the correct tool because it visualizes each service as a node and the connections between them as edges, with latency metrics for each edge. This directly reveals whether the identified slowness stems from network communication between services (for example, high I/O wait or retries) rather than from code execution inside a single service, allowing the DevOps team to pinpoint the exact segment of the request path that is underperforming.

  • ✗

    Add annotations to the traces for better filtering.

    Why it's wrong here

    Annotations in X-Ray are user-defined key-value pairs attached to segments or subsegments for the purpose of indexing, searching, and filtering traces; they do not capture or display timing data for the network hops between services. Adding annotations would only help you retrieve traces that meet certain criteria after the fact, but it provides no visibility into where latency is introduced along the service boundary — making it an auxiliary tool for trace organization, not a diagnostic aid for slow inter-service communication.

  • ✗

    View the raw segments of the upstream service.

    Why it's wrong here

    Viewing the raw segments of the upstream service shows the internal work performed within that service (e.g., database queries, local processing, and subsegment timing) but stops at the point where the service sends its response. It does not include the time spent on the wire or the network round-trip between the upstream and downstream services, so it cannot reveal connection-level latency such as packet loss, DNS resolution issues, or load balancer delays that occur outside the service's own execution context.

  • ✗

    Adjust the sampling rules to capture more traces.

    Why it's wrong here

    Adjusting sampling rules changes the proportion of requests that are recorded by X-Ray, which controls trace volume and cost but has no bearing on the analysis of a specific latency problem in an already-captured trace. Even if you increase the sampling rate, you are simply recording more of the same type of trace data; the information needed to diagnose the slow connection (the per-http-edge latency metrics) is still only available through the trace map, and changing sampling rules will not add any dimensions of diagnostic visibility to the existing traces.

Visual reference

Client Recursive Resolver Root DNS (13 root servers) TLD DNS (.com, .org, …) Authoritative example.com query IP addr answer

About these practice questions

This DOP-C02 question is part of Courseiva's 1,298-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 →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This DOP-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 DOP-C02 exam.