Propagating Trace Context Across Microservices for End-to-End Correlation
A development team is implementing a distributed tracing solution for a microservices application deployed on Azure. They want to correlate requests across services using OpenTelemetry and send data to Azure Monitor. The application currently generates traces, but the traces are incomplete, showing only individual service spans without end-to-end correlation. The team has already instrumented each service with the OpenTelemetry SDK. What should the team do to ensure proper end-to-end trace correlation?
Quick Answer
Incomplete, disconnected spans across services almost always mean trace context isn't being propagated between them. Each service needs to pass the trace ID and span ID via HTTP headers (W3C Trace-Context) on outgoing calls and extract them on incoming ones — the OpenTelemetry SDK can automate this, but the team has to make sure every service boundary actually carries those headers.
⚠ Common exam trap
A common mix-up: candidates confuse telemetry export (sending data to a backend) with context propagation (passing trace IDs between services), assuming that using the correct exporter or agent automatically correlates spans.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Implement context propagation by passing trace headers between services.
Distributed tracing requires propagating trace context (trace ID, span ID) across service boundaries via HTTP headers (e.g., W3C Trace-Context). Without context propagation, each service creates its own trace, resulting in disconnected spans. The OpenTelemetry SDK automatically handles propagation when configured, but the team must ensure that outgoing requests include the trace headers and incoming requests extract them.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Implement context propagation by passing trace headers between services.
Why this is correct
Without context propagation, each service starts a fresh trace, so spans never share a trace ID. Passing W3C traceparent headers between calls lets the OpenTelemetry SDK link child spans to the originating trace, delivering the end-to-end correlation across services that the stem requires.
- ✗
Enable the Application Insights auto-instrumentation agent on the application host.
Why it's wrong here
Auto-instrumentation adds spans for supported frameworks but does not propagate W3C traceparent headers across your own service calls; each service still starts a new trace. It suits quick onboarding of a single app without custom code, yet the SDKs are already installed, so context propagation must be configured there.
- ✗
Configure the OpenTelemetry SDK to use the Azure Monitor exporter instead of the default exporter.
Why it's wrong here
Exporting spans to Azure Monitor only changes the destination of telemetry; it does not propagate trace context between services. Correlation requires W3C traceparent headers to be injected on outbound calls and extracted on inbound ones, which the default propagator already handles once configured. The exporter is genuinely needed to route data to Application Insights.
- ✗
Set the same service name for all services in the OpenTelemetry configuration.
Why it's wrong here
A shared service name groups spans under one cloud role, but correlation depends on propagating the trace ID and parent span ID across HTTP calls, not on naming. Identical names actually merge distinct services in Application Insights. Service naming is for logical grouping and filtering within the Application Map.
Go deeper
Related to this question
Learn chapter
Managing Infrastructure as Code Using Azure
Key term
Trace
A trace is a record of the path and timing of a request or operation as it moves through components in a system, used to monitor performance and troubleshoot issues.
Key term
Azure Monitor
Azure Monitor is a cloud service that collects, analyzes, and acts on telemetry data from your Azure and on-premises resources to help you understand performance and availability.
About these practice questions
One of 696 original AZ-400 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
Same concept, more angles
3 more ways this is tested on AZ-400
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. You are building a comprehensive instrumentation strategy for a large-scale Azure DevOps environment. You need to ensure that all pipeline events (build, release, test) are automatically tracked and correlated with application performance data. Which THREE components should you include?
hard- ✓ A.A shared Correlation ID that flows from pipeline to application.
- B.Azure Monitor Workbooks to visualize pipeline data.
- ✓ C.Custom pipeline tasks that send telemetry to Application Insights.
- D.Azure Boards to track pipeline run metadata.
- ✓ E.OpenTelemetry SDK in the application to emit trace context.
Why A: Options A, C, and E are correct. A shared Correlation ID (A) flows from pipeline to application, enabling end-to-end trace correlation. Custom pipeline tasks (C) send telemetry (e.g., build/release events) to Application Insights. The OpenTelemetry SDK (E) emits trace context from the application, which can include the correlation ID. Option B is wrong because Azure Monitor Workbooks are visualization tools, not data collection components. Option D is wrong because Azure Boards is for work item tracking, not pipeline event capture.
Variation 2. A company uses Azure Monitor and Application Insights to monitor a microservices application deployed on Azure Kubernetes Service (AKS). The development team wants to implement distributed tracing to correlate requests across services. They currently have Application Insights SDKs instrumented in each service. Which TWO configurations are required to enable end-to-end distributed tracing?
hard- A.Enable the Live Metrics Stream feature in Application Insights.
- ✓ B.Ensure all services use the same Application Insights instrumentation key or connection string.
- C.Configure adaptive sampling in the Application Insights SDK.
- ✓ D.Ensure the SDKs are configured to propagate correlation headers (e.g., W3C Trace-Context).
- E.Enable Application Map in the Azure portal for each service.
Why B: All services must share the same Application Insights instrumentation key or connection string to ensure that telemetry from different microservices is correlated into a single application map and trace. Without a common instrumentation key, the distributed trace data would be siloed across separate Application Insights resources, preventing end-to-end correlation.
Variation 3. You are designing an instrumentation strategy for a microservices application deployed to Azure Kubernetes Service (AKS) using Azure Pipelines. The application emits custom metrics using OpenTelemetry. You need to ensure that all pipeline-related events (build, release, and test results) are correlated with application telemetry to enable end-to-end traceability. What should you do?
hard- A.Configure Application Insights to ingest pipeline telemetry via a custom exporter.
- B.Store pipeline logs in an Azure Log Analytics workspace and query them together with application metrics.
- C.Use Azure Pipelines' Checks feature to enforce deployment gates based on application metrics.
- ✓ D.Set a unique Correlation ID in the pipeline variables and pass it to the application's OpenTelemetry instrumentation as a span attribute.
Why D: To correlate pipeline events with application telemetry, you must propagate a shared identifier from the pipeline into the application's telemetry. Setting a unique Correlation ID in pipeline variables and passing it as an OpenTelemetry span attribute (D) lets Application Insights and pipeline logs join on that ID, enabling true end-to-end traceability.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This AZ-400 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-400 exam.