Core Components — Deep Dive

The settings and mechanics inside this tab are where most X-Ray exam questions actually live — especially sampling rule behavior and the annotations/metadata split.

AWS Exam Thinking

Requirement → Keywords → Expected Answer → why every distractor fails.

Integrations & Architecture Example

End-to-End Architecture Example

Best Practices & Common Exam Traps

When to Use X-Ray — and When Not To

Best Practices

Common Exam Traps

X-Ray vs. CloudWatch Logs vs. CloudTrail

Since X-Ray doesn't have close functional lookalikes the way GuardDuty/Inspector/Macie do, the comparison that actually matters on this exam is which of these three observability services answers which question.

Memory Anchors

• "Annotate to filter, use metadata to explain." — the fastest recall for the #1 tested distinction.
• "Segment = one service's box; subsegment = a smaller box inside it."
• "Reservoir first, then the rate." — sampling rule mechanics in five words.
• "No daemon in Lambda — the platform is the daemon."
• "X-Ray traces the request; CloudTrail traces the API call; CloudWatch Logs stores what you printed."

Hands-On Lab

Three self-contained exercises that turn the conceptual annotations/metadata and Active Tracing material above into something you actually click and run. All console steps assume the eu-west-1 (Ireland) region and an existing Lambda function — swap my-orders-function for your own function name throughout. Each CLI block is AWS CLI v2 syntax.

Exercise 1 — Enable Active Tracing and Read Your First Trace

1. In the Lambda console (region eu-west-1), open my-orders-function → Configuration tab → Monitoring and operations tools → click Edit → toggle Active tracing to On → Save. The function's configuration now shows Active Tracing = Active; every new invocation generates an X-Ray segment automatically.
2. Reproduce the same change from the CLI instead (useful to confirm what the console toggle actually does under the hood):

   aws lambda update-function-configuration \
     --region eu-west-1 \
     --function-name my-orders-function \
     --tracing-config Mode=Active

   "TracingConfig": { "Mode": "Active" } is echoed back in the CLI response.
3. Attach the AWSXRayDaemonWriteAccess managed policy to the function's execution role so it's allowed to call xray:PutTraceSegments / xray:PutTelemetryRecords:

   aws iam attach-role-policy \
     --role-name my-orders-function-role \
     --policy-arn arn:aws:iam::aws:policy/AWSXRayDaemonWriteAccess

   Find the exact role name first if you don't have it memorized: aws lambda get-function-configuration --region eu-west-1 --function-name my-orders-function --query Role --output text returns the role ARN; the role name is the last path segment.

   No error is returned; aws iam list-attached-role-policies --role-name my-orders-function-role now lists AWSXRayDaemonWriteAccess.
4. Invoke the function a handful of times to generate sampled traces:

   for i in 1 2 3 4 5; do
     aws lambda invoke \
       --region eu-west-1 \
       --function-name my-orders-function \
       --payload '{"orderId":"ord-1001","customerTier":"standard"}' \
       --cli-binary-format raw-in-base64-out \
       out-$i.json
   done

   Five out-N.json files are written locally, each with "StatusCode": 200 in the invoke response.
5. Open the X-Ray console → Traces (region eu-west-1) → the five invocations should appear within about a minute, each with a trace ID and a duration. Click one, then open Service map. The trace timeline shows a single segment named my-orders-function; the service map shows one green node for the function with no downstream edges yet, since no instrumented AWS SDK calls have been added.

Exercise 2 — Custom Subsegment + Annotation, Then Filter By It

1. Add the X-Ray SDK to your deployment package. Python example (requirements.txt):

   aws-xray-sdk>=2.14.0

   Node.js example (package.json):

   npm install aws-xray-sdk-core --save

   The SDK is bundled into the next deployment package/layer alongside your handler code.
2. Instrument the handler — open a custom subsegment, add one annotation (searchable) and one metadata field (not searchable) so you can see the difference land in the console later.

   Python:

   from aws_xray_sdk.core import xray_recorder
   
   def handler(event, context):
       order_id = event.get("orderId", "unknown")
       customer_tier = event.get("customerTier", "standard")
   
       subsegment = xray_recorder.begin_subsegment("validate-order")
       subsegment.put_annotation("customer_tier", customer_tier)
       subsegment.put_metadata("raw_event", event)
       try:
           # ... order validation logic ...
           result = {"orderId": order_id, "status": "validated"}
       finally:
           xray_recorder.end_subsegment()
   
       return result

   Node.js equivalent:

   const AWSXRay = require('aws-xray-sdk-core');
   
   exports.handler = async (event) => {
     const orderId = event.orderId || 'unknown';
     const customerTier = event.customerTier || 'standard';
   
     const segment = AWSXRay.getSegment();
     const subsegment = segment.addNewSubsegment('validate-order');
     subsegment.addAnnotation('customer_tier', customerTier);
     subsegment.addMetadata('raw_event', event);
   
     try {
       // ... order validation logic ...
       return { orderId, status: 'validated' };
     } finally {
       subsegment.close();
     }
   };

   Handler code now opens/closes a named subsegment on every invocation and tags it with one annotation and one metadata field.
3. Redeploy the updated code:

   aws lambda update-function-code \
     --region eu-west-1 \
     --function-name my-orders-function \
     --zip-file fileb://function.zip

   "LastUpdateStatus": "Successful" appears in the response once the update finishes propagating.
4. Invoke again with a couple of different customerTier values so you have something to filter between:

   aws lambda invoke --region eu-west-1 --function-name my-orders-function \
     --payload '{"orderId":"ord-2001","customerTier":"enterprise"}' \
     --cli-binary-format raw-in-base64-out out-enterprise.json
   
   aws lambda invoke --region eu-west-1 --function-name my-orders-function \
     --payload '{"orderId":"ord-2002","customerTier":"standard"}' \
     --cli-binary-format raw-in-base64-out out-standard.json

   Both invocations return "StatusCode": 200, and each produces a new trace containing a validate-order subsegment.
5. In the X-Ray console → Traces, use the filter expression:

   annotation.customer_tier = "enterprise"

   Only the trace from the enterprise invocation appears. Now try metadata.raw_event = "..." in the filter bar — the console rejects it or returns nothing, because metadata is never indexed. Opening the trace detail view directly (not the filter bar) is the only place raw_event is visible.

Exercise 3 — Read a Service Map for Root-Cause Analysis

1. Add an instrumented downstream call plus a deliberate artificial delay and a conditional failure. Python example, extending Exercise 2's handler:

   import time
   import random
   import boto3
   from aws_xray_sdk.core import patch_all
   
   patch_all()  # auto-wraps boto3 clients so calls become subsegments
   dynamodb = boto3.client("dynamodb", region_name="eu-west-1")
   
   def handler(event, context):
       order_id = event.get("orderId", "unknown")
   
       # Artificial delay to simulate a slow downstream dependency
       time.sleep(2.5)
   
       # Artificial fault ~50% of the time to populate the service map with red
       if random.random() < 0.5:
           raise Exception("Simulated downstream failure for order " + order_id)
   
       dynamodb.put_item(
           TableName="Orders",
           Item={"orderId": {"S": order_id}, "status": {"S": "validated"}}
       )
       return {"orderId": order_id, "status": "validated"}

   The function now sometimes succeeds slowly (2.5s+) and sometimes throws, in addition to whichever behavior it had before.
2. Redeploy and invoke it 8-10 times in a loop so both outcomes occur:

   aws lambda update-function-code --region eu-west-1 \
     --function-name my-orders-function --zip-file fileb://function.zip
   
   for i in $(seq 1 10); do
     aws lambda invoke --region eu-west-1 --function-name my-orders-function \
       --payload "{\"orderId\":\"ord-30$i\"}" \
       --cli-binary-format raw-in-base64-out out-$i.json
     sleep 1
   done

   Roughly half the invocations return a normal 200 response with elevated duration; the rest return an unhandled function error.
3. Open X-Ray console → Service map (region eu-west-1). The my-orders-function node is no longer solid green — it shows a red slice/ring proportional to the fault rate, and hovering it surfaces average latency alongside the fault percentage.
4. Click the node → View traces, then open one of the failed traces and one of the slow-but-successful traces side by side. The failed trace's segment is flagged with a red "Fault" indicator and the exception message from the raised exception appears in the segment detail. The slow-but-successful trace shows a normal (non-fault) segment whose duration bar is visibly wider than a typical invocation, making the 2.5s artificial delay obvious in the waterfall view without reading any code.
5. Clean up before moving on, so this exercise's artificial fault/delay doesn't linger in a real deployment — redeploy the Exercise 2 version of the handler (without the time.sleep and random.random block). Subsequent invocations return to fast, consistently successful responses, and the service map node gradually returns to solid green as new healthy traces accumulate.

Flashcards — 22 Cards

Click card to flip. Mark right or wrong to track score.

Practice Quiz — 13 Questions

DVA-C02 scenario style, Easy → Specialty. Select an answer to reveal the explanation.