Implement an instrumentation strategy practice questions

Aggregate telemetry into 1-minute buckets before sending

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

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

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

Deployment Frequency

Why wrong: 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 wrong: 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 wrong: 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.

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

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: Incorrect. A race condition from an unawaited database call would not cause _dbContext to be null; it would cause unexpected behavior or exceptions on the database operation itself.

The database connection string is invalid in appsettings.json.

Why wrong: Incorrect. An invalid database connection string would cause a failure when trying to open a connection (e.g., SqlException), not a NullReferenceException on the DbContext instance.

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

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: Auto-instrumentation is for metrics, not trace context propagation.

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

Why wrong: Exporter choice does not affect context propagation.

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

Why wrong: Service name is for identification, not trace correlation.

Use metric alerts only for simple threshold-based conditions.

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

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

Why wrong: 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 wrong: 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.

Install the Application Insights Agent on the App Service instance.

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

Step 1: Create a new feed, Step 2: Set feed permissions, Step 3: Configure upstream sources, Step 4: Publish NuGet packages, Step 5: Consume packages from feed

Why wrong: Configuring upstream sources after feed permissions is incorrect because upstream sources are a core feed-level setting that affects how all packages are resolved and cached. If you lock down permissions first, you may inadvertently block the account or build service principal from adding or modifying upstream sources, since that action requires feed management rights. Upstream sources should be set immediately after feed creation so that any subsequent publish or restore operations can automatically save dependencies from external sources.

Step 1: Create a new feed, Step 2: Publish NuGet packages, Step 3: Configure upstream sources, Step 4: Set feed permissions, Step 5: Consume packages from feed

Why wrong: Publishing NuGet packages before configuring upstream sources defeats the purpose of upstream caching, because during the publish operation the feed cannot yet see nuget.org or other upstream feeds to save missing dependencies. Additionally, setting feed permissions after publishing means you have no access control over who pushed packages beforehand — the feed is still using its default permissions, which may allow any project contributor to publish. Permissions must be established prior to any publishing to enforce a trusted contributor set.

Step 1: Create a new feed, Step 2: Configure upstream sources, Step 3: Publish NuGet packages, Step 4: Set feed permissions, Step 5: Consume packages from feed

Why wrong: Setting feed permissions after packages have already been published exposes your feed to unauthorized or accidental pushes, because Azure Artifacts' default permissions grant contribute rights to every project contributor. By the time you restrict permissions, malicious or incorrect packages may already be present, and you cannot retroactively prevent them from having been published. The correct order places permissions before publishing but after upstream sources are configured, ensuring the feed’s access model is enforced from the first push.