AZ-400 Implement an instrumentation strategy Practice Question
You are designing an instrumentation strategy for a new application that will be deployed to Azure. The application consists of an Azure App Service web front end, an Azure Functions backend, and an Azure SQL Database. You need to collect telemetry that allows you to correlate requests across all components and analyze performance bottlenecks. You plan to use Application Insights. Which two actions should you perform? (Choose two.)
⚠ Common exam trap
The trap here is thinking that enabling diagnostic logs on Azure SQL Database and linking workspaces will automatically correlate database calls with application telemetry, when correlation requires SDK instrumentation and a shared Application Insights resource.
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
✓
Enable the Application Insights SDK in the App Service and Azure Functions code to track requests and dependencies.
To correlate requests across App Service, Azure Functions, and Azure SQL, you need application-level instrumentation in each component and a shared Application Insights resource. The SDK tracks requests and dependencies and propagates correlation context, while a single resource stores all telemetry for unified analysis. Database logs and inconsistent sampling do not provide the required end-to-end view.
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 sampling in each component with different sampling rates to optimize telemetry volume.
Why it's wrong here
Different sampling rates across components can break correlation because sampled-out telemetry may remove parts of a transaction. While sampling is useful for volume control, inconsistent settings can lead to incomplete traces. For reliable correlation, sampling should be configured consistently, often using a single setting across all components.
- ✓
Enable the Application Insights SDK in the App Service and Azure Functions code to track requests and dependencies.
Why this is correct
To correlate requests across components, each component must emit telemetry with a common operation ID. The Application Insights SDK provides automatic instrumentation for incoming requests and outgoing dependencies, and it propagates the correlation context across HTTP calls. This is essential for end-to-end transaction diagnostics in Application Insights.
- ✗
Configure the Azure SQL Database to send diagnostic logs to a Log Analytics workspace and link the workspace to Application Insights.
Why it's wrong here
Azure SQL Database diagnostic logs contain query and security events but do not participate in Application Insights distributed tracing. Linking a Log Analytics workspace to Application Insights does not merge the telemetry into the Application Insights transaction view. Correlation requires application-level instrumentation, not just database logs.
- ✗
Deploy the Application Insights status monitor to the App Service and Azure Functions to enable automatic instrumentation.
Why it's wrong here
The Application Insights Status Monitor is a legacy tool for attaching to .NET applications on-premises or in IaaS, not for Azure App Service or Azure Functions. For Azure App Service, you enable Application Insights via the Azure portal or ARM template; for Functions, you use the built-in integration. Status Monitor is not the correct mechanism here.
- ✓
Use the same Application Insights resource for all components to enable cross-component correlation.
Why this is correct
Using a single Application Insights resource for all components ensures that all telemetry is stored together and can be correlated by operation ID. If different resources are used, the distributed trace will be split, and you cannot see the end-to-end transaction. A shared resource is a prerequisite for cross-component correlation in Application Insights.
Quick reference
Cloud Service Model Comparison
| Model | You Manage | Provider Manages | Examples |
|---|---|---|---|
| IaaS | OS, runtime, apps, data | Hardware, hypervisor, networking | EC2, Azure VMs, GCP Compute Engine |
| PaaS | Apps and data | OS, runtime, middleware, hardware | Elastic Beanstalk, Azure App Service |
| SaaS | Data and settings only | Everything else | Microsoft 365, Salesforce, Workday |
| FaaS / Serverless | Function code only | Infra, scaling, runtime | Lambda, Azure Functions, Cloud Run |
| CaaS | Containers and apps | Kubernetes, OS, hardware | EKS, AKS, GKE |
Go deeper
Related to this question
Learn chapter
Designing and Implementing Instrumentation Strategy
Key term
Functions
A function is a reusable block of code that performs a specific task, taking inputs, processing them, and returning a result, helping to organize and automate IT workflows.
Key term
Telemetry
Telemetry is the automatic collection, transmission, and measurement of data from remote sources to a central system for analysis and monitoring.
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 →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Microsoft exam blueprint
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.