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.

• ✓

  The X-Ray daemon is not running in the task definition.

  Why this is correct

  The X-Ray daemon must be deployed as a sidecar container in the ECS task definition when using the Fargate launch type. The SDK only emits UDP trace data to localhost:2000; without the daemon listening, those UDP packets are silently dropped and no segments ever reach the X-Ray service. Fargate does not run a host-level X-Ray agent, so the task definition must explicitly include the daemon container and the application must be configured to communicate with it via the daemon's port.

• ✗

  The X-Ray SDK cannot send traces to AWS X-Ray from Fargate tasks.

  Why it's wrong here

  This statement is false because the X-Ray SDK never calls the X-Ray API directly; it always sends trace data to a local daemon via UDP. In Fargate, you run the X-Ray daemon as a sidecar container, and the SDK forwards segments to that daemon, which then batches and asynchronously uploads them to AWS X-Ray over HTTPS. The SDK-to-daemon protocol works identically on Fargate as on EC2, so there is no inherent limitation preventing trace delivery from Fargate tasks.

• ✗

  ServiceLens does not support Amazon ECS with Fargate launch type.

  Why it's wrong here

  ServiceLens fully supports Amazon ECS, including tasks using the Fargate launch type, as long as you integrate AWS X-Ray with Amazon CloudWatch and configure the required IAM permissions. The trace map and end-to-end service visualization in ServiceLens rely on X-Ray segments, not on the underlying compute launch type. What is required is that the application is instrumented with the X-Ray SDK and that a daemon (or AWS Distro for OpenTelemetry collector) is present in the task to forward traces; the launch type itself does not affect this support.

• ✗

  The application is not sending metrics to CloudWatch Container Insights.

  Why it's wrong here

  CloudWatch Container Insights collects infrastructure metrics and logs from ECS, but it is entirely independent from X-Ray trace data. ServiceLens shows trace maps and service health based on X-Ray segments and traces, not on the container-level metrics that Container Insights gathers. If Container Insights is disabled, you simply lack those operational dashboards and metrics; traces still appear in ServiceLens because they originate from the X-Ray SDK and daemon, so this is not the reason traces are missing.

Go deeper

Related to this question