AZ-400 Implement an instrumentation strategy — Timed 15 Questions

Question 1

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.. Option A is correct because 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 2

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.. Option D is correct because 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 3

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 4

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?

Accepted Answer

Deployment Frequency. The Deployment Frequency analytics view in Application Insights is specifically designed to track how often deployments occur and the rate at which they fail, directly aligning with the goal of capturing deployment frequency and change failure rate. This view leverages data from Azure DevOps pipelines to provide these metrics without requiring custom queries or additional instrumentation.

Answer

Application Dashboard

Answer

Time to Restore Service

Answer

Azure DevOps Pipeline Telemetry

Question 5

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 6

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 7

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. Option B is correct because fixed-rate sampling in Application Insights randomly selects a percentage of telemetry items to send, reducing volume predictably while preserving a representative sample for diagnostics. This technique is ideal when you need consistent, controllable data reduction without losing the ability to detect trends and anomalies across all telemetry types.

Answer

Aggregate telemetry into 1-minute buckets before sending

Answer

Set a maximum telemetry throughput limit on the Application Insights instance

Question 8

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.. Option B is correct because 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 9

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 Index page model is not registered in the dependency injection container.. The Snapshot Debugger shows _dbContext is null, which indicates the dependency was never injected. In ASP.NET Core, page models like IndexModel must be registered in the dependency injection (DI) container (e.g., via AddTransient or AddScoped) for DI to resolve and inject the DbContext. Without registration, the runtime creates the page model manually, leaving _dbContext uninitialized and causing a NullReferenceException when OnGet accesses it.

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 10

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.. Option D is correct because 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 11

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 'ContainerLogs' 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 12

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.. Option A is correct because 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 13

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.. Option B is correct because 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 14

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 15

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'.. Option A is correct because 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.