Implement an instrumentation strategy practice questions

Deployment Frequency

Why it fails: The 'Deployment Frequency' view is a report in Azure DevOps Analytics, not a built-in analytics view in Application Insights.

Time to Restore Service

Why it fails: Time to Restore Service is a DORA metric, but it is not a built-in analytics view in Application Insights.

Azure DevOps Pipeline Telemetry

Why it fails: Azure DevOps Pipeline Telemetry is not a built-in analytics view; it refers to telemetry data that can be sent to Application Insights but not a predefined view.

Aggregate telemetry into 1-minute buckets before sending

Why it fails: Aggregating telemetry into 1-minute buckets before sending is not a valid reduction technique because Application Insights expects individual telemetry items with timestamps; pre-aggregated data is not accepted as standard telemetry and would lose the dimensional richness needed for diagnostics.

Set a maximum telemetry throughput limit on the Application Insights instance

Why it fails: Setting a maximum telemetry throughput limit on the Application Insights instance is not valid because Azure does not expose any such configuration; you cannot cap throughput at the ingestion layer, only manage volume via sampling or filtering in the SDK.

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

Why it fails: Diagnostic settings in Azure Monitor capture control-plane audit and kube-system logs for AKS, not the stdout/stderr container logs emitted by application pods. Container logs are collected via the Azure Monitor agent using a Data Collection Rule (DCR), so the absence of a diagnostic setting would not prevent container log ingestion.

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

Why it fails: Azure Monitor and Log Analytics workspaces support cross-region and cross-subscription data collection for AKS, so a different workspace region does not block container log ingestion. Region mismatch only adds slight egress latency or potential billing implications, but it would not cause the ContainerLogs table to remain empty.

The Azure Monitor agent version on the nodes is outdated.

Why it fails: The Azure Monitor agent on AKS nodes is automatically upgraded as part of the managed AKS service and Azure Monitor updates, so an outdated agent is rarely the root cause of missing container logs. Even if a node has an older agent version, the absence of the ContainerLogs table in the Data Collection Rule is the definitive reason the logs are not collected.

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

Why it fails: The Application Insights agent deployed as a DaemonSet collects node-level performance metrics and host counters, but it does not perform distributed tracing because it cannot propagate context or track dependencies across microservice calls.

Enable Azure Monitor Container Insights on the AKS cluster

Why it fails: Azure Monitor Container Insights collects performance metrics, container inventory, and logs from AKS into a Log Analytics workspace, but it does not support distributed tracing or correlate individual requests across microservices, so it cannot meet the tracing requirement.

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

Why it fails: Setting the connection string enables telemetry collection, and sampling reduces volume, but neither establishes cross-component correlation for Service Bus messages. Without an explicit operation ID linking the message to the function execution, the distributed trace will not show the full path from enqueue to completion.

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

Why it fails: While Azure Functions provides built-in Application Insights integration, the automatic correlation for Service Bus triggers does not always propagate a trace context from the message itself. The host-level integration collects telemetry but does not create a custom operation ID based on the Service Bus message ID, so end-to-end correlation across the messaging boundary is incomplete.

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.

Why it fails: Sending Service Bus diagnostic logs to Log Analytics captures platform events but does not create Application Insights distributed traces. Joining logs in Kusto is an after-the-fact analysis technique and does not provide the live, correlated trace view in Application Insights. It also does not insert the required operation ID into the function's telemetry.

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

Why it fails: Diagnostics logging in App Service captures text-based logs (application, web server, failed request tracing) and streaming them to Application Insights only forwards raw log output; it does not produce the structured telemetry (requests, dependencies, exceptions) that Application Insights relies on for end-to-end transaction monitoring, so it is insufficient for full instrumentation.

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

Why it fails: Installing the Microsoft.ApplicationInsights.AspNetCore NuGet package and adding services.AddApplicationInsightsTelemetry() in Startup.cs enables full Application Insights SDK instrumentation, but it requires modifying application code, rebuilding, and redeploying the app—contradicting the goal of minimizing code changes; the site extension accomplishes the same telemetry coverage without touching code.

Add the Application Insights JavaScript SDK to each page.

Why it fails: Adding the Application Insights JavaScript SDK to each page only captures client-side/browser telemetry such as page views, AJAX calls, and client exceptions; it does not monitor server-side request handling, dependencies, or performance counters, and requires invasive per-page code modifications, making it incomplete for server-side monitoring and contrary to the no-code-change objective.

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

Why it fails: While you can use REST APIs to pull pipeline run details, it requires custom code to handle pagination, authentication, and data transformation, and it doesn't provide the pre-aggregated performance metrics that Analytics does. The Analytics OData endpoint is the supported, scalable way to query telemetry.

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

Why it fails: The Azure DevOps CLI has commands for managing boards, repos, pipelines, and artifacts, but there is no 'az devops telemetry publish' command. Telemetry ingestion into Application Insights is done via the Application Insights SDK or HTTP API, not through the DevOps CLI.

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

Why it fails: Azure DevOps provides built-in Analytics widgets and dashboards with pre-defined pipeline charts, but there is no dedicated 'Pipeline Telemetry' dashboard that can be customized or exported to Application Insights. You cannot stream raw telemetry to your own monitoring solution from these stock views.

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

Why it fails: Azure Blob Storage is an object store designed for archival and unstructured data, not for interactive log analytics. Azure Storage Analytics provides only coarse-grained metrics and limited querying (e.g., per-hour transaction logs), which cannot efficiently filter or aggregate container stdout/stderr at the scale required for centralized logging.

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

Why it fails: Azure Event Hubs is a high-throughput ingestion and transport service, not a storage or query engine. While streaming logs to Event Hubs is suitable for real-time event ingestion, it still requires a downstream analytics store (like Azure Data Explorer) for querying; using Event Hubs alone as the log store would not meet centralized logging requirements, and adding Azure Data Explorer lacks native AKS integration compared to Container Insights.

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

Why it fails: Application Insights is designed for application-level telemetry (requests, traces, exceptions) generated from code instrumentation, not for bulk infrastructure log ingestion. Deploying the Application Insights agent as a DaemonSet to capture stdout/stderr logs would flood Application Insights with high-volume, low-value logs, resulting in excessive cost and poor query performance; it also bypasses the built-in Log Analytics integration that Azure Monitor provides for AKS log collection.

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

Why it fails: A SQL Server firewall rule blocks traffic at the network or login layer, producing an immediate connection failure or login error before the application can acquire a connection; it does not cause wait-based timeouts after the connection pool is already in use, so this is not the cause of intermittent timeout symptoms.

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

Why it fails: Deadlocks are detected by SQL Server's lock manager and immediately terminated with error 1205, not by the application waiting for a connection timeout; enabling read committed snapshot isolation can reduce deadlock occurrences but does not affect connection pool timeout behavior.

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

Why it fails: Exceeding the DTU limit causes Azure SQL Database to throttle or queue queries, typically surfacing as performance degradation or resource-wait errors such as DTU waits, not as connection timeout exceptions from the application; scaling the service tier would not address a connection pool exhaustion issue.

Lead Time for Changes

Why it fails: Lead Time for Changes measures the time from code commit to production deployment, which reflects delivery speed and pipeline efficiency. It does not directly measure reliability, as a short lead time can coexist with frequent failures, so it is a velocity metric rather than a reliability indicator.

CPU Usage

Why it fails: CPU Usage is an infrastructure performance metric that tracks resource utilization, not an indicator of deployment reliability or service quality. It may be relevant for capacity planning or detecting performance bottlenecks, but it does not align with DORA's four key metrics for measuring software delivery reliability.

Deployment Frequency

Why it fails: Deployment Frequency measures how often a team successfully releases new features or fixes to production, reflecting delivery throughput and agility. High deployment frequency is a sign of efficient DevOps practices but does not directly assess the stability or reliability of those releases, so it is a velocity metric rather than a reliability metric.

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

Why it fails: The severity of an Azure Monitor alert does not control whether the alert fires; it only classifies the impact. Severity 2 is a valid, non-suppressing severity level, so this choice incorrectly attributes suppression to severity.

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

Why it fails: The metric name 'requests/count' is not misspelled. In Application Insights, this is the standard metric identifier for the count of server requests, published under the 'azure.applicationinsights' metric namespace. The slash is an inherent part of the metric name, not a typo, and it is case-sensitive exactly as documented. Therefore, the alert rule's metric definition is valid, and the failure to fire is not due to a misspelled metric.

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

Why it fails: The dimension filter for 'request/resultCode' with the value '500' is valid and will match only requests with that exact result code. Azure Monitor dimension filters for this metric use exact values, not wildcards, so adding '5xx' is unnecessary and would not work as expected.

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

Why it fails: A missing await would surface as an incomplete Task or unexpected ordering, not a null _dbContext field. Unawaited calls are the classic cause of race conditions in async code, but a null injected dependency points to dependency injection registration or disposal instead.

The database connection string is invalid in appsettings.json.

Why it fails: A null _dbContext indicates the dependency was never injected or constructed, not that its connection string was rejected — an invalid string would throw a configuration or SQL exception after successful instantiation. Connection-string validation belongs to configuration troubleshooting, where the context object itself exists but cannot open a database session.

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

Why it fails: Incorrect. A missing null check is a coding oversight that would allow the NullReferenceException to be thrown, but it is not the root cause. The root cause is that _dbContext is null because the DbContext was never injected.

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

Why it fails: Scaling AKS nodes only adds compute capacity (CPU, memory, pod slots); it does not change the per-process connection pool limit that each pod's Redis or SQL client is bound by. If the true bottleneck is connection pool exhaustion or high dependency latency (e.g., p99 SQL calls), more nodes can actually amplify the problem by introducing more concurrent calls to the same dependency, saturating it further. This masks symptoms at the infrastructure layer while increasing cost and operational complexity, without addressing the measured telemetry that points to a dependency-level root cause.

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

Why it fails: Proper connection disposal using 'using' statements is a best practice, but inspecting code without first using telemetry to confirm the actual failure point is inefficient; resource leaks would typically manifest as connection pool timeouts or exhausted pools, which can be confirmed through Application Insights dependency telemetry rather than a blind code review.

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

Why it fails: A load test can stress the system but it uses synthetic or artificial traffic that may not reflect production data patterns, user behavior, or the exact dependency load; running it against a production-like environment introduces overhead and delays without giving the direct observability into the specific Redis/SQL latency provided by Application Insights dependency tracking.

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

Why it fails: Auto-instrumentation adds spans for supported frameworks but does not propagate W3C traceparent headers across your own service calls; each service still starts a new trace. It suits quick onboarding of a single app without custom code, yet the SDKs are already installed, so context propagation must be configured there.

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

Why it fails: Exporting spans to Azure Monitor only changes the destination of telemetry; it does not propagate trace context between services. Correlation requires W3C traceparent headers to be injected on outbound calls and extracted on inbound ones, which the default propagator already handles once configured. The exporter is genuinely needed to route data to Application Insights.

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

Why it fails: A shared service name groups spans under one cloud role, but correlation depends on propagating the trace ID and parent span ID across HTTP calls, not on naming. Identical names actually merge distinct services in Application Insights. Service naming is for logical grouping and filtering within the Application Map.

Use metric alerts only for simple threshold-based conditions.

Why it fails: Metric alerts are not limited to simple threshold-based conditions; they support multiple conditions on a single or multiple metrics and dynamic thresholds that use machine learning to adapt to historical patterns. Restricting them to only static thresholds overlooks capabilities such as AND/OR logic across dimensions or separate metrics, which can express complex operational requirements without requiring multiple rules. This misconception leads to underutilizing Azure Monitor's flexible signal combination features.

Create separate alert rules for each condition to avoid complexity.

Why it fails: Creating separate alert rules for each condition increases management overhead, duplicates configuration logic, and amplifies alert fatigue because the same underlying issue may trigger multiple notifications. Azure Monitor allows a single metric alert rule to contain multiple conditions combined with AND/OR operators, letting you consolidate related signals and reduce rule sprawl. The best practice is to combine related conditions into an efficient rule that simplifies maintenance and provides a clearer incident picture.

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

Why it fails: Action groups are intentionally designed for reuse across multiple alert rules, enabling centralized administration of notification and automation settings. Requiring a unique action group per rule creates unnecessary duplication, makes compliance and contact-list changes tedious, and increases the risk of inconsistent configuration across the environment. This approach contradicts Azure's recommended pattern, which leverages shared action groups to reduce administrative burden and maintain a single, reliable notification model.

The workspace resource ID is incorrectly formatted.

Why it fails: The workspace resource ID is incorrectly formatted. The resource ID is actually well-formed because it follows the standard Azure Resource Manager format '/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.OperationalInsights/workspaces/<workspace-name>', with a valid subscription ID, resource group, and workspace name, so this is not the cause of the collection failure.

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

Why it fails: The counter specifier uses the wrong format for Windows performance counters. The specifier '\\Processor(_Total)\\% Processor Time' is the standard and correct WMI/Logman format for Windows performance counters, where the object, instance, and counter are separated by backslashes and parentheses, so the format is valid and not a contributing factor.

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

Why it fails: The sampling frequency of 60 seconds is too low and data is being throttled. In Azure Monitor DCRs, performance counter collection supports a 'scheduledTransferPeriod' or sampling interval in seconds, and 60 seconds is a valid, typical interval for Windows performance counters; it does not cause throttling because throttling is based on data volume and rate limits, not a 60-second sample frequency.

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

Why it fails: Autoscale rules take effect immediately after creation; there is no 24-hour learning period, though the service uses a look-back window (typically the last 10 minutes) of metric data to evaluate the threshold, so short metric history may delay a valid trigger but does not require a full day of warm-up.

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

Why it fails: Autoscale evaluation is driven by Azure Monitor platform metrics, which are collected and published at a default interval of one minute for supported resources, and the autoscale engine polls these metrics on its own schedule (usually every 1–5 minutes); a separate 'collection interval' of 30 minutes only affects diagnostics/export settings and cannot cause a delay in autoscale because the autoscale engine does not rely on that setting.

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

Why it fails: Autoscale rules are limited to Azure Monitor platform metrics emitted by the underlying resource (such as CPU, memory, or request counts); they cannot directly use Log Analytics queries as a metric source, and attempting to configure a query-based signal would not be accepted, so the rule would not work as designed.

Deploy the Azure Monitor agent on the App Service instance

Why it fails: Azure Monitor agent is designed for Azure VMs and on-premises servers, not for App Service, which runs in a managed, sandboxed environment. App Service provides its own diagnostics and monitoring integration, so deploying this agent is neither supported nor relevant for anomaly detection.

Create a Log Analytics workspace and configure data collection rules

Why it fails: A Log Analytics workspace is the storage and query engine for telemetry, but it does not detect anomalies by itself. Anomaly detection requires alert rules, analytic queries, or machine learning capabilities built on top of the data, so simply creating a workspace and data collection rules does not directly identify anomalies.

Enable diagnostics settings to stream logs to Event Hubs

Why it fails: Diagnostic settings streaming logs to Event Hubs deliver platform-level logs and metrics, not the application-specific performance telemetry like HTTP requests and dependency calls that anomaly detection requires. This creates a downstream pipeline for platform data, but it does not directly address the need for application performance anomaly detection.

Install the Application Insights Agent on the App Service instance.

Why it fails: The Application Insights Agent is a codeless attach option primarily for .NET Framework or IIS-hosted apps; when the Application Insights SDK is already added via AddApplicationInsightsTelemetry(), installing the Agent is redundant and unnecessary for dependency tracking in a .NET Core App Service.

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

Why it fails: Manually adding Microsoft.ApplicationInsights.DependencyCollector and invoking DependencyTrackingModule.Initialize() is a low-level invocation intended for custom bootstrapping when you are not using the standard AddApplicationInsightsTelemetry() extension. Because AddApplicationInsightsTelemetry() already registers and initializes the dependency collector as part of its default pipeline, performing an explicit Initialize() afterward is redundant and can cause duplicate dependency telemetry or double initialization. In an Azure App Service with the SDK already configured, this manual step adds risk without contributing any additional tracking capability.

Use the Application Insights Status Monitor to enable dependency tracking.

Why it fails: Application Insights Status Monitor is a legacy on-premises tool for instrumenting .NET Framework applications by attaching to IIS or modifying web.config; it is not used for .NET Core applications running on Azure App Service, where the SDK is the proper way to enable dependency tracking.

Enable the Live Metrics Stream feature in Application Insights.

Why it fails: 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.

Configure adaptive sampling in the Application Insights SDK.

Why it fails: 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.

Enable Application Map in the Azure portal for each service.

Why it fails: 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.