DVA-C02 Troubleshooting and Optimization 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 the X-Ray SDK to instrument the application code.

  Why this is correct

  The X-Ray SDK must be integrated directly into the application code because it is what creates trace data in the first place. For supported web frameworks, middleware or interceptors automatically capture incoming HTTP requests, generate a trace ID, manage segments and subsegments, and propagate the X-Amzn-Trace-Id header to downstream services. The SDK then sends completed segments to the local X-Ray daemon over UDP port 2000 for eventual upload to the X-Ray API. Without this code-level instrumentation, a request never becomes a trace, regardless of daemon status or network configuration.

• ✗

  Open port 2000 on the security groups for TCP traffic.

  Why it's wrong here

  The X-Ray daemon listens on UDP port 2000 to accept trace segment batches from the SDK, not on TCP. Opening TCP 2000 in a security group is therefore incorrect because it targets the wrong transport protocol and would not permit the datagram-based traffic the daemon expects. Moreover, when the SDK and daemon run on the same EC2 instance, traffic stays on the loopback interface and no security group rule is needed at all. Security-group changes become relevant only if a remote daemon is deliberately configured.

• ✗

  Deploy the X-Ray daemon as a centralized service in a separate instance.

  Why it's wrong here

  Running a single centralized X-Ray daemon on a separate instance contradicts how the SDK is configured by default: the SDK sends trace data to 127.0.0.1:2000 on the same host. A centralized daemon would require overriding the daemon address in every service, introduces a network dependency for every trace, and creates a single point of failure that can drop segments during outages. The intended pattern is a daemon per EC2 instance, container, or task, because it is meant to run as a lightweight local relay that buffers bursts and flushes to the X-Ray API asynchronously. Centralizing also adds inter-instance latency to something that should be a fast local hop.

• ✗

  Install the CloudWatch agent on all instances.

  Why it's wrong here

  Installing the CloudWatch agent does not enable X-Ray tracing because the agent is designed to collect operating-system metrics and log files, not application trace segments. Trace data is produced by the X-Ray SDK and forwarded by the X-Ray daemon through a separate API endpoint; the CloudWatch agent has no role in receiving or forwarding segment payloads. It might allow you to correlate CPU utilization with trace latency later, but it cannot instrument HTTP requests or generate trace IDs. Relying on it instead of the X-Ray SDK/daemon leaves the trace pipeline empty.

• ✓

  Ensure the X-Ray daemon is running on all EC2 instances.

  Why this is correct

  The X-Ray daemon is the local UDP relay that receives raw segments from the instrumented application, batches them, and uploads them to the X-Ray service via the AWS API. It must be running on every EC2 instance that hosts your application; if it is absent, the SDK cannot offload trace data and you will see missing or incomplete traces. The daemon also applies the configured sampling rules and preserves the timing of segments so the service graph can be built accurately. It is a required companion to the SDK and is typically launched as a service during instance startup.