AZ-400 Implement an instrumentation strategy — 20 Questions

Question 1

You have an Azure DevOps pipeline that deploys a web app to Azure App Service. You want to capture deployment frequency and change failure rate as metrics in Application Insights. Which built-in analytics view should you use?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Application Dashboard. The Application Dashboard in Application Insights is a built-in analytics view that provides a customizable overview of your application's metrics. While it does not natively display deployment frequency or change failure rate, you can configure it with metric tiles to show these values if telemetry is properly instrumented. Option A is incorrect because 'Deployment Frequency' is a report in Azure DevOps Analytics, not a built-in view in Application Insights.

Answer

Deployment Frequency

Answer

Time to Restore Service

Answer

Azure DevOps Pipeline Telemetry

Question 2

Which THREE of the following are valid techniques to reduce the volume of telemetry data sent to Application Insights while preserving diagnostic value?

Accepted Answer

Configure fixed-rate sampling. Fixed-rate sampling randomly selects a percentage of telemetry items to send, reducing volume predictably while preserving a representative sample for diagnostics. Adaptive sampling automatically adjusts the sampling rate based on telemetry volume, retaining a representative sample while responding to changes in load. Using ITelemetryProcessor filters allows you to programmatically discard low-importance telemetry before transmission, keeping high-value events for diagnostics. These techniques collectively reduce telemetry volume while preserving diagnostic value.

Answer

Aggregate telemetry into 1-minute buckets before sending

Answer

Set a maximum telemetry throughput limit on the Application Insights instance

Question 3

A team uses Azure Monitor to collect metrics from their Azure Kubernetes Service (AKS) cluster. They notice that container logs are missing from Log Analytics. The cluster was created with the default settings and no custom configuration was applied. What is the most likely reason for the missing logs?

Accepted Answer

The Data Collection Rule does not include the ContainerLogs table.. By default, an AKS cluster created with default settings does not have container logs (stdout/stderr) collected by Azure Monitor. Container logs require a Data Collection Rule (DCR) that includes the 'ContainerLog' table. Without this DCR, the Azure Monitor agent will not collect container logs, even though other metrics may be sent to Log Analytics.

Answer

The diagnostic setting for the AKS cluster is not configured to send logs to Log Analytics.

Answer

The Log Analytics workspace is in a different region than the AKS cluster.

Answer

The Azure Monitor agent version on the nodes is outdated.

Question 4

A company runs a critical microservices application on Azure Kubernetes Service (AKS). They need to implement distributed tracing across services using Application Insights. Which three actions should be performed?

Accepted Answer

Use OpenTelemetry SDK with Application Insights exporter. Option B is correct because using the OpenTelemetry SDK with the Azure Monitor/Application Insights exporter is the modern, vendor-neutral way to emit distributed traces (spans with trace/span IDs and W3C traceparent propagation) from AKS workloads into Application Insights. Option C is correct because each microservice must be instrumented—via the Application Insights SDK or OpenTelemetry—so that inbound/outbound calls, dependencies, and correlation context are captured and stitched into end-to-end transactions. Option D is correct because all microservices must report to the same Application Insights resource (same instrumentation key/connection string) so that telemetry shares one correlation context and appears as a single distributed trace rather than fragmented per-service resources. Option A is not correct because the Application Insights agent is not deployed as a DaemonSet on AKS nodes; instrumentation happens in the application code or via auto-instrumentation, not a node-level agent. Option E is not correct because Container Insights collects cluster/node/pod metrics and logs (performance and health), not distributed tracing spans across microservices.

Answer

Deploy the Application Insights agent as a DaemonSet on each AKS node

Answer

Enable Azure Monitor Container Insights on the AKS cluster

Question 5

You are configuring Application Insights for a set of Azure Functions written in C# that run in the Consumption plan. The functions process messages from an Azure Service Bus queue. You need to correlate each function execution to the originating Service Bus message so that a distributed trace shows the full path from message enqueue to function completion. What should you configure?

Accepted Answer

Enable the Application Insights SDK in the function code and use TelemetryClient.StartOperation with a custom operation ID derived from the Service Bus message ID.. For end-to-end correlation across Service Bus, you need to create a custom operation in the function that uses the Service Bus message ID as the operation ID. This ties the function execution telemetry to the upstream message context, enabling Application Insights to display a unified distributed trace. Host-level integration alone does not correlate the message to the function run.

Answer

Set the APPLICATIONINSIGHTS_CONNECTION_STRING environment variable in the function app and enable sampling to reduce telemetry volume.

Answer

Enable Application Insights integration in the Azure Functions host and rely on the built-in correlation for Service Bus triggers.

Answer

Configure the Service Bus namespace to send diagnostic logs to a Log Analytics workspace and join the logs with Application Insights telemetry using Kusto queries.

Question 6

You are configuring Application Insights for a .NET Core web application deployed to Azure App Service. The application must capture telemetry for all HTTP requests, exceptions, and dependency calls with minimal code changes. What should you do?

Accepted Answer

Enable the Application Insights site extension in the App Service 'Application Insights' blade.. Enabling the Application Insights site extension via the App Service 'Application Insights' blade automatically instruments the .NET Core application without requiring any code changes. This extension injects the necessary telemetry modules to capture HTTP requests, exceptions, and dependency calls at the runtime level, leveraging the Azure App Service integration for zero-code instrumentation.

Answer

Configure diagnostics logging in the App Service and stream logs to Application Insights.

Answer

Install the Microsoft.ApplicationInsights.AspNetCore NuGet package and add services.AddApplicationInsightsTelemetry() in Startup.cs.

Answer

Add the Application Insights JavaScript SDK to each page.

Question 7

Your team uses Azure DevOps for CI/CD. You need to ensure that every build publishes telemetry to Application Insights, including build duration, test pass rate, and deployment frequency. Which approach should you use?

Accepted Answer

Use the Azure DevOps Analytics OData endpoint to query pipeline telemetry and send to Application Insights via a release task.. The Azure DevOps Analytics OData endpoint provides a standardized, queryable interface to pipeline telemetry data (build duration, test pass rate, deployment frequency). By using a release task to query this endpoint and forward the data to Application Insights, you can instrument your CI/CD pipeline to send custom telemetry without relying on manual scripting or unsupported commands. This approach aligns with the 'Implement an instrumentation strategy' domain by leveraging Azure DevOps Analytics and Application Insights integration.

Answer

Call the Azure DevOps REST API from a custom script in the pipeline to capture telemetry.

Answer

Run the Azure DevOps CLI command 'az devops telemetry publish' in a build task.

Answer

Use the built-in 'Pipeline Telemetry' dashboard in Azure DevOps.

Question 8

You are designing a centralized logging strategy for multiple microservices hosted in Azure Kubernetes Service (AKS). Each microservice writes logs in JSON format to stdout/stderr. The operations team needs to query logs across all services and correlate them with application performance metrics. Which solution provides the best integration?

Accepted Answer

Enable Container Insights in Azure Monitor to collect stdout/stderr logs and metrics into a Log Analytics workspace.. Container Insights in Azure Monitor is the best solution because it natively collects stdout/stderr logs from AKS containers and correlates them with performance metrics (CPU, memory, disk, network) in a single Log Analytics workspace. This enables the operations team to query logs across all microservices using KQL and join them with metrics for end-to-end troubleshooting, without additional infrastructure or data movement.

Answer

Configure AKS to send logs to Azure Blob Storage and use Azure Storage Analytics for querying.

Answer

Stream logs to Azure Event Hubs and then to Azure Data Explorer for analysis.

Answer

Deploy the Application Insights agent as a DaemonSet in AKS and send logs directly to Application Insights.

Question 9

You are troubleshooting an intermittent performance issue in a web application. Application Insights shows a high number of failed dependency calls to Azure SQL Database. The errors are SqlException with error code -2 (timeout). What is the most likely cause and recommended fix?

Accepted Answer

The application is exhausting the connection pool; increase Max Pool Size in the connection string.. A is correct because SqlException with error code -2 indicates a connection timeout, which in a high-traffic scenario is most commonly caused by the application exhausting the connection pool. When all connections in the pool are in use and the wait time for a free connection exceeds the Connect Timeout (default 15 seconds), new requests fail with this error. Increasing Max Pool Size in the connection string (e.g., Max Pool Size=200) allows more concurrent connections, reducing contention.

Answer

The SQL Server firewall is blocking the application IP; add a firewall rule.

Answer

The database is experiencing deadlocks; enable read committed snapshot isolation.

Answer

The database DTU limit is being exceeded; scale up the service tier.

Question 10

Which TWO metrics should you monitor to evaluate the reliability of a web application according to the DORA metrics?

Accepted Answer

Change Failure Rate. The DORA metrics define four key measures for software delivery performance: Deployment Frequency, Lead Time for Changes, Mean Time to Restore (MTTR), and Change Failure Rate. For evaluating the reliability of a web application, the two most directly relevant metrics are Change Failure Rate (B), which measures the percentage of deployments causing a failure in production, and Mean Time to Restore (MTTR) (C), which measures the time it takes to recover from a failure. These two metrics directly quantify stability and resilience, whereas Deployment Frequency and Lead Time for Changes focus on throughput and speed.

Answer

Lead Time for Changes

Answer

CPU Usage

Answer

Deployment Frequency

Question 11

You have deployed an Azure Resource Manager (ARM) template for a scheduled query rule as shown. The rule is enabled and targets an Application Insights resource. However, no alerts are firing despite HTTP 500 errors occurring. What is the most likely cause?

Accepted Answer

The threshold of 100 is too high; the rule should use a percentage-based condition on error rate.. The threshold of 100 is an absolute count, not a percentage. HTTP 500 errors may occur sporadically, but unless they reach 100 within the evaluation window, the alert will not fire. For error-rate monitoring, a percentage-based condition (e.g., >5% of total requests) is more appropriate to detect anomalies even with lower traffic volumes.

Answer

The severity is set to 2, which suppresses the alert.

Answer

The metric name 'requests/count' is misspelled; it should be 'requests/count' (correct).

Answer

The dimension filter for 'request/resultCode' includes '500' but should also include '5xx' wildcard.

Question 12

You are debugging a production issue using Application Insights Snapshot Debugger. The exhibit shows a snapshot from a NullReferenceException. The variable _dbContext is null. What is the most likely root cause?

Accepted Answer

The DbContext is not registered in the dependency injection container.. In ASP.NET Core, when a constructor-injected service like a DbContext is null at runtime, the most likely root cause is that the service (the DbContext) has not been registered in the dependency injection container. Page models themselves do not require registration. The missing null check (Option D) is a symptom, not the root cause, and the other options are unrelated.

Answer

The call to the database is not awaited, causing a race condition.

Answer

The database connection string is invalid in appsettings.json.

Answer

The OnGet method is missing a null check for _dbContext before usage.

Question 13

You are a DevOps engineer for a large e-commerce company. The company uses Azure DevOps for CI/CD and Application Insights for monitoring. The application is a .NET Core 6 microservice running on Azure Kubernetes Service (AKS) with a Redis cache and Azure SQL Database. Recently, the operations team noticed that the application's response time has degraded significantly during peak traffic hours. Application Insights shows an increase in server-side dependency call duration to Redis and SQL, but no increase in exceptions. The team suspects a connection pooling issue. You have been asked to diagnose and fix the problem. Which approach should you take first?

Accepted Answer

Use Application Insights 'Dependency' performance blade to analyze call duration percentiles and identify whether the bottleneck is in Redis or SQL. Then adjust connection pool sizes accordingly.. The first step in diagnosing a connection pooling issue is to analyze the dependency performance data in Application Insights. The 'Dependency' blade provides detailed percentiles (e.g., P50, P95, P99) for Redis and SQL call durations, allowing you to pinpoint which dependency is the bottleneck. Once identified, you can adjust the connection pool size (e.g., Max Pool Size in SQL connection string or Redis multiplexer settings) to match the peak concurrency demands without overwhelming the database or cache.

Answer

Increase the number of AKS nodes to handle peak traffic and reduce resource contention.

Answer

Review the application code to ensure that Redis and SQL connections are properly opened and closed using 'using' statements.

Answer

Run a load test against the application to reproduce the issue and monitor system counters.

Question 14

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?

Accepted Answer

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

Enable the Application Insights auto-instrumentation agent on the application host.

Answer

Configure the OpenTelemetry SDK to use the Azure Monitor exporter instead of the default exporter.

Answer

Set the same service name for all services in the OpenTelemetry configuration.

Question 15

Which TWO are best practices when configuring alerts in Azure Monitor for a production application?

Accepted Answer

Use dynamic thresholds for metrics with seasonal patterns.. Dynamic thresholds in Azure Monitor use machine learning to automatically detect and adjust alert thresholds based on historical patterns, making them ideal for metrics with seasonal or cyclical behavior (e.g., CPU usage that spikes during business hours). This reduces alert noise and manual tuning effort compared to static thresholds.

Answer

Use metric alerts only for simple threshold-based conditions.

Answer

Create separate alert rules for each condition to avoid complexity.

Answer

Ensure each alert rule uses a unique action group to isolate notifications.

Question 16

You are reviewing a Data Collection Rule (DCR) for an Azure virtual machine. The DCR is assigned to the VM, and the Azure Monitor Agent is installed. After one hour, no performance data appears in the Log Analytics workspace. What is the most likely cause?

Accepted Answer

The data flow streams property does not include 'Microsoft-Perf'.. The most likely cause is that the data flow streams property in the DCR does not include 'Microsoft-Perf'. The Azure Monitor Agent uses DCRs to define which data to collect and where to send it. Without the 'Microsoft-Perf' stream specified in the dataFlows section, performance counters are not collected, even if the counter specifiers are correctly defined. The workspace resource ID and counter format may be correct, but the missing stream prevents any performance data from being ingested.

Answer

The workspace resource ID is incorrectly formatted.

Answer

The counter specifier uses the wrong format for Windows performance counters.

Answer

The sampling frequency of 60 seconds is too low and data is being throttled.

Question 17

A company has a multi-region application deployed on Azure App Service (Windows) across three regions: West US, East US, and West Europe. The operations team uses Azure Monitor to collect application logs and metrics. Recently, they noticed that the application in West US is experiencing high CPU usage (sustained above 90%) during peak hours, while the other regions remain below 60%. The team has set up an autoscale rule on the App Service plan to scale out when CPU exceeds 80% for 10 minutes. However, autoscale is not triggering, and the application in West US is becoming slow. The team has verified that the autoscale rule is correctly configured, the instance count is below the maximum, and there are no scale-in rules interfering. The metric data appears in Azure Monitor. You suspect that the metric alert that triggers autoscale is not firing. What is the most likely cause?

Accepted Answer

The autoscale rule is using the wrong metric aggregation or namespace, such as 'CpuTime' instead of 'Percentage CPU'.. The autoscale rule must use the correct metric name and aggregation to evaluate scaling conditions. If the rule is configured with 'CpuTime' instead of 'Percentage CPU', it will not match the actual CPU utilization metric emitted by the Azure App Service plan. 'Percentage CPU' is the standard platform metric for CPU load, while 'CpuTime' measures total CPU time consumed, which does not trigger the same threshold logic. Since the team verified the rule is correctly configured but autoscale is not firing, the most likely cause is a mismatch in the metric name or namespace.

Answer

The autoscale rule was created less than 24 hours ago and needs a learning period.

Answer

The metric collection interval for CPU is set to 30 minutes, causing a delay in autoscale evaluation.

Answer

The autoscale rule is configured to use Log Analytics queries instead of platform metrics.

Question 18

A company deploys a web application to Azure App Service. They want to monitor application performance and detect anomalies using Application Insights. Which two components should be configured?

Accepted Answer

Configure sampling to reduce data volume. Sampling in Application Insights reduces the volume of telemetry data while preserving statistically correct analysis, which is essential for managing cost and performance in high-traffic applications. Option D is correct because the application-side SDK (e.g., Application Insights SDK for .NET, Java, or Node.js) is required to instrument the code and collect detailed telemetry such as requests, dependencies, and exceptions for performance monitoring and anomaly detection.

Answer

Deploy the Azure Monitor agent on the App Service instance

Answer

Create a Log Analytics workspace and configure data collection rules

Answer

Enable diagnostics settings to stream logs to Event Hubs

Question 19

A company deploys a .NET Core web application to Azure App Service. The application uses Application Insights for monitoring. The operations team reports that dependency tracking is missing for calls to a third-party REST API made using HttpClient. The application is instrumented with the Application Insights SDK. Which action should be taken to enable dependency tracking for HttpClient calls?

Accepted Answer

Ensure the SDK is configured using services.AddApplicationInsightsTelemetry(); in the Startup.cs file.. `services.AddApplicationInsightsTelemetry()` in `Startup.cs` automatically registers the `DependencyTrackingModule` for .NET Core applications. This module collects dependency telemetry for `HttpClient` calls made via `IHttpClientFactory` or typed `HttpClient` instances, provided the SDK is properly configured. Since the application already uses the Application Insights SDK, this single line enables automatic dependency tracking without additional packages or agents.

Answer

Install the Application Insights Agent on the App Service instance.

Answer

Add a reference to Microsoft.ApplicationInsights.DependencyCollector and call DependencyTrackingModule.Initialize().

Answer

Use the Application Insights Status Monitor to enable dependency tracking.

Question 20

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?

Accepted Answer

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

Enable the Live Metrics Stream feature in Application Insights.

Answer

Configure adaptive sampling in the Application Insights SDK.

Answer

Enable Application Map in the Azure portal for each service.