Using AWS X-Ray to Break Down API Latency per Endpoint in Microservices
A company is running a microservices application on Amazon ECS with AWS Fargate. The operations team needs to monitor application performance and troubleshoot slow API responses. They currently use Amazon CloudWatch Logs for container logs and have enabled Container Insights. However, they are unable to see detailed latency breakdowns per API endpoint. Which solution would provide the most granular visibility into API performance?
Quick Answer
The answer is AWS X-Ray, as it provides the most granular visibility into API latency breakdown per endpoint in microservices. Unlike CloudWatch Logs or Container Insights, which offer aggregated metrics or log-based queries, X-Ray captures end-to-end trace data as requests travel through distributed services on Amazon ECS with Fargate, revealing detailed latency contributions from downstream calls, database queries, and external HTTP requests. On the AWS Certified DevOps Engineer Professional DOP-C02 exam, this question tests your ability to distinguish between monitoring tools that show high-level health versus those that pinpoint root causes of slow responses—a common trap is choosing CloudWatch Logs Insights, which requires manual correlation and lacks automatic trace segmentation. Remember the mnemonic: X-Ray eXposes the exact path—each hop in your microservices gets a detailed latency stamp, making it the only tool that breaks down API performance endpoint by endpoint.
⚠ Common exam trap
Test-takers frequently confuse infrastructure-level metrics (CPU, memory, network) or log-based querying with the distributed tracing capability needed to break down latency per API endpoint, overlooking that only X-Ray provides end-to-end trace segments with sub-millisecond timing per service call.
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
✓
Use AWS X-Ray to instrument the application and collect trace data.
AWS X-Ray provides end-to-end tracing of requests as they travel through microservices, capturing detailed latency breakdowns per API endpoint, including downstream calls, database queries, and external HTTP requests. This gives the operations team the granular visibility needed to pinpoint exactly where slow responses occur, unlike aggregated metrics or log-based queries.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Enable detailed CloudWatch metrics for ECS and Fargate, including CPU and memory.
Why it's wrong here
Detailed ECS and Fargate metrics report task-level CPU, memory and network utilisation, which cannot attribute latency to individual API endpoints. It is tempting because resource saturation often causes slow responses, and these metrics would be correct when diagnosing whether a task is throttled or under-provisioned.
- ✗
Enable CloudWatch Logs Insights to query API logs for slow requests.
Why it's wrong here
Logs Insights queries existing log fields, so it can only surface endpoint latency if the application already emits per-request timing; it adds no instrumentation itself. It is tempting because it interrogates logs without code changes, and would be correct where structured request-duration fields are already being written.
- ✓
Use AWS X-Ray to instrument the application and collect trace data.
Why this is correct
X-Ray traces individual requests across microservices, producing segment and subsegment timings that break latency down per API endpoint and downstream call. Container Insights only aggregates task and service metrics, so it cannot satisfy the stem's requirement for granular per-endpoint latency visibility.
- ✗
Deploy the AWS Distro for OpenTelemetry collector on each task to send metrics to CloudWatch.
Why it's wrong here
Deploying the AWS Distro for OpenTelemetry (ADOT) collector to send metrics to CloudWatch is insufficient for detailed API latency breakdowns per endpoint. CloudWatch Metrics stores time-series data, not the interconnected span data required for distributed tracing across microservices to pinpoint latency sources. This option is tempting because ADOT is the correct tool for collecting various telemetry types, including application metrics and traces. It would be appropriate for gathering custom application metrics or if the question specified sending traces to a service like AWS X-Ray for detailed analysis.
- ✗
Set up VPC Flow Logs to analyze network latency between services.
Why it's wrong here
VPC Flow Logs record accepted and rejected IP traffic metadata, exposing network-level reachability and retransmits rather than application-layer per-endpoint latency. It is tempting because flow data diagnoses connectivity and packet loss, and would be the right choice when services cannot reach each other or security groups block traffic.
Go deeper
Related to this question
About these practice questions
Courseiva writes every DOP-C02 question from scratch — 1,298 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
3 more ways this is tested on DOP-C02
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A company runs a microservices application on Amazon ECS with Fargate. The operations team notices that some services are experiencing intermittent high latency, but CPU and memory metrics appear normal. They need to identify the root cause. Which approach should they use?
hard- A.Enable detailed CloudWatch Logs and use CloudWatch Logs Insights to query logs for slow requests.
- B.Use Amazon Managed Service for Prometheus to collect custom metrics and set up dashboards.
- C.Set up CloudWatch Synthetics canaries to monitor the endpoints and measure response times.
- ✓ D.Instrument the application with the AWS X-Ray SDK and use the X-Ray console to analyze traces.
Why D: Intermittent latency with normal CPU and memory metrics points to a distributed tracing problem — the bottleneck is likely in a downstream call, a network hop, or a specific service in the request chain. AWS X-Ray traces requests end-to-end across ECS tasks, Lambda functions, and downstream services, showing exactly where time is spent. This makes it the right tool to pinpoint the root cause of intermittent latency in a microservices architecture.
Variation 2. A company runs a serverless application using AWS Lambda, Amazon API Gateway, and Amazon DynamoDB. The application is used by thousands of users. Recently, the operations team noticed an increase in 5xx errors from API Gateway. The team has enabled CloudWatch Logs for the Lambda functions and API Gateway. They see the errors are sporadic and not correlated with high traffic. The Lambda function's error count in CloudWatch is also increasing. The team wants to identify the specific requests that are failing and understand the error details. Which solution should the team implement?
medium- A.Use CloudWatch Logs Insights to query the Lambda logs for ERROR messages and correlate with API Gateway logs
- B.Enable VPC Flow Logs for the Lambda function's VPC to capture network traffic
- ✓ C.Enable AWS X-Ray active tracing on the Lambda functions and API Gateway to capture detailed request traces and error details
- D.Enable AWS CloudTrail to log API Gateway API calls and analyze the logs
Why C: AWS X-Ray active tracing on Lambda and API Gateway captures end-to-end request traces, including downstream calls to DynamoDB, latency breakdowns, and exception details for each failing invocation. Because the errors are sporadic and not traffic-correlated, X-Ray's per-request trace view is the fastest way to pinpoint which specific requests fail and why. CloudWatch Logs alone would require manual correlation across services and lacks the trace context X-Ray provides.
Variation 3. A company runs a serverless application using AWS Lambda and Amazon API Gateway. The application processes user uploads to an S3 bucket. The operations team uses CloudWatch Logs for monitoring, but they are finding it difficult to correlate logs across multiple Lambda functions that handle different parts of the workflow. The team wants to trace requests as they flow through the application and identify bottlenecks or errors. The team has already enabled CloudWatch Logs for all Lambda functions. What should the team do to achieve end-to-end request tracing?
medium- A.Use CloudWatch Contributor Insights to analyze the log data and identify the top contributors to latency.
- B.Use AWS CloudTrail to log all API calls and correlate them with CloudWatch Logs.
- C.Create a CloudWatch ServiceLens service map to visualize the application components.
- ✓ D.Enable AWS X-Ray on the Lambda functions and API Gateway to trace requests end-to-end.
Why D: AWS X-Ray is the native distributed tracing service that integrates with Lambda and API Gateway to trace requests end-to-end across services. Enabling X-Ray on the Lambda functions and API Gateway propagates a trace ID through the workflow, letting the team visualize the full request path, latency per segment, and errors. CloudWatch ServiceLens can then surface the X-Ray traces alongside logs and metrics for correlation.
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.