DOP-C02 Monitoring and Logging Practice Question
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?
⚠ Common exam trap
DOP-C02 often tests the distinction between metrics, logs, and traces — candidates pick CloudWatch Logs or Prometheus because they sound comprehensive, but only X-Ray provides the per-request, cross-service causality needed to diagnose intermittent latency.
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
✓
Instrument the application with the AWS X-Ray SDK and use the X-Ray console to analyze traces.
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.
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 Logs and use CloudWatch Logs Insights to query logs for slow requests.
Why it's wrong here
CloudWatch Logs Insights can query application logs for slow requests, but logs are typically uncorrelated across services and lack a trace ID to stitch a single end-to-end request path. While you could manually search for timestamps, this approach cannot reveal internal service-to-service latencies or dependencies. Without propagation of a correlation identifier, you cannot accurately pinpoint which downstream call added the most delay.
- ✗
Use Amazon Managed Service for Prometheus to collect custom metrics and set up dashboards.
Why it's wrong here
Amazon Managed Service for Prometheus collects and stores time-series metric data, enabling dashboards and alerts for aggregate trends like average latency or error rates. However, metrics are aggregated and strip away request-level detail, so they cannot trace an individual request through multiple microservices or show per-service segment latency. Prometheus dashboards show the big picture but are blind to the specific path and bottleneck within a request.
- ✗
Set up CloudWatch Synthetics canaries to monitor the endpoints and measure response times.
Why it's wrong here
CloudWatch Synthetics canaries are scripted monitors that exercise HTTP endpoints from outside the application, measuring availability and response times from a customer perspective. While they can detect that an endpoint is slow, they cannot observe the internal calls that occur inside the VPC or container network—such as service-to-service invocations, database queries, or cache lookups. Thus they are useful for black-box monitoring but cannot identify which internal service causes the slowdown.
- ✓
Instrument the application with the AWS X-Ray SDK and use the X-Ray console to analyze traces.
Why this is correct
Instrumenting with the AWS X-Ray SDK is the correct approach because X-Ray traces individual requests as they traverse services, generating a trace ID that propagates across HTTP headers and AWS SDK client calls. The X-Ray console provides a service map and trace timelines, segment and subsegment views that break down latency for each downstream call, letting you pinpoint the exact service or resource causing the slowdown. You can also annotate traces with request metadata and set sampling rules to balance overhead and observability.
Quick reference
Cloud Service Model Comparison
| Model | You Manage | Provider Manages | Examples |
|---|---|---|---|
| IaaS | OS, runtime, apps, data | Hardware, hypervisor, networking | EC2, Azure VMs, GCP Compute Engine |
| PaaS | Apps and data | OS, runtime, middleware, hardware | Elastic Beanstalk, Azure App Service |
| SaaS | Data and settings only | Everything else | Microsoft 365, Salesforce, Workday |
| FaaS / Serverless | Function code only | Infra, scaling, runtime | Lambda, Azure Functions, Cloud Run |
| CaaS | Containers and apps | Kubernetes, OS, hardware | EKS, AKS, GKE |
Go deeper
Related to this question
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 →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Amazon Web Services exam blueprint
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.