DVA-C02 - Troubleshooting and Optimization (18% of the exam) - Section 4.2

Perform root cause analysis using AWS X-Ray service maps and traces, interpreting common HTTP error codes and SDK exceptions.

Use the AWS X-Ray service map to visualise distributed call flows and identify latency hotspots or error sources across microservices and Lambda functions. Interpret common HTTP status codes and AWS SDK exceptions in X-Ray traces to distinguish throttling, client errors, and downstream service failures.

AWS X-RayService mapHTTP status codesSDK exception handling

Practice question for this objective

Free sampleTroubleshooting and Optimizationhard

A developer wants an AWS Lambda function written with the AWS SDK for Node.js to appear in the AWS X-Ray service map with its downstream Amazon DynamoDB calls shown as separate timed subsegments. After deploying, no traces appear in the X-Ray console at all. Which TWO configuration steps are required for the function to publish segments and capture the DynamoDB call as a subsegment? (Select TWO.)

  • AEnable Active tracing in the function configuration so Lambda creates and emits the request segment to X-Ray. Correct
  • BWrap the AWS SDK client with the X-Ray SDK (capture the AWS client) so each DynamoDB call is recorded as a subsegment. Correct
  • CGrant the execution role dynamodb:DescribeTable so X-Ray can read the table's metadata for the service map.
  • DAdd an X-Ray annotation named dynamodb to the segment so the DynamoDB subsegment becomes visible on the service map.
  • EIncrease the function timeout so the trace has time to flush before the execution environment is frozen.
End-to-end Lambda tracing needs Active tracing enabled to emit the segment and the AWS SDK client captured by the X-Ray SDK to record downstream calls as subsegments. Active tracing makes the Lambda service create and send the parent segment to X-Ray. The X-Ray SDK only records a downstream DynamoDB call when the AWS SDK client is wrapped or patched, which generates the timed subsegment that surfaces DynamoDB as a node on the service map.

Why A is correct: With Active tracing on, the Lambda service opens the segment and sends it to X-Ray; without it the SDK has no parent segment to attach subsegments to and nothing reaches the console.

Why B is correct: Patching or capturing the AWS SDK client is what instruments the DynamoDB call, producing the timed subsegment that appears as a downstream node on the service map.

Why C is wrong: X-Ray does not call DynamoDB to build the map; this permission is unrelated, and the missing-traces symptom stems from tracing setup, not table metadata access.

Why D is wrong: Annotations index values for filter expressions; they neither create subsegments nor cause downstream nodes to appear, so this does not capture the call.

Why E is wrong: A longer timeout sounds like it would help flushing, but Lambda emits the segment as part of the managed lifecycle; the traces are absent because tracing was never enabled and the client was not instrumented.

See more DVA-C02 practice questions, answers explained.

Exam traps in Troubleshooting and Optimization

Answers that look right on this material and are not. Each one is a distractor from a different question in the DVA-C02 bank for this domain.

  • A response with a 4xx status such as 404 sets the fault flag because any non-2xx response is treated as a downstream failure.

    Why it is wrong: X-Ray records 4xx as the error flag, not the fault flag, and a clean 2xx is neither; treating all non-2xx alike is the common mistake this distractor encodes.

  • Enable active tracing on the function alone, because that setting makes X-Ray create downstream subsegments for every AWS SDK and HTTP client call automatically.

    Why it is wrong: Active tracing produces the parent segment and Lambda subsegments, but capturing downstream client calls still requires instrumenting those clients with the X-Ray SDK.

  • The inventory node is failing internally and returning 5xx faults, so the developer should restart the inventory service to clear the server-side failures driving the edge errors.

    Why it is wrong: This is tempting because a problem edge feels like a downstream failure, but a green inventory node with a healthy fault rate shows it is not producing 5xx faults, so restarting it does not address the 4xx errors on the edge.

Examworthy is not affiliated with or endorsed by Amazon Web Services. Original, blueprint-aligned practice material only.