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.

• ✗

  Use CloudWatch Logs Insights to query container logs

  Why it's wrong here

  CloudWatch Logs Insights is a query engine for searching and analyzing log event payloads, so it can reveal application errors or response codes, but it does not natively ingest or correlate numeric time-series metrics like ECS CPU utilization, nor can it join those logs to X-Ray trace segments. To triangulate a problem you would need to manually export timestamps, metric data, and trace IDs, which misses the point of a unified observability correlation. This makes it a poor choice for directly linking a container's CPU spike to a specific request trace.

• ✓

  Enable Container Insights and ServiceLens to correlate metrics and traces

  Why this is correct

  For Fargate, Container Insights must be enabled to collect infrastructure telemetry such as CPU and memory utilization at the cluster, service, task, and container levels; AWS then ships these metrics to CloudWatch automatically. ServiceLens builds on that by combining CloudWatch metrics, logs, and X-Ray traces into a single service map and console, allowing you to select a trace and see the corresponding CPU/memory metric trends for that underlying container. This native integration is exactly what is required to prove whether a CPU saturation event is causing an observed latency increase in a traced request.

• ✗

  Configure CloudWatch Synthetics canaries to measure latency

  Why it's wrong here

  CloudWatch Synthetics canaries are scheduled Node.js or Python scripts that simulate end-user requests against public or internal HTTP endpoints, measuring availability, latency, and screenshot capture; they do not expose container-level CPU or memory metrics at all. Even if a canary runs inside a VPC and hits an internal load balancer, the result is a black-box external measurement of response time, not a host or task-level CPU telemetry feed. Therefore, while it can detect a slowdown, it cannot identify that the cause is the ECS container's CPU saturation, and it cannot associate a trace with that metric.

• ✗

  Set up a Prometheus server on an EC2 instance to scrape container metrics

  Why it's wrong here

  Standing up a Prometheus server on an EC2 instance means self-managing service discovery, scrape targets, persistent storage, retention policies, and alerting infrastructure, which is far more operational overhead than the AWS-native Container Insights and ServiceLens combination. Additionally, Prometheus metrics are just one part of observability; you would still need a separate tracing solution like AWS X-Ray and build your own correlation mechanism between the Prometheus CPU gauge and trace IDs. AWS offers a managed Prometheus-compatible service, but for this scenario the native CloudWatch and X-Ray integration yields correlated metrics and traces without additional servers.

Go deeper

Related to this question