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
Context propagation is required to correlate spans across services.
- ✗
Enable the Application Insights auto-instrumentation agent on the application host.
Why it's wrong here
Auto-instrumentation is for metrics, not trace context propagation.
- ✗
Configure the OpenTelemetry SDK to use the Azure Monitor exporter instead of the default exporter.
Why it's wrong here
Exporter choice does not affect context propagation.
- ✗
Set the same service name for all services in the OpenTelemetry configuration.
Why it's wrong here
Service name is for identification, not trace correlation.
Go deeper
Related to this question
Learn chapter
Introduction to DevOps and Azure DevOps
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 823 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: Setting a unique Correlation ID in pipeline variables and passing it as a span attribute to OpenTelemetry allows end-to-end traceability by linking pipeline events with application telemetry. Option A is incorrect because Application Insights can ingest pipeline telemetry, but that alone does not correlate with application telemetry; you need a shared correlation ID. Option B is wrong because storing pipeline logs in Log Analytics and querying with metrics does not provide real-time correlation at the span level. Option C is incorrect because deployment gates based on application metrics do not create correlation; they only block deployments based on conditions.
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.