Monitor, troubleshoot, and optimize Azure solutions practice questions

exceptions | where timestamp > ago(24h) | extend exceptionType = tostring(customDimensions.['ExceptionType']) | summarize Count=count() by exceptionType, url = tostring(customDimensions.['Url'])

Why it fails: Exception data typically does not store URL in customDimensions by default. The URL is available in the requests table, not directly in exceptions. This approach is unreliable.

requests | where timestamp > ago(24h) and success == false | extend exceptionType = tostring(resultCode) | summarize Count=count() by exceptionType, url

Why it fails: This only covers failed requests (HTTP errors), not custom exceptions caught in code. It also uses resultCode as exceptionType, which is not accurate.

exceptions | where timestamp > ago(24h) | extend exceptionType = tostring(innermostType) | summarize Count=count() by exceptionType

Why it fails: This returns the count per exceptionType but does not include the URL, which the requirement specifies.

Availability test (URL ping test)

Why it fails: A URL ping test from multiple locations checks the HTTP status and response time, meeting the requirement.

Multi-step web test

Why it fails: Multi-step tests are for recording a sequence of steps, which is more than needed for a simple homepage check.

Custom metric test

Why it fails: Custom metrics are for sending custom telemetry, not for synthetic availability monitoring.

A manually exported CSV report

Why it fails: Manual exports are not proactive alerting controls.

A public IP address on the app

Why it fails: A public IP is not required for alerting.

Azure Policy compliance scan

Why it fails: Azure Policy compliance scans evaluate resource configuration against governance rules; they emit no request or dependency telemetry. Distributed tracing requires Application Insights, which correlates operations across the App Service and its downstream calls. Policy is tempting when the goal is enforcing standards across subscriptions, not diagnosing runtime behaviour.

Cost Management budgets only

Why it fails: Cost Management budgets track and alert on Azure spend against thresholds; they capture no per-request or dependency timing data. Application Insights provides the distributed tracing the scenario requires. Budgets are tempting when the concern is controlling expenditure, which is a billing-governance task, not observability.

Storage account static website logs

Why it fails: Static website logs record blob-service access to hosted static content, not application request or dependency spans. Application Insights auto-instrumentation on App Service is what produces the correlated distributed trace. Static website logging is tempting when hosting a single-page app in a storage account and auditing content requests.

Move the app to a larger App Service plan

Why it fails: App Service plan size governs compute resources, not telemetry volume, so scaling up leaves ingestion rates and cost unchanged. It is tempting because larger plans help with CPU or memory pressure, and would be the right answer if the app were throttled by resource limits rather than emitting excessive telemetry.

Disable all exception telemetry

Why it fails: Disabling exception telemetry removes an entire diagnostic signal, so failures become invisible and the remaining data loses statistical usefulness. It is tempting as a blunt cost cut, and would suit a scenario where exception logging itself causes an outage or where a separate error-tracking system already captures those events.

Increase log verbosity to debug

Why it fails: Raising verbosity to debug increases the volume of ingested telemetry, directly worsening the cost problem rather than reducing it. It is tempting during active troubleshooting, and would be correct if the goal were richer diagnostics for a specific incident, not sustained ingestion reduction.

Azure Advisor

Why it fails: Azure Advisor acts as a personalized cloud consultant, providing actionable recommendations to optimize Azure deployments across five pillars: cost, security, reliability, operational excellence, and performance. It analyzes resource configurations and usage patterns over time to suggest improvements, but it does not offer real-time monitoring or granular insights into individual SQL query performance or duration from an application perspective. Its focus is on long-term best practices rather than immediate operational metrics.

Azure Monitor Logs

Why it fails: Azure Monitor Logs, powered by a Log Analytics workspace, is a robust platform for collecting, indexing, and querying log and telemetry data from various Azure resources and applications. While SQL Database diagnostic logs can be routed here, and custom KQL queries can extract performance insights, it primarily functions as a data store and query engine, not an out-of-the-box, real-time monitoring solution specifically designed for application-driven SQL query performance. It requires significant configuration and custom querying to achieve the desired level of specific query performance monitoring and alerting.

Azure SQL Analytics

Why it fails: Azure SQL Analytics, often integrated into the Azure portal as Query Performance Insight or Intelligent Insights for Azure SQL Database, is a specialized monitoring solution focused on database-side performance. It leverages the Query Store feature to collect detailed query execution statistics, including CPU usage, duration, and execution counts for individual queries. This tool provides deep insights into query plans, wait statistics, and resource consumption directly from the database engine, making it ideal for identifying and optimizing long-running or resource-intensive queries from the database perspective.

Live Metrics Stream

Why it fails: Live Metrics doesn't show dependency relationships.

Application Insights Profiler

Why it fails: Profiler traces code execution but not dependency latency.

Search

Why it fails: Search allows querying individual telemetry items but doesn't provide a holistic view.

Allows all traffic

Why it fails: This statement is incorrect because a Web Application Firewall (WAF) custom rule with an 'Action' set to 'Block' is fundamentally designed to restrict access, not permit all traffic. The presence of specific 'MatchConditions' and an explicit 'Block' action ensures that certain requests will be denied, preventing universal access to the web app and contradicting the idea of allowing all traffic.

Blocks traffic from 192.168.1.0/24 and 10.0.0.0/8

Why it fails: This option misinterprets the effect of 'NegateCondition: true' in a WAF rule. When 'NegateCondition' is true, the rule's action is triggered when the specified 'MatchCondition' is *false*. Therefore, if the 'MatchCondition' is 'IPMatch' for '192.168.1.0/24' or '10.0.0.0/8', and 'NegateCondition' is true, the rule will block traffic *not* originating from these IP ranges, rather than blocking traffic *from* them.

Allows traffic from 192.168.1.0/24 and 10.0.0.0/8

Why it fails: While traffic *from* these IP ranges would indeed be allowed (because it doesn't trigger the block rule), this option incorrectly states that the rule's *action* is to 'Allow' traffic. The rule's explicit 'Action' is 'Block', and it blocks traffic that *doesn't* match the specified IPs. Therefore, the rule itself is a blocking rule, not an allowing rule, even if its net effect is to permit traffic from certain sources.

Allows Contributors to create virtual machines

Why it fails: Incorrect. Azure Policy does not grant permissions, and the roleDefinitionId condition cannot be used to allow VM creation.

Audits when Contributors create virtual machines

Why it fails: Incorrect. Auditing would still require a valid condition, which does not exist for the initiator's roleDefinitionId.

Deploys a virtual machine when a Contributor action occurs

Why it fails: Incorrect. DeployIfNotExists is not triggered by a Contributor action, and roleDefinitionId cannot be used as described.

API server request latency

Why it fails: API server request latency measures the responsiveness of the Kubernetes control plane, indicating how quickly requests to manage cluster resources (like creating or updating pods) are processed. While critical for the overall health and operability of the cluster's management plane, it does not directly reflect the performance or resource utilization of the *workloads* running within the pods. Therefore, it's not a primary metric for determining if *applications* need scaling due to resource constraints.

Network bytes sent and received

Why it fails: While network bytes sent and received provides insight into network traffic volume, it is generally a less direct indicator for determining the need to scale *application workloads* compared to CPU, memory, or disk I/O. High network traffic might be a symptom of an application's behavior, but it doesn't inherently mean the application itself is resource-constrained on the node in terms of compute or memory. Other metrics are more immediate indicators of performance bottlenecks requiring scaling.

Enable Always On to keep the app warm

Why it fails: Always On increases cost.

Increase function timeout to reduce retries

Why it fails: Doesn't reduce cost.

Enable clustering for the cache

Why it fails: Clustering provides scalability but does not directly reduce evictions.

Enable data persistence using RDB or AOF

Why it fails: Persistence saves data to disk but does not prevent evictions.

Upgrade to a higher-tier Azure Cache for Redis

Why it fails: Upgrading changes the instance, not a configuration change on the current cache.

Azure Activity Log

Why it fails: The Azure Activity Log primarily tracks control-plane operations, such as resource creation, updates, deletions, and service health events. It provides insights into who performed what action on which resource and when, but it does not capture data-plane operations or detailed performance metrics like individual slow database queries. Therefore, it cannot diagnose the root cause of a slow web application related to database query execution.

Azure Advisor

Why it fails: Azure Advisor provides personalized recommendations to optimize cost, performance, reliability, operational excellence, and security across your Azure resources. While it offers proactive guidance and might suggest general performance improvements, it does not provide real-time diagnostic capabilities or granular insights into specific slow database queries causing application slowness. Its function is advisory, not detailed performance troubleshooting.

Azure Monitor Metrics

Why it fails: Azure Monitor Metrics collects numerical data from your Azure resources at regular intervals, such as CPU utilization, memory usage, or I/O operations per second for a database. While these metrics can indicate that a performance issue exists (e.g., high CPU on the SQL server), they do not provide the granular detail needed to identify which specific queries are slow, their execution plans, or wait statistics. It offers high-level performance counters, not query-level diagnostics.

Azure Network Watcher

Why it fails: Azure Network Watcher is a suite of tools specifically designed for monitoring, diagnosing, and auditing network performance and connectivity within Azure. While network-related problems can indirectly affect VM performance, Network Watcher focuses on network-specific issues such as packet flow, routing, and security group configurations. It does not directly provide insights into internal VM resource utilization, application performance, or operating system-level metrics, which are crucial for diagnosing VM performance directly.

Azure Backup reports

Why it fails: Azure Backup reports are primarily focused on providing detailed information regarding the operational health, compliance, and auditing of backup jobs and recovery services. These reports track the success or failure of backups, data transfer volumes, and adherence to retention policies for protected resources. They do not offer any metrics or insights into the real-time or historical performance of the virtual machines or the applications running within them, making them irrelevant for performance diagnosis.

Configure Application Insights continuous export to a storage account and build an Azure Logic App to parse the blobs and send an email when errors exceed 5%.

Why it fails: Continuous export is deprecated and requires custom parsing logic, adding significant configuration and maintenance overhead. While it can work, it does not minimize effort or cost as requested. The native metric alert on Function Execution Count already provides the needed error-rate notification without additional services.

Enable diagnostic settings to send Function App logs to a Log Analytics workspace and create a scheduled query alert that counts failed executions in the last 15 minutes.

Why it fails: Log Analytics scheduled query alerts are powerful but incur ingestion and retention costs, and require writing KQL and configuring a workspace. This is more effort and cost than a simple metric alert on an existing platform metric. The scenario explicitly asks to minimize configuration effort and cost.

Use the Azure Functions Core Tools to run 'func azure functionapp logstream' and set up a local script to monitor the stream and send notifications.

Why it fails: Log streaming is a real-time debugging tool, not a production alerting mechanism. It requires a continuously running local client and custom scripting, which is neither reliable nor cost-effective. It also lacks built-in alerting and cannot automatically evaluate a 15-minute error-rate threshold.

Add the correlation ID as a custom property on the Activity using 'activity.SetTag("correlationId", correlationId)' and configure the Application Insights SDK to map it.

Why it fails: Setting a custom tag on the Activity does not automatically make it a filterable property in Application Insights. The OpenTelemetry exporter maps only specific tags to customDimensions; arbitrary tags may be dropped or not indexed. To filter by a custom property, you must use the appropriate API such as adding a custom property to the telemetry item directly.

Implement an ITelemetryInitializer that reads the HTTP header and adds it to the telemetry item's Properties collection.

Why it fails: ITelemetryInitializer is part of the classic Application Insights SDK, not the OpenTelemetry-based Azure Monitor exporter. The scenario specifies using Azure.Monitor.OpenTelemetry.AspNetCore, which does not support ITelemetryInitializer. Using it would require switching SDKs and is not the correct approach for the OpenTelemetry library.

Use the 'Activity.Current.AddBaggage("correlationId", correlationId)' method to add the correlation ID as baggage, which is automatically propagated and stored as a custom dimension.

Why it fails: Baggage is propagated across service boundaries but is not automatically stored as a custom dimension in Application Insights. It is intended for context propagation, not for telemetry enrichment. While it can be exported, it requires additional configuration and is not the direct method to ensure the correlation ID appears as a filterable property.

Use the 'DefaultAzureCredential' class from Azure.Identity to authenticate the Azure Monitor Query client.

Why it fails: While 'DefaultAzureCredential' is a convenient way to authenticate, it attempts multiple credential types, including managed identity and developer credentials. For a service principal running in production, it is more secure and predictable to use 'ClientSecretCredential' or 'ClientCertificateCredential' directly. The question asks for actions to authenticate as a service principal, not the credential class to use.

Assign the 'Contributor' role to the service principal at the subscription scope.

Why it fails: 'Contributor' is far too permissive, granting full management access to all resources in the subscription. It violates the principle of least privilege. The application only needs to read monitoring data, so a read-only role scoped to the Application Insights resource is sufficient and appropriate.

Assign the 'Log Analytics Reader' role to the service principal at the Log Analytics workspace scope.

Why it fails: 'Log Analytics Reader' grants read access to Log Analytics workspaces, but Application Insights resources may not be workspace-based. Even if they are, scoping to the workspace grants access to all data in that workspace, which may include other resources. For least privilege specific to an Application Insights resource, 'Monitoring Reader' at that resource is more precise.

Fixed-rate sampling with a 1% rate

Why it fails: Fixed-rate sampling applies a constant sampling percentage, such as 1%, to all telemetry items, regardless of the current traffic volume. While it offers predictable data volume under stable load, it fails to adapt to the fluctuating high volume characteristic of an e-commerce application. During traffic spikes, a fixed 1% rate could still lead to excessive data ingestion and costs, or conversely, during lulls, it might collect too little data for meaningful analysis, making it inefficient for dynamic workloads.

Ingestion sampling

Why it fails: "Ingestion sampling" is not a recognized or configurable sampling method within Azure Application Insights. Application Insights primarily offers SDK-based sampling (fixed-rate and adaptive) and a form of "daily cap" which limits total ingestion but isn't a proactive sampling strategy. While data might be dropped if a daily cap is exceeded, this isn't a configurable, intelligent sampling mechanism like adaptive sampling, making it an incorrect choice for managing high-volume telemetry.

Head-based sampling

Why it fails: Head-based sampling, often used in distributed tracing systems, makes sampling decisions at the very beginning of a request's lifecycle, typically based on a trace ID. This ensures that all telemetry items related to a single request are either fully sampled or fully dropped, preserving the complete context of a transaction. However, Azure Application Insights does not natively implement head-based sampling as a configurable option, instead relying on adaptive or fixed-rate sampling for its telemetry collection.

Logs

Why it fails: Logs store and query historical telemetry through Log Analytics, introducing ingestion latency rather than streaming live CPU percentage. It is tempting because metrics can be routed into logs for analysis, but real-time CPU utilisation on a VM is surfaced by Metrics, which provides near-instant time-series values.

Alerts

Why it fails: Alerts evaluate metric or log rules and trigger notifications when thresholds breach; they do not display live CPU percentage themselves. It is tempting because CPU monitoring commonly involves alerting, but the stem asks which feature surfaces real-time utilisation, which is Metrics.

Workbooks

Why it fails: Workbooks are interactive reports combining queries, text and visualisations over existing telemetry; they render data rather than collect live CPU values. It is tempting because dashboards appear to show utilisation, but the underlying real-time CPU data comes from Metrics, which Workbooks merely visualise.

Live Metrics.

Why it fails: Live Metrics Stream in Application Insights provides a real-time, minute-by-minute view of your application's health, including requests, failures, and performance counters. While useful for immediate operational monitoring and spotting sudden spikes or drops, it aggregates data and does not offer the granular, code-path tracing necessary to pinpoint specific slow methods or lines of code causing performance bottlenecks. It's a high-level operational dashboard, not a diagnostic profiler.

Snapshot Debugger.

Why it fails: The Snapshot Debugger for Azure App Services is designed to automatically collect debug snapshots from live web applications when an exception occurs. It allows developers to inspect the state of variables and call stacks at the moment of an exception without impacting the live application's performance. However, it is not intended for diagnosing general application slowness or performance degradation that doesn't manifest as an unhandled exception, as it requires a specific trigger point.

Availability tests.

Why it fails: Application Insights Availability tests are external monitors that periodically send web requests to your application from various global locations to assess its uptime and responsiveness. These tests confirm if your application is accessible and performing within expected thresholds from an end-user perspective. However, they provide no insight into the internal execution flow or specific code paths that might be causing performance issues once a request successfully reaches the application.