Jeff’s Note #
Jeff’s Note #
“Unlike generic exam dumps, ADH analyzes this scenario through the lens of a Real-World Lead Developer.”
“For DVA-C02 candidates, the confusion often lies in distinguishing between the X-Ray SDK and X-Ray daemon roles. In production, this is about knowing exactly which component captures trace data and which component relays it to AWS. Let’s drill down.”
The Certification Drill (Simulated Question) #
Scenario #
TechFlow Solutions has deployed a microservices-based order processing system where the frontend API is hosted on AWS using API Gateway, but the core business logic runs on legacy Ubuntu servers in their Chicago datacenter. The development team has enabled X-Ray tracing on the API Gateway test stage to monitor request flows and identify bottlenecks.
The Lead Developer needs to extend X-Ray tracing visibility into the on-premises portion of the application to create end-to-end trace maps showing the complete request journey from API Gateway through to the datacenter servers.
The Requirement: #
Enable X-Ray tracing on the on-premises Linux servers with the LEAST amount of configuration while maintaining seamless integration with the existing API Gateway X-Ray implementation.
The Options #
- A) Install and run the X-Ray SDK on the on-premises servers to capture and relay the data to the X-Ray service.
- B) Install and run the X-Ray daemon on the on-premises servers to capture and relay the data to the X-Ray service.
- C) Capture incoming requests on-premises and configure an AWS Lambda function to pull, process, and relay relevant data to X-Ray using the PutTraceSegments API call.
- D) Capture incoming requests on-premises and configure an AWS Lambda function to pull, process, and relay relevant data to X-Ray using the PutTelemetryRecords API call.
Google adsense #
Correct Answer #
Option B.
Quick Insight: The Developer Implementation Imperative #
For DVA-C02, understanding the X-Ray architecture’s two-tier model is critical:
- SDK = Instrumentation Layer (code-level integration)
- Daemon = Transport Layer (UDP listener on port 2000)
The daemon handles batching, retries, and AWS authentication—eliminating the need for developers to configure IAM credentials in application code.
Content Locked: The Expert Analysis #
You’ve identified the answer. But do you know the implementation details that separate a Junior from a Senior?
The Expert’s Analysis #
Correct Answer #
Option B: Install and run the X-Ray daemon
The Winning Logic #
The X-Ray daemon is specifically designed as a lightweight background process that:
- Listens for UDP traffic on port 2000 from the X-Ray SDK
- Buffers and batches trace segments for efficient transmission
- Handles AWS authentication using IAM credentials (instance profile, environment variables, or credentials file)
- Relays data to the X-Ray service via HTTPS
Why this is “LEAST configuration”:
- Single binary installation (
wgetandchmod +x) - One configuration file (
cfg.yaml) for region and IAM role - Automatic handling of retries, exponential backoff, and connection pooling
- No code changes required if SDK is already instrumented
For DVA-C02 candidates: The daemon acts as a local aggregation point. Your application code uses the SDK to generate trace segments, but the SDK sends them via UDP to localhost:2000, not directly to AWS.
The Trap (Distractor Analysis) #
Why not Option A (X-Ray SDK only)? #
The SDK alone cannot relay data to AWS X-Ray. The SDK’s job is to:
- Instrument code (capture HTTP calls, database queries, custom subsegments)
- Generate trace segment JSON
- Send segments to the daemon via UDP
Without the daemon, trace data stays local. The question asks to “capture and relay"—the SDK does capturing, but the daemon does relaying.
Technical Detail for DVA-C02: The SDK uses the AWS_XRAY_DAEMON_ADDRESS environment variable (default: 127.0.0.1:2000) to locate the daemon. If the daemon isn’t running, traces are silently dropped.
Why not Option C (Lambda + PutTraceSegments)? #
This creates an over-engineered polling architecture:
- Lambda would need to continuously poll on-premises logs or a queue
- Requires setting up a message broker (SQS, Kinesis) in the data path
- Violates the “LEAST configuration” requirement
- Introduces latency and potential data loss during network partitions
PutTraceSegments is the correct API for sending traces, but the daemon already uses it internally. Manually calling it from Lambda duplicates this functionality unnecessarily.
Why not Option D (Lambda + PutTelemetryRecords)? #
PutTelemetryRecords is the wrong API entirely. This API is used by the X-Ray daemon itself to send metadata about the daemon’s health (CPU usage, segments sent/failed), not application trace data.
For DVA-C02, remember:
PutTraceSegments= Application trace dataPutTelemetryRecords= Daemon health metricsGetTraceSummaries= Query trace data
The Technical Blueprint #
X-Ray Daemon Installation and Configuration (On-Premises Linux):
# Download the X-Ray daemon for Linux
wget https://s3.us-east-2.amazonaws.com/aws-xray-assets.us-east-2/xray-daemon/aws-xray-daemon-linux-3.x.zip
unzip aws-xray-daemon-linux-3.x.zip
chmod +x xray
# Configure IAM credentials (if not using instance profile)
export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
export AWS_REGION=us-east-1
# Run the daemon
./xray -o -n us-east-1
# Verify daemon is listening
netstat -tuln | grep 2000
# Expected output: udp 0 0 127.0.0.1:2000 0.0.0.0:*
Sample cfg.yaml for Production:
TotalBufferSizeMB: 24
Region: "us-east-1"
Socket:
UDPAddress: "127.0.0.1:2000"
Logging:
LogLevel: "info"
LogPath: "/var/log/xray-daemon.log"
Application Code (Python with SDK):
from aws_xray_sdk.core import xray_recorder
from aws_xray_sdk.core import patch_all
# Patch libraries to auto-instrument
patch_all()
# SDK automatically sends to daemon at 127.0.0.1:2000
@xray_recorder.capture('process_order')
def process_order(order_id):
# Your business logic
return {"status": "processed"}
The Comparative Analysis #
| Option | API Complexity | Configuration Overhead | Performance Impact | Best Use Case |
|---|---|---|---|---|
| B) X-Ray Daemon | Low (no API calls needed) | Minimal (binary + IAM) | Negligible (<1% CPU) | Standard hybrid tracing |
| A) SDK Only | Medium (SDK integration) | Medium (IAM in code) | Low | Invalid—cannot relay to AWS |
| C) Lambda + PutTraceSegments | High (custom polling logic) | High (Lambda + queue + IAM) | Medium (added latency) | Custom trace aggregation from non-instrumented systems |
| D) Lambda + PutTelemetryRecords | N/A (wrong API) | High | N/A | Daemon health monitoring (internal use) |
DVA-C02 Exam Tip: If a question mentions “LEAST configuration” or “minimal operational overhead” for X-Ray on EC2/on-premises, the daemon is almost always the answer.
Real-World Application (Practitioner Insight) #
Exam Rule #
“For DVA-C02, always pick the X-Ray daemon when enabling tracing on EC2, ECS (non-Fargate), or on-premises servers. The daemon is the standard relay mechanism.”
Real World #
“In reality, we run the daemon as a systemd service to ensure it auto-restarts on server reboot. We also configure it to use AssumeRole for cross-account tracing, allowing our on-premises systems to send traces to a centralized AWS monitoring account without embedding long-term credentials.”
Production Enhancement:
# Create systemd service for auto-restart
sudo cat > /etc/systemd/system/xray-daemon.service <<EOF
[Unit]
Description=AWS X-Ray Daemon
After=network.target
[Service]
ExecStart=/usr/local/bin/xray -o -n us-east-1
Restart=always
User=xray
EnvironmentFile=/etc/xray/credentials
[Install]
WantedBy=multi-user.target
EOF
sudo systemctl enable xray-daemon
sudo systemctl start xray-daemon
Stop Guessing, Start Mastering #
Disclaimer
This is a study note based on simulated scenarios for the AWS DVA-C02 exam. Company names and business contexts have been modified for educational purposes while preserving core technical concepts.