AZ-400 Implement an instrumentation strategy Practice Question
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?
⚠ Common exam trap
A common mix-up: candidates confuse enabling Application Map (a visualization) with the actual configuration needed for correlation, or they think adaptive sampling is required for tracing, when in fact the key requirements are a shared instrumentation key and header propagation.
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
✓
Ensure all services use the same Application Insights instrumentation key or connection string.
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.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Enable the Live Metrics Stream feature in Application Insights.
Why it's wrong here
Live Metrics Stream in Application Insights is a low-latency, real-time telemetry view used for monitoring active request rates, failure counts, and performance counters. It is a visualization and monitoring tool, not a configuration that changes how telemetry is structured; it does not generate or propagate the trace correlation context (trace ID and parent ID) needed to link telemetry from dependent services into a single distributed operation. Therefore, while useful for live dashboards, it does nothing to enable end-to-end distributed tracing.
- ✓
Ensure all services use the same Application Insights instrumentation key or connection string.
Why this is correct
For distributed tracing, all services must send telemetry to the same Application Insights resource by using the same instrumentation key or connection string. This ensures that the operation IDs and parent IDs emitted by each service are stored in one logical table, allowing the trace to be stitched together across service boundaries. Using different keys on different services scatters telemetry into separate resources, making it impossible to correlate a request end-to-end even if trace-context headers are present. This is a necessary prerequisite, though not sufficient on its own.
- ✗
Configure adaptive sampling in the Application Insights SDK.
Why it's wrong here
Adaptive sampling is a built-in feature that automatically reduces the volume of telemetry sent to Application Insights by retaining rates based on the volume. Sampling operates after telemetry items are generated and assigned correlation IDs, so it cannot create a correlation relationship; worse, it can selectively drop dependency calls or child spans, making distributed traces incomplete and harder to debug. Configuring it is therefore irrelevant to service-to-service correlation and, in practice, can harm the fidelity of end-to-end tracing under high load.
- ✓
Ensure the SDKs are configured to propagate correlation headers (e.g., W3C Trace-Context).
Why this is correct
Correctly enabling distributed tracing requires each service's SDK to propagate W3C Trace-Context correlation headers, specifically `traceparent`, on every outbound HTTP dependency call. When Service A calls Service B, A writes its current trace ID and span ID into the `traceparent` header, and B's SDK reads that header to create a child span whose parent is A's span. Without this header propagation, each ingress request is treated as a root operation, so Application Insights cannot join the telemetry across services into a cohesive end-to-end transaction.
- ✗
Enable Application Map in the Azure portal for each service.
Why it's wrong here
Application Map is a visualization in the Azure portal that automatically discovers components and renders the interactions between them once telemetry is already correlated by operation IDs. It is an output of distributed tracing, not a switch that turns on correlation; enabling it has no effect on the SDK configuration or on the presence of trace-context headers. Thus, it does not solve the problem of getting services to emit correlatable telemetry.
Go deeper
Related to this question
Learn chapter
Introduction to DevOps and Azure DevOps
Key term
Application Insights
Application Insights is an Azure monitoring service that helps developers detect, diagnose, and understand issues in live web applications by collecting telemetry data like requests, exceptions, and performance counters.
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.
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 →
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.