Courseiva

CCNA Monitor, troubleshoot, and optimize Azure solutions Questions

75 of 102 questions · Page 1/2 · Monitor, troubleshoot, and optimize Azure solutions · Answers revealed

Practice these questionsDomain overviewAll questions
1
MCQmedium

Your Azure web app is running in a production environment. Users report that the app is slow. You need to identify the root cause without impacting production traffic. Which approach should you use?

A.Enable Application Insights Profiler
B.Enable Application Insights sampling at 100%
C.Run a load test in a staging slot
D.Review server logs in the web app
AnswerA

Application Insights Profiler is specifically designed for diagnosing performance issues in production environments with minimal impact. It continuously collects detailed execution traces, including CPU usage, garbage collection events, and call stacks, allowing developers to pinpoint exact code paths, database queries, or external service calls that are contributing to slowness. This granular visibility into application behavior is crucial for identifying root causes of performance bottlenecks without requiring code changes or redeployments.

Why this answer

Application Insights Profiler provides detailed, per-request performance traces that pinpoint which code paths are consuming the most time, enabling root cause analysis of slow responses without altering production traffic. Unlike sampling or logs, Profiler captures execution data on-demand or automatically with minimal overhead, making it ideal for diagnosing latency issues in a live environment.

Exam trap

The trap here is that candidates often confuse high-level monitoring (logs, metrics) with diagnostic profiling, assuming that more data (100% sampling) or separate testing (staging slot) will solve the problem, when in fact Profiler is the only tool designed for low-overhead, code-level latency analysis in production.

How to eliminate wrong answers

Option B is wrong because enabling sampling at 100% would capture every telemetry event, significantly increasing data volume and cost, and could impact app performance due to the overhead of transmitting all telemetry, which defeats the goal of not affecting production traffic. Option C is wrong because running a load test in a staging slot tests synthetic traffic, not the actual production workload causing user-reported slowness, so it cannot identify the real root cause. Option D is wrong because reviewing server logs provides high-level error and request counts but lacks the granular, code-level timing details needed to pinpoint specific slow code paths, making it insufficient for root cause analysis of performance issues.

Practice this question →
2
MCQmedium

You are monitoring an Azure Web App using Application Insights. You need to track the duration and status code of an external API call made by the app. Which Application Insights feature should you use?

A.Built-in request telemetry (server-side requests)
B.Dependency tracking feature
C.Custom events (TrackEvent)
D.Page view tracking
AnswerB

Dependency tracking is designed to automatically monitor and collect telemetry for outbound calls made by your application to external services, databases, or other APIs. It captures critical details such as the target dependency's name, call duration, success/failure status, and associated exception messages, providing crucial insights into external service performance. This feature is essential for understanding how your application interacts with and is affected by its external dependencies, enabling effective distributed tracing and troubleshooting.

Why this answer

Dependency tracking in Application Insights is specifically designed to monitor calls made by your application to external services, such as APIs, databases, or HTTP endpoints. It automatically captures the duration, success/failure status, and response code of outbound HTTP requests, making it the correct choice for tracking an external API call's duration and status code.

Exam trap

The trap here is that candidates confuse 'request telemetry' (incoming calls to the app) with 'dependency telemetry' (outgoing calls from the app), leading them to incorrectly select built-in request telemetry for monitoring external API calls.

How to eliminate wrong answers

Option A is wrong because built-in request telemetry (server-side requests) tracks incoming HTTP requests to your web app, not outbound calls to external APIs. Option C is wrong because custom events (TrackEvent) are used for logging custom business events or user actions, not for automatically capturing the duration and status code of HTTP calls. Option D is wrong because page view tracking monitors client-side page loads and user navigation, not server-side outbound API call metrics.

Practice this question →
3
MCQmedium

Your e-commerce application sends telemetry to Application Insights. You need to reduce ingestion costs while preserving the ability to detect trends in performance metrics. Which sampling type should you configure?

A.Fixed-rate sampling
B.Adaptive sampling
C.Ingestion sampling
D.Head-based sampling
AnswerB

Adaptive sampling dynamically adjusts the sampling rate based on the current telemetry volume and a configured target data ingestion rate. This intelligent approach ensures that the total volume of collected telemetry remains within a manageable budget, preventing excessive costs while still capturing a statistically representative dataset. By continuously monitoring and adapting, it effectively preserves the statistical accuracy needed for trend analysis and anomaly detection across varying application loads.

Why this answer

Adaptive sampling is the correct choice because it automatically adjusts the volume of telemetry data collected based on the application's activity level, ensuring that performance trends are preserved while reducing ingestion costs. Unlike fixed-rate sampling, adaptive sampling dynamically increases or decreases the sampling rate to maintain a target volume, making it ideal for e-commerce applications with variable traffic patterns.

Exam trap

The trap here is that candidates often confuse 'adaptive sampling' with 'fixed-rate sampling' because both are head-based, but only adaptive sampling dynamically adjusts to reduce costs without losing trend visibility.

How to eliminate wrong answers

Option A is wrong because fixed-rate sampling applies a constant sampling percentage regardless of traffic volume, which can either over-sample during low activity (wasting cost) or under-sample during high activity (losing trend data). Option C is wrong because ingestion sampling occurs at the ingestion endpoint after telemetry is sent, meaning it does not reduce network bandwidth or storage costs at the source, and it cannot preserve trends as effectively as client-side sampling. Option D is wrong because head-based sampling is a general category that includes fixed-rate and adaptive sampling; it is not a specific sampling type, and the question asks for a specific configuration that reduces costs while preserving trends.

Practice this question →
4
MCQeasy

You are using Application Insights to monitor a web application. You notice that a specific request is slow. You want to see the complete end-to-end transaction details, including all dependency calls and exceptions for that single request. Which feature should you use?

A.Metrics Explorer
B.Transaction Search (End-to-End Transaction Details)
C.Application Map
D.Live Metrics Stream
AnswerB

Transaction Search, specifically the End-to-End Transaction Details view, is the primary tool in Application Insights for investigating the full lifecycle of an individual request. It presents a chronological timeline of all operations, dependencies, and logs associated with a specific transaction, allowing developers to trace the flow across different components, identify bottlenecks, and understand the exact sequence of events that led to a particular outcome or performance issue. This granular view is crucial for root cause analysis.

Why this answer

Transaction Search (End-to-End Transaction Details) is the correct feature because it allows you to view the complete trace of a single request, including all dependency calls (e.g., SQL, HTTP, Azure services), exceptions, and logs associated with that specific operation. This is achieved by correlating telemetry using the operation_Id field, which groups all telemetry items from the same request into a single end-to-end view. Other features like Metrics Explorer or Application Map provide aggregated or topological views, not per-request drill-down.

Exam trap

The trap here is that candidates often confuse the aggregated monitoring features (Metrics Explorer, Application Map) with the diagnostic drill-down capability of Transaction Search, mistakenly believing that a high-level view can reveal per-request details.

How to eliminate wrong answers

Option A is wrong because Metrics Explorer provides aggregated, time-series metrics (e.g., average response time, request count) and cannot show individual request-level details or dependency call trees. Option C is wrong because Application Map offers a topological view of application components and their dependencies, but it does not provide per-request transaction details or exception traces. Option D is wrong because Live Metrics Stream shows real-time, near-instantaneous metrics (e.g., request rate, CPU usage) for monitoring live traffic, but it does not support querying historical or specific slow requests with full dependency and exception details.

Practice this question →
5
MCQhard

Application Insights ingestion cost is rising because a high-traffic app emits large telemetry volume. The team needs statistically useful telemetry while reducing ingestion. What should be configured?

A.Move the app to a larger App Service plan
B.Adaptive sampling
C.Disable all exception telemetry
D.Increase log verbosity to debug
AnswerB

Adaptive sampling dynamically adjusts the volume of telemetry items Application Insights retains, based on actual traffic rates, while preserving statistically representative samples and correlated request traces. This satisfies the constraint of reducing ingestion cost without losing statistically useful data, unlike fixed-rate sampling which can miss spikes.

Why this answer

Adaptive sampling is the correct solution because it automatically adjusts the volume of telemetry data sent to Application Insights, retaining only a representative subset that preserves statistical accuracy for analysis. This reduces ingestion costs while ensuring the sampled data remains statistically useful for detecting trends and anomalies in high-traffic applications.

Exam trap

The trap here is that candidates may think increasing resources (larger plan) or disabling entire telemetry categories (exceptions) is a valid cost-control measure, but the exam tests understanding that adaptive sampling is the designed Azure feature for reducing telemetry volume while preserving statistical significance.

How to eliminate wrong answers

Option A is wrong because moving the app to a larger App Service plan increases compute resources and cost, but does not reduce telemetry ingestion volume or address the root cause of rising Application Insights costs. Option C is wrong because disabling all exception telemetry would eliminate critical diagnostic data needed for monitoring application health, and it does not provide a balanced approach to reducing ingestion while maintaining statistical usefulness. Option D is wrong because increasing log verbosity to debug would generate even more telemetry data, exacerbating the ingestion cost problem rather than solving it.

Practice this question →
6
Multi-Selectmedium

Which TWO actions should you take to optimize costs for an Azure SQL Database that is underutilized? (Choose two.)

Select 2 answers
A.Enable geo-replication
B.Increase the DTU or vCore limit
C.Purchase reserved capacity
D.Enable read scale-out
E.Scale down to a lower service tier
AnswersC, E

Purchasing reserved capacity for Azure SQL Database allows organizations to commit to a specific amount of database compute usage for a one-year or three-year term. By making this upfront commitment, Azure provides substantial discounts, often ranging from 30% to 70% compared to standard pay-as-you-go rates. This strategy is particularly effective for predictable, long-running workloads, significantly reducing the total cost of ownership over the reservation period and directly optimizing expenditures.

Why this answer

Option C (Purchase reserved capacity) is correct because committing to a 1- or 3-year reservation for Azure SQL Database provides a significant discount (up to ~33% for 1-year and ~55% for 3-year) compared to pay-as-you-go pricing, directly reducing cost for a database that will continue running. Option E (Scale down to a lower service tier) is correct because an underutilized database is provisioned with more DTUs/vCores than it needs, so moving to a lower service tier or compute size reduces the hourly provisioned cost while still meeting actual workload demand. Option A (Enable geo-replication) is incorrect because it adds a secondary readable database and increases cost rather than optimizing it.

Option B (Increase the DTU or vCore limit) is incorrect because it raises provisioned resources and cost, the opposite of optimization for an underutilized database. Option D (Enable read scale-out) is incorrect because, while it can offload read workloads, it does not reduce the cost of an underutilized database and may require a higher service tier.

Exam trap

The trap here is that candidates often confuse cost optimization with performance improvement, selecting options like enabling geo-replication or read scale-out, which are high-availability and scalability features that increase costs, not reduce them.

Practice this question →
7
MCQhard

You are a developer for a large e-commerce company. The company has a global customer base and runs a critical web application on Azure App Service (Premium v3 plan) deployed in multiple regions. The application uses Azure Cosmos DB (multi-region writes enabled) for product catalog and session state. Recently, the operations team reported that during peak shopping hours (e.g., Black Friday), the application becomes slow and some users experience timeouts. You have implemented Application Insights to collect telemetry. After analyzing the data, you find that the Cosmos DB write operations are experiencing high latency (average 200ms) and occasional throttling (429 errors). The read latency is acceptable. The App Service instances are scaled out to 20 instances during peak, and CPU usage is around 70%. You need to optimize the solution to reduce write latency and eliminate throttling without over-provisioning resources. The solution must be cost-effective and require minimal code changes. What should you do?

A.Scale up the App Service plan to a higher tier to increase CPU capacity
B.Implement Azure Cache for Redis to cache Cosmos DB read and write operations
C.Increase the provisioned RU/s manually before peak hours and decrease after
D.Enable autoscale on the Cosmos DB container with a maximum throughput limit
AnswerD

Enabling autoscale on the Cosmos DB container is the most effective solution for dynamically managing throughput and preventing throttling errors. Autoscale automatically adjusts the provisioned Request Units per second (RU/s) based on the actual usage patterns of the workload, scaling up during peak demand and scaling down during lulls. Setting a maximum throughput limit ensures cost control by preventing the throughput from exceeding a predefined ceiling, while still allowing the system to adapt to varying loads and maintain application responsiveness without manual intervention.

Why this answer

Enabling autoscale on the Cosmos DB container allows the throughput to automatically scale up to the maximum limit during peak traffic, eliminating throttling (429 errors) and reducing write latency without manual intervention. This approach is cost-effective as it scales down during low traffic, and requires minimal code changes since it's a configuration change at the Cosmos DB level.

Exam trap

The trap here is that candidates may confuse scaling the App Service (Option A) with scaling the database, or assume caching (Option B) can solve write latency, but writes must be persisted to Cosmos DB and caching does not help with throttling.

How to eliminate wrong answers

Option A is wrong because scaling up the App Service plan increases CPU capacity, but the issue is with Cosmos DB write latency and throttling, not App Service CPU (which is at 70%). Option B is wrong because Azure Cache for Redis can cache read operations to reduce read latency, but it cannot cache write operations (writes must go to Cosmos DB for durability), so it does not address write throttling or latency. Option C is wrong because manually increasing RU/s before peak hours and decreasing after is not cost-effective (you pay for provisioned RU/s even if unused) and requires operational overhead, whereas autoscale dynamically adjusts throughput based on demand.

Practice this question →
8
MCQhard

You need to emit a custom metric in Application Insights that tracks the number of page views per browser. You expect high volume (millions of events per day). Which API should you use to ensure efficient pre-aggregation and avoid performance issues?

A.TrackEvent
B.TrackMetric
C.GetMetric
D.TrackDependency
AnswerC

GetMetric (specifically, GetMetric().TrackValue()) is the recommended approach for high-volume custom metrics that require multiple dimensions. It provides an in-memory metric object that intelligently aggregates data points client-side over a configurable interval (typically 1 minute) before sending a single, summarized data point to Application Insights. This client-side pre-aggregation significantly reduces telemetry volume, optimizes ingestion costs, and supports rich dimensional analysis without incurring high overhead.

Why this answer

C is correct because the GetMetric API (previously known as Pre-Aggregated Metric API) is designed for high-volume telemetry scenarios. It pre-aggregates metrics on the client side before sending them to Application Insights, significantly reducing network traffic and storage costs while avoiding performance bottlenecks from millions of individual events.

Exam trap

The trap here is that candidates often confuse TrackEvent (for custom events) with metric tracking, or assume TrackMetric is the correct choice because of its name, not realizing it is deprecated and lacks client-side pre-aggregation.

How to eliminate wrong answers

Option A is wrong because TrackEvent sends each event individually, which would generate millions of separate telemetry records, causing excessive network overhead and ingestion costs. Option B is wrong because TrackMetric is deprecated and also sends individual metric values without client-side aggregation, leading to similar performance issues. Option D is wrong because TrackDependency is used to track external dependency calls (e.g., HTTP, SQL), not custom metrics like page views per browser.

Practice this question →
9
Multi-Selecteasy

You are monitoring an Azure App Service web app that is experiencing intermittent high CPU usage. You need to configure alerts and troubleshoot the issue. Which TWO actions should you take? (Choose two.)

Select 2 answers
A.Create a metric alert rule that triggers when average CPU exceeds 90% over 5 minutes.
B.Scale up the App Service plan to a higher tier to ensure sufficient resources.
C.Create a Log Analytics workspace and configure diagnostic settings to send platform logs.
D.Enable Application Insights and configure autoscale based on custom metrics.
E.Create an autoscale rule for the App Service plan to scale out when CPU > 80%.
AnswersA, C

An alert rule primarily provides notification when a specific metric threshold, such as average CPU exceeding 90%, is breached. While crucial for operational awareness and indicating a potential problem, it does not automatically remediate the high CPU usage or provide the detailed diagnostic data necessary for root cause analysis. This action only informs about the issue, rather than proactively resolving it or enabling deep troubleshooting.

Why this answer

Option A is correct because a metric alert on the CPU Percentage metric with an average aggregation over a 5-minute window and a 90% threshold is the standard way to detect sustained high CPU on an App Service plan and get notified when the condition is met. Option C is correct because sending platform logs and metrics to a Log Analytics workspace via diagnostic settings enables querying historical resource and platform data (e.g., using KQL) to troubleshoot the intermittent CPU spikes and correlate them with events. Option B is not appropriate because scaling up changes the pricing tier and resources but does not by itself alert or diagnose the intermittent issue.

Option D is incorrect because Application Insights primarily provides application-level telemetry and autoscale cannot be driven by Application Insights custom metrics for App Service plans in the way described. Option E is incorrect because autoscale rules react to load by adding instances but do not satisfy the requirement to configure alerts and troubleshoot the root cause.

Exam trap

The trap here is that candidates confuse alerting (Option A) with troubleshooting, or they assume scaling (Option B) is a valid troubleshooting action rather than a mitigation, while Option D mixes a diagnostic tool (Application Insights) with an autoscale action that does not directly help identify the cause.

Practice this question →
10
MCQhard

You have an Azure Logic App that processes orders. Occasionally, the Logic App fails due to a transient error from a downstream API. You want to automatically retry the failed action after 10 seconds, up to 3 times, with exponential backoff. Which configuration should you set on the action?

A.Set retry policy to default with interval of 10 seconds and count of 3
B.Set retry policy to fixed interval with 10-second delay and 3 retries
C.Set retry policy to none and implement custom retry logic
D.Set retry policy to custom with exponential interval and 3 retries
AnswerA

The default retry policy in Azure Logic Apps automatically implements an exponential backoff strategy, which is ideal for transient errors as it progressively increases the delay between retries. When configured with an interval of 10 seconds and a count of 3, the initial delay will be 10 seconds, and subsequent retries will have longer delays, preventing immediate re-bombardment of a potentially overloaded service. This approach significantly improves the chances of success by allowing the target system time to recover.

Why this answer

The default retry policy in Azure Logic Apps uses exponential backoff, which automatically increases the delay between retries. Setting the interval to 10 seconds and count to 3 configures the initial delay and maximum retry attempts, while the exponential backoff behavior is inherent to the default policy. This matches the requirement to retry after 10 seconds initially, up to 3 times, with exponential backoff.

Exam trap

The trap here is that candidates often assume 'default' means no configuration is needed, but the default policy actually uses exponential backoff and requires explicit interval and count settings to control the retry behavior.

How to eliminate wrong answers

Option B is wrong because a fixed interval retry policy uses a constant delay between retries (e.g., exactly 10 seconds each time), not exponential backoff, which violates the requirement for exponential backoff. Option C is wrong because setting the retry policy to 'none' disables automatic retries entirely, requiring custom logic that would be unnecessary and more complex when the built-in default policy already supports exponential backoff. Option D is wrong because there is no 'custom' retry policy type in Azure Logic Apps; the available types are 'default', 'fixed interval', and 'none', and the default policy already provides exponential backoff without needing a custom configuration.

Practice this question →
11
Multi-Selecthard

A production API needs proactive alerting for high telemetry cost. Which two elements are required for a useful Azure Monitor alert?

Select 2 answers
A.A signal or metric/log query that detects the condition
B.A public IP address on the app
C.A manually exported CSV report
D.An action group for notification or automation
AnswersA, D

To proactively alert on high telemetry, an Azure Monitor alert rule requires a specific signal, which can be a platform metric (e.g., CPU utilization, request count) or a custom log query (e.g., Kusto Query Language for Application Insights logs). This signal serves as the condition that the alert rule continuously evaluates against a defined threshold, triggering an alert when the telemetry exceeds the specified limit.

Why this answer

An Azure Monitor alert requires a signal—either a metric (e.g., number of API calls, or a custom metric for telemetry cost) or a log query (e.g., Application Insights traces analyzed for cost patterns)—that defines the condition to detect high telemetry cost. Without this signal, the alert has no data source to evaluate against a threshold or pattern, making proactive detection impossible. Additionally, a useful alert requires an action group to define what happens when the alert condition is met, such as sending notifications (email, SMS) or triggering automated actions (webhooks, runbooks).

Without an action group, the alert would trigger but provide no practical benefit.

Exam trap

The trap here is that candidates often confuse the components needed for an alert (signal and action group) with unrelated infrastructure details like IP addresses or manual exports, leading them to select options that are not part of the alert definition.

Practice this question →
12
MCQeasy

You are using Application Insights to monitor a web application. The business team wants to track how many users click a specific button on the page. You need to send custom telemetry data from the client-side JavaScript. Which Application Insights JavaScript SDK method should you call?

A.appInsights.trackTrace
B.appInsights.trackEvent
C.appInsights.trackPageView
D.appInsights.trackException
AnswerB

appInsights.trackEvent is the correct and most appropriate method for capturing custom user interactions and business events within an application, such as a button click, form submission, or item added to a cart. It allows developers to attach custom properties (e.g., button name, user ID, feature variant) and measurements (e.g., duration, value) to the event, enabling rich analytical queries, segmentation, and funnel analysis in Application Insights. This structured data is crucial for understanding user behavior and application engagement.

Why this answer

The correct method is `trackEvent` because it is specifically designed for capturing user interactions, such as button clicks, as custom events in Application Insights. Unlike other methods, `trackEvent` allows you to attach custom properties and measurements, making it ideal for business metrics like click tracking. This method sends the data as a custom event telemetry item, which can be analyzed in the Azure portal under 'Events'.

Exam trap

The trap here is that candidates often confuse `trackEvent` with `trackTrace` or `trackPageView`, thinking that any custom data can be sent via `trackTrace`, but `trackEvent` is the only method designed for user-defined business events like button clicks.

How to eliminate wrong answers

Option A is wrong because `trackTrace` is used for logging diagnostic trace messages, not for tracking user interactions or custom business events. Option C is wrong because `trackPageView` is designed to track page loads and views, not individual button clicks on a page. Option D is wrong because `trackException` is used to report exceptions and errors, not to track user actions or custom telemetry events.

Practice this question →
13
Multi-Selectmedium

Which TWO Azure Monitor features can help troubleshoot a web app that returns slow response times intermittently?

Select 2 answers
A.Sentinel incidents
B.Advisor recommendations
C.Live Metrics
D.Application Map
E.Policy compliance
AnswersC, D

Azure Monitor's Live Metrics Stream provides a near real-time, minute-by-minute view of a running web application's performance, including incoming requests, failures, dependency calls, and CPU utilization. This feature allows developers to observe the impact of deployments or diagnose issues immediately as they occur, offering a crucial, unfiltered stream of operational data directly from the application instance. It is invaluable for quickly identifying spikes in errors or latency during active troubleshooting sessions.

Why this answer

Live Metrics (C) is correct because it provides real-time, low-latency monitoring of a web app's performance, including CPU, memory, and request rates, allowing you to observe intermittent slow responses as they happen without sampling delays. Application Map (D) is correct because it visualizes the distributed components of your application and their dependencies, helping you identify which downstream service or component is causing latency spikes during intermittent slowdowns.

Exam trap

The trap here is that candidates often confuse Azure Monitor metrics (like Live Metrics) with log-based solutions (like Log Analytics queries) or governance tools (like Policy), failing to recognize that real-time streaming and dependency mapping are the only features that can capture and isolate intermittent performance issues without aggregation delays.

Practice this question →
14
MCQhard

You are optimizing an Azure API Management instance that handles 10,000 requests per second. You notice that caching is not effective. The cache hit ratio is below 10%. You need to increase the cache hit ratio. What should you do?

A.Use external Azure Cache for Redis
B.Configure cache key to include only relevant query parameters
C.Disable caching for low-traffic APIs
D.Increase the cache size to 5 GB
AnswerB

Optimizing the cache key to include only essential query parameters significantly improves the cache hit ratio by ensuring that logically identical requests map to the same cached response. By explicitly excluding irrelevant parameters (e.g., tracking IDs, timestamps, or optional filters that do not alter the core response content), multiple requests for the same resource will share a single cache entry. This consolidation ensures that the API Management instance can serve more requests directly from the cache, thereby reducing backend load, improving API response times, and maximizing caching efficiency.

Why this answer

The low cache hit ratio indicates that cache keys are too specific, causing each request to miss the cache. By configuring the cache key to include only relevant query parameters, you group similar requests under the same cache key, increasing the likelihood of cache hits. This directly addresses the root cause of poor cache utilization in Azure API Management.

Exam trap

The trap here is that candidates often assume a low cache hit ratio is due to insufficient cache size or backend performance, when the real issue is overly granular cache keys that prevent reuse.

How to eliminate wrong answers

Option A is wrong because switching to external Azure Cache for Redis does not solve the problem of ineffective cache keys; it only changes the cache backend, which may improve performance but not the hit ratio if keys remain overly specific. Option C is wrong because disabling caching for low-traffic APIs would reduce cache usage further, potentially worsening the overall hit ratio and not addressing the key design issue. Option D is wrong because increasing cache size to 5 GB does not fix the fundamental issue of cache key granularity; a larger cache may store more entries but still suffer from low hit rates if keys are too unique.

Practice this question →
15
MCQmedium

You are troubleshooting an Azure Function that intermittently throws exceptions. You have enabled Application Insights. You need to capture the exact line of code that caused the exception, even for exceptions that occur during high load. Which feature should you use?

A.Snapshot Debugger
B.Application Insights Profiler
C.Live Metrics Stream
D.SQL Insights
AnswerA

The Snapshot Debugger is specifically designed to diagnose intermittent issues in live Azure applications by automatically collecting debug snapshots when an exception occurs. It captures the full call stack and local variables at the exact moment of the exception, without impacting the running application's performance. This allows developers to inspect the state of the application at the point of failure, even for non-reproducible errors, making it ideal for troubleshooting intermittent exceptions in an Azure Function.

Why this answer

Snapshot Debugger is the correct choice because it captures a point-in-time snapshot of the call stack and local variables at the exact line where an exception occurs, even under high load. This allows you to see the precise line of code and state that caused the failure, which is essential for diagnosing intermittent exceptions. Application Insights integrates Snapshot Debugger to automatically collect these snapshots for thrown exceptions without requiring manual instrumentation.

Exam trap

The trap here is that candidates confuse Profiler (performance tracing) with Snapshot Debugger (exception debugging), assuming both capture code-level details, but only Snapshot Debugger provides the exact line of code and variable state at the moment of failure.

How to eliminate wrong answers

Option B is wrong because Application Insights Profiler traces performance bottlenecks by sampling CPU and request durations, not capturing exception call stacks or line-level details. Option C is wrong because Live Metrics Stream provides real-time monitoring of metrics like request rate and failure count, but it does not capture snapshots or line-of-code details for individual exceptions. Option D is wrong because SQL Insights focuses on diagnosing database query performance and deadlocks, not application-level exception line numbers.

Practice this question →
16
MCQmedium

You are a developer for a company that runs a critical e-commerce application on Azure. The application consists of an Azure App Service web app, an Azure SQL Database, and an Azure Cache for Redis. The web app experiences occasional performance degradation that you suspect is due to inefficient database queries caused by caching issues. You have enabled Application Insights on the web app. You need to identify the root cause of the performance issues and optimize the solution. The solution must minimize cost and administrative overhead. You have the following options: Option A: Configure Azure SQL Database Intelligent Insights to automatically tune database queries. Option B: Use Application Insights Profiler to capture and analyze database query performance. Option C: Implement Redis cache-aside pattern and ensure that all database queries check the cache first. Option D: Enable Azure SQL Database Query Performance Insight to identify the most costly queries and then implement caching. Which option should you recommend?

A.Implement Redis cache-aside pattern and ensure that all database queries check the cache first.
B.Configure Azure SQL Database Intelligent Insights to automatically tune database queries.
C.Enable Azure SQL Database Query Performance Insight to identify the most costly queries and then implement caching.
D.Use Application Insights Profiler to capture and analyze database query performance.
AnswerC

Azure SQL Database Query Performance Insight is specifically designed to identify the top resource-consuming queries based on metrics like CPU, I/O, and duration. This tool allows developers to precisely pinpoint the exact queries causing performance bottlenecks. Once these 'most costly queries' are identified, implementing a targeted optimization, such as the Redis cache-aside pattern for those specific queries, becomes a highly effective and efficient strategy to reduce database load and improve overall application responsiveness.

Why this answer

The scenario requires identifying the root cause of performance degradation due to inefficient database queries caused by caching issues. Query Performance Insight in Azure SQL Database pinpoints the most resource-intensive and longest-running queries, allowing you to target exactly which queries need caching. After identifying these costly queries, implementing a Redis cache-aside pattern reduces redundant database hits, directly addressing the suspected caching issue while minimizing cost and administrative overhead.

Exam trap

The trap here is that candidates may confuse diagnostic tools (like Profiler or Intelligent Insights) with the specific query identification and caching optimization needed, overlooking that Query Performance Insight directly reveals which queries are most costly and thus candidates for caching.

How to eliminate wrong answers

Option A is wrong because Intelligent Insights provides automated tuning and proactive diagnostics for database performance, but it does not directly help identify which queries are causing the caching-related inefficiency; it focuses on index recommendations and query plan regressions, not on caching gaps. Option B is wrong because Application Insights Profiler captures and analyzes end-to-end request traces, including database calls, but it is a diagnostic tool for performance profiling, not a solution for optimizing caching; it adds overhead and cost without directly resolving the caching issue. Option D is wrong because while Application Insights Profiler can help diagnose performance, it does not provide the targeted query-level cost analysis needed to decide which queries to cache; it is better suited for general performance troubleshooting rather than identifying specific costly queries for caching optimization.

Practice this question →
17
MCQhard

Your Azure Functions app uses Durable Functions to orchestrate a workflow. The orchestration sometimes fails with a 'FunctionRuntimeException' due to a timeout. You need to increase the maximum orchestration time. What should you modify?

A.Add an app setting 'AzureFunctionsJobHost__functionTimeout'
B.Change the Azure Storage account to a Premium account
C.Increase the 'functionTimeout' in host.json
D.Set 'maxOrchestrationTimeout' in the host.json file
AnswerD

Setting 'maxOrchestrationTimeout' in the host.json file is the correct approach because this specific configuration property, located within the 'durableTask' section, directly controls the maximum allowable wall-clock duration for a Durable Function orchestration instance. If an orchestration exceeds this configured timeout, the Durable Task Framework will automatically terminate it, preventing indefinitely running instances and ensuring proper resource management and application stability.

Why this answer

D is correct because in Durable Functions, the maximum orchestration time is controlled by the 'maxOrchestrationTimeout' setting in the host.json file. This setting specifies the maximum duration an orchestration instance can run before it times out, and increasing it directly addresses the 'FunctionRuntimeException' due to timeout. The default value is 7 days, but you can extend it as needed.

Exam trap

The trap here is that candidates often confuse 'functionTimeout' (for individual function execution) with 'maxOrchestrationTimeout' (for Durable Functions orchestration duration), leading them to incorrectly modify the wrong setting in host.json.

How to eliminate wrong answers

Option A is wrong because 'AzureFunctionsJobHost__functionTimeout' is not a valid app setting; the correct app setting for function timeout is 'AzureFunctionsJobHost:functionTimeout' or 'FUNCTIONS_EXTENSIONVERSION' related settings, but this does not apply to Durable Functions orchestration timeout. Option B is wrong because changing the Azure Storage account to a Premium account improves performance and throughput but does not affect the maximum orchestration timeout; it addresses storage latency, not timeout duration. Option C is wrong because 'functionTimeout' in host.json controls the timeout for individual function executions (e.g., HTTP triggers), not the orchestration timeout in Durable Functions; orchestration timeout is managed separately via 'maxOrchestrationTimeout'.

Practice this question →
18
MCQhard

Three microservices collaborate on a single user transaction: an App Service API, an Azure Function that processes a Service Bus message, and a downstream storage service. Traces appear separately in Application Insights with no parent-child relationship. What is needed to correlate all three into a single end-to-end trace?

A.Install the Application Insights SDK on all three services and ensure W3C Trace Context header propagation is enabled for both HTTP calls and Service Bus messages
B.Use the same Application Insights instrumentation key for all three services — no additional configuration is needed
C.Add a custom x-correlation-id header in each service and log it with TelemetryClient.TrackEvent
D.Enable Azure Monitor cross-resource queries and write a KQL join across all three services' logs
AnswerA

The SDK propagates the traceparent header on outgoing HTTP requests automatically. For Service Bus, the SDK injects and reads correlation properties in the message's ApplicationProperties collection. With the same operation ID flowing through all three services, Application Insights assembles the calls into a single end-to-end trace in the Application Map and end-to-end transaction view.

Why this answer

Distributed tracing across HTTP and asynchronous messaging requires the Application Insights SDK on each service and propagation of the W3C Trace-Context standard (traceparent and tracestate headers). This ensures that the App Service API, Azure Function, and downstream storage service share a single trace ID, enabling Application Insights to correlate all telemetry into one end-to-end transaction view.

Exam trap

The trap here is that candidates assume sharing an instrumentation key is sufficient for correlation, overlooking the necessity of W3C Trace-Context header propagation across both synchronous HTTP and asynchronous messaging protocols.

How to eliminate wrong answers

Option B is wrong because sharing the same instrumentation key only sends telemetry to the same Application Insights resource but does not automatically correlate spans without trace context propagation; each service's traces remain disconnected. Option C is wrong because a custom x-correlation-id header and manual TrackEvent calls do not create parent-child span relationships; the SDK's built-in distributed tracing relies on standardized W3C headers and automatic telemetry correlation. Option D is wrong because cross-resource queries and KQL joins can combine logs after the fact but do not establish the real-time parent-child trace hierarchy needed for a single end-to-end view; they also require manual correlation logic.

Practice this question →
19
MCQmedium

Your team monitors Azure Functions with Application Insights. After a recent deployment, cold start latency increased. Which feature should you enable to mitigate this?

A.Set FUNCTIONS_WORKER_RUNTIME to 'dotnet-isolated'
B.Migrate from Consumption plan to Premium plan
C.Enable Azure Monitor alerts on function execution count
D.Enable Always On in the function app configuration
AnswerB

Migrating an Azure Function app from a Consumption plan to a Premium plan directly addresses cold start issues by provisioning pre-warmed instances. The Premium plan maintains a specified minimum number of active instances, ensuring that function apps are always ready to process requests without the initial latency associated with instance allocation, startup, and code loading. This significantly reduces the delay experienced during the first invocation after a period of inactivity.

Why this answer

Cold start latency occurs when a function app is idle and needs to be loaded from scratch. The Consumption plan can cause cold starts because it scales to zero when idle. Migrating to the Premium plan eliminates cold starts by keeping instances warm, as it provides pre-warmed workers and always-on instances, reducing latency after deployment.

Exam trap

The trap here is that candidates often confuse 'Always On' (an App Service setting for continuous web jobs) with Azure Functions cold start mitigation, but 'Always On' is not supported on Consumption or Premium plans, and the correct solution is to use the Premium plan's built-in warm instance support.

How to eliminate wrong answers

Option A is wrong because setting FUNCTIONS_WORKER_RUNTIME to 'dotnet-isolated' changes the process model but does not address cold start latency; it may even increase startup time due to the additional out-of-process overhead. Option C is wrong because enabling Azure Monitor alerts on function execution count only notifies you of execution patterns, it does not mitigate cold start latency. Option D is wrong because 'Always On' is a setting for App Service plans (e.g., Basic, Standard, Premium) and is not available or applicable to Azure Functions running on Consumption or Premium plans; it is a common misconception that it applies to Functions.

Practice this question →
20
MCQhard

You need to analyze all exceptions that occurred in the last 24 hours from an application monitored by Application Insights. You want to group them by exception type, and for each type show the URL where it occurred and the count. Which Log Analytics Kusto query should you use?

A.exceptions | where timestamp > ago(24h) | summarize count() by type, cloud_RoleInstance
B.exceptions | where timestamp > ago(24h) | summarize count() by type, url
C.exceptions | where timestamp > ago(24h) | summarize count() by type, operation_Name
D.exceptions | where timestamp > ago(24h) | summarize count() by type
AnswerB

This query accurately filters all exceptions that occurred within the last 24 hours using the `ago(24h)` function. By grouping the results using `summarize count() by type, url`, it provides a precise breakdown of how many times each exception `type` occurred at each specific `url`. This directly addresses the requirement to analyze exceptions 'from' their originating application endpoint, offering clear insight into problematic URLs.

Why this answer

The query filters exceptions from the last 24 hours using `timestamp > ago(24h)`, groups them by `type` (exception type) and `url` (the URL where the exception occurred), and then counts occurrences per group with `summarize count()`. This directly matches the requirement to show, for each exception type, the URL and the count.

Exam trap

The trap here is that candidates may confuse `url` with `operation_Name` or `cloud_RoleInstance`, thinking those columns also represent the URL, but only `url` directly captures the request URL where the exception occurred.

How to eliminate wrong answers

Option A is wrong because it groups by `cloud_RoleInstance`, which identifies the server or instance, not the URL where the exception occurred; this would show counts per server per exception type, not per URL. Option C is wrong because it groups by `operation_Name`, which is the name of the operation (e.g., a controller action), not the URL; this would show counts per operation per exception type, not per URL. Option D is wrong because it only groups by `type`, omitting the URL entirely; this would show total counts per exception type but not break them down by URL as required.

Practice this question →
21
MCQeasy

You need to monitor the performance of an Azure App Service web app. Which metric indicates high CPU usage?

A.Data In/Out
B.Requests per second
C.CPU Time
D.Memory working set
AnswerC

The 'CPU Time' metric is a direct and highly accurate measure for monitoring the performance of an Azure App Service, as it quantifies the cumulative amount of time the application's processes spend actively utilizing the CPU cores. This metric directly reflects the computational resources consumed by the application, providing a clear indication of its processing load and efficiency. High CPU Time often signals inefficient code, complex operations, or insufficient compute capacity for the workload.

Why this answer

CPU Time is the correct metric for monitoring high CPU usage in an Azure App Service web app because it directly measures the total amount of CPU processing time consumed by the application. When CPU usage is high, the CPU Time metric will show elevated values, reflecting the actual seconds of processor time used, which is the most direct indicator of CPU load.

Exam trap

The trap here is that candidates may confuse 'Requests per second' (a throughput metric) with CPU usage, assuming more requests always mean more CPU, but Azure App Service can handle many requests with low CPU if the workload is I/O-bound or efficiently parallelized.

How to eliminate wrong answers

Option A is wrong because Data In/Out measures network throughput (bytes sent and received), not CPU utilization, so it cannot indicate high CPU usage. Option B is wrong because Requests per second measures the rate of incoming HTTP requests, which can correlate with CPU load but does not directly measure CPU consumption; a high request rate can be handled efficiently without high CPU usage. Option D is wrong because Memory working set measures the amount of physical memory (RAM) used by the app, not CPU usage; high memory usage does not imply high CPU usage.

Practice this question →
22
MCQeasy

You are monitoring an Azure App Service using Application Insights. You want to alert when the average server response time exceeds 2 seconds over a 5-minute window. What should you create?

A.An availability alert
B.A log alert with a custom KQL query
C.A metric alert with 'Server response time' as the signal
D.An activity log alert
AnswerC

Metric alerts in Azure Monitor are specifically designed to monitor numeric values collected over time, such as performance counters or telemetry from Application Insights. 'Server response time' is a standard, pre-aggregated metric automatically collected by Application Insights, representing the time taken for the server to process a request. Configuring a metric alert with this signal allows for direct, efficient, and real-time thresholding to detect performance degradation or spikes in latency, making it the ideal choice for this scenario.

Why this answer

A metric alert is the correct choice because 'Server response time' is a pre-aggregated performance metric emitted by Azure App Service to Application Insights. Metric alerts evaluate this signal against a static threshold (e.g., >2 seconds) over a specified time window (e.g., 5 minutes) without needing custom queries, making them ideal for simple threshold-based monitoring of latency.

Exam trap

The trap here is that candidates confuse metric alerts (which use pre-aggregated metrics) with log alerts (which require custom KQL queries), assuming that any alert involving Application Insights must use logs, when in fact the 'Server response time' is a standard metric signal available directly in the metric alert creation flow.

How to eliminate wrong answers

Option A is wrong because availability alerts monitor endpoint availability (HTTP response codes) and latency from synthetic ping tests, not the average server response time of actual user requests. Option B is wrong because log alerts with custom KQL queries are used for complex, multi-dimensional analysis of raw log data (e.g., traces, exceptions) and are unnecessary for a simple threshold on a pre-aggregated metric like server response time. Option D is wrong because activity log alerts fire on Azure resource management events (e.g., create, delete, scale) and do not monitor application-level performance metrics like response time.

Practice this question →
23
MCQhard

Your application uses Azure Cosmos DB with the SQL API. You notice that read requests are being throttled (HTTP 429) during peak hours. You need to improve read performance without changing the application code. Which action should you take?

A.Add a composite index to the container
B.Increase the provisioned throughput (RU/s) for the container
C.Enable multi-region writes for the Cosmos DB account
D.Change the default consistency level to Strong
AnswerB

Increasing the provisioned throughput, measured in Request Units per second (RU/s), directly expands the total capacity available for all database operations, including reads and writes. Each operation consumes a certain number of RUs, and exceeding the provisioned RU/s results in throttling. By increasing RU/s, the application gains more headroom to execute a higher volume of operations concurrently without encountering rate limiting.

Why this answer

Throttling (HTTP 429) occurs when the consumed request units per second exceed the provisioned throughput. Increasing the provisioned RU/s for the container directly raises the capacity, allowing more read requests per second without any code changes. This is the simplest and most direct way to eliminate throttling under peak load.

Exam trap

The trap here is that candidates confuse performance optimization (indexing, consistency) with capacity management; throttling is always a throughput capacity problem, not a query or consistency problem.

How to eliminate wrong answers

Option A is wrong because composite indexes improve query performance for multi-field ORDER BY or filter operations, but they do not increase the overall throughput capacity; throttling is a capacity issue, not a query optimization issue. Option C is wrong because enabling multi-region writes improves write availability and latency but does not increase the read throughput limit for a single region; reads are still subject to the provisioned RU/s on each region. Option D is wrong because Strong consistency increases the RU cost per read (requiring quorum reads), which would worsen throttling, not improve it; weaker consistency levels reduce RU consumption for reads.

Practice this question →
24
MCQeasy

You are using Azure Monitor to collect logs from multiple Azure resources. You need to query logs to find all error events from the last 24 hours. Which query language should you use?

A.Transact-SQL (T-SQL)
B.PromQL
C.PowerShell
D.Kusto Query Language (KQL)
AnswerD

Kusto Query Language (KQL) is the powerful, read-only query language used to query and analyze data in Azure Data Explorer, Azure Monitor Logs (Log Analytics), and Azure Sentinel. It is specifically designed for querying large volumes of structured, semi-structured, and unstructured data, making it ideal for log and telemetry analysis. KQL provides rich capabilities for filtering, aggregating, joining, and visualizing data from various sources within Azure Monitor, making it the native and most efficient way to interact with log data.

Why this answer

Azure Monitor uses Kusto Query Language (KQL) as its native query language for log analytics. KQL is specifically designed for querying large volumes of structured and semi-structured data in Azure Data Explorer and Log Analytics workspaces, making it the correct choice for retrieving error events from the last 24 hours.

Exam trap

The trap here is that candidates may confuse Azure Monitor's query language with SQL-like syntax (T-SQL) due to familiarity, but KQL is the only language natively supported for log queries in Azure Monitor.

How to eliminate wrong answers

Option A is wrong because Transact-SQL (T-SQL) is used for querying relational databases like SQL Server or Azure SQL Database, not for Azure Monitor logs which require KQL. Option B is wrong because PromQL is the query language for Prometheus, a monitoring system for containerized environments, and is not supported in Azure Monitor Log Analytics. Option C is wrong because PowerShell is a scripting language for automation and configuration management, not a query language for log analytics; it can invoke KQL queries via cmdlets but cannot directly query logs.

Practice this question →
25
MCQeasy

You are monitoring an Azure Function app that processes messages from an Event Hub. You want to be alerted if the function is failing to process messages (e.g., exceptions) and automatically restart the function host. Which Azure service should you use?

A.Azure Monitor alerts with a metric alert on exception count.
B.Application Insights availability tests.
C.Azure Service Health alerts.
D.Azure Advisor recommendations.
AnswerA

Azure Monitor allows configuring metric alerts based on telemetry collected from Azure Function Apps, often integrated with Application Insights. A metric alert on "Exceptions" can detect an abnormal increase in processing failures, indicating a problem with the function's execution logic or external dependencies. When triggered, this alert can activate an action group to perform automated remediation, such as restarting the function app host to clear transient issues and restore normal operation.

Why this answer

Azure Monitor metric alerts on exception count can trigger when the function app throws exceptions during message processing. By configuring an alert rule that fires on the 'Exceptions' metric, you can then set up an action group that includes an auto-remediation step, such as restarting the function app host via a webhook or Azure Automation runbook. This directly addresses the requirement to be alerted and automatically restart the host.

Exam trap

The trap here is that candidates often confuse Application Insights availability tests (which only check HTTP endpoint availability) with the need to monitor internal function exceptions, or they mistakenly think Azure Service Health alerts cover application-level errors instead of Azure platform issues.

How to eliminate wrong answers

Option B is wrong because Application Insights availability tests are designed to monitor the availability and responsiveness of HTTP endpoints, not to detect processing failures or exceptions within an Azure Function. Option C is wrong because Azure Service Health alerts notify you about service-level issues, outages, or planned maintenance affecting Azure services, not application-level exceptions in your function code. Option D is wrong because Azure Advisor provides proactive recommendations for best practices (e.g., performance, cost, reliability) but does not offer real-time alerting or automated restart capabilities based on exception metrics.

Practice this question →
26
MCQhard

Refer to the exhibit. You deployed an Azure Storage account with this ARM template. Users outside the allowed IP range receive '403 Forbidden' errors. What is the MOST likely cause?

A.The access tier is Cool
B.The minimum TLS version is set to TLS1_2
C.The IP rule allows only 203.0.113.0/24
D.The network ACL default action is Deny
AnswerD

When the network ACL default action for an Azure Storage account is set to 'Deny', it explicitly blocks all network traffic to the storage account by default. This means that only requests originating from IP addresses or Virtual Network subnets that are explicitly added to the allowed list will be permitted. Any client attempting to access the storage account from an unlisted network source will receive a 403 Forbidden error, as their request is understood but explicitly unauthorized by the network security configuration.

Why this answer

The default action for network ACLs in Azure Storage is 'Deny' when no explicit rules match. Since the ARM template only allows traffic from the IP range 203.0.113.0/24, all other IP addresses are implicitly denied, resulting in 403 Forbidden errors for users outside that range.

Exam trap

The trap here is that candidates often focus on the IP rule (option C) as the direct cause, but the real issue is the default action being set to 'Deny', which makes the rule an exclusive allow list rather than a permissive one.

How to eliminate wrong answers

Option A is wrong because the access tier (Cool vs. Hot) affects storage costs and retrieval latency, not network access control; it cannot cause 403 errors. Option B is wrong because the minimum TLS version (TLS1_2) enforces encryption protocol requirements for client connections, but it does not block IP addresses; a client using TLS 1.2 would still be allowed if its IP is permitted.

Option C is wrong because the IP rule allowing only 203.0.113.0/24 is the explicit allow rule, but it is not the cause of the 403 error—the error occurs because the default action (Deny) blocks all other IPs, not because the rule itself is restrictive.

Practice this question →
27
MCQmedium

You are using Application Insights to monitor an ASP.NET Core web API. Users report that a specific endpoint is slow, but you cannot reproduce the issue in development. You need to identify which line of code is causing the delay in production. Which Application Insights feature should you use?

A.Use the Application Insights Map to visualize dependencies.
B.Enable Application Insights Profiler.
C.Use the Snapshot Debugger to capture debug snapshots on exceptions.
D.Create a custom telemetry event in the slow endpoint to log timing data.
AnswerB

Application Insights Profiler is the correct tool because it automatically collects detailed execution traces for requests, capturing the call stack and timing for each method invocation. This allows developers to precisely identify the 'hot path' within their code, revealing exactly where CPU time is being spent and pinpointing the specific lines of code responsible for performance bottlenecks without manual instrumentation. It provides deep, method-level insights into application performance.

Why this answer

Application Insights Profiler is designed specifically to trace code-level performance issues in production without requiring code changes or reproducing the problem. It captures detailed call stacks and timing for each request, allowing you to identify exactly which line of code is causing the delay. This makes it the correct choice for diagnosing a slow endpoint that cannot be reproduced in development.

Exam trap

The trap here is that candidates often confuse the Snapshot Debugger (for exceptions) with the Profiler (for performance), or assume custom telemetry is the only way to get timing data, missing that the Profiler provides automatic, line-level diagnostics without code changes.

How to eliminate wrong answers

Option A is wrong because the Application Insights Map visualizes dependencies between services (e.g., databases, external APIs) but does not provide line-by-line code execution timing. Option C is wrong because the Snapshot Debugger captures debug snapshots only when exceptions are thrown, not for slow performance without exceptions. Option D is wrong because creating a custom telemetry event requires modifying the application code and redeploying, which is not a built-in feature for diagnosing existing production slowness without prior instrumentation.

Practice this question →
28
MCQeasy

You are deploying a microservices application on Azure Kubernetes Service (AKS). You need to monitor the resource consumption of each pod and set up alerts when CPU usage exceeds 80% for 5 minutes. What should you use?

A.Azure Monitor VM Insights
B.Application Insights
C.Azure Service Health
D.Azure Monitor Container Insights
AnswerD

Azure Monitor Container Insights is the dedicated monitoring solution for Azure Kubernetes Service (AKS) clusters, providing comprehensive performance visibility by collecting metrics from controllers, nodes, and containers. It automatically collects CPU, memory, disk, and network usage data, along with inventory data, from Kubernetes components and workloads. This enables detailed analysis of pod health, resource utilization, and the ability to configure metric alerts directly on container-level performance thresholds, making it ideal for microservices deployed on AKS.

Why this answer

Azure Monitor Container Insights is the correct choice because it is specifically designed to monitor the performance of container workloads running on Azure Kubernetes Service (AKS). It collects memory and processor metrics from controllers, nodes, and containers, and supports setting metric alerts based on CPU usage thresholds, such as 80% for 5 minutes.

Exam trap

The trap here is that candidates often confuse Application Insights (which monitors application code) with Container Insights (which monitors container infrastructure), leading them to select Application Insights for resource consumption alerts.

How to eliminate wrong answers

Option A is wrong because Azure Monitor VM Insights is designed for monitoring virtual machines, not containerized pods in AKS; it cannot collect per-pod CPU metrics. Option B is wrong because Application Insights is an application performance management (APM) service focused on tracing, logging, and application-level telemetry, not infrastructure-level pod resource consumption. Option C is wrong because Azure Service Health provides information about Azure service outages and planned maintenance, not real-time resource monitoring of your deployed pods.

Practice this question →
29
MCQeasy

You are monitoring an Azure web application with Application Insights. You want to create a custom dashboard that shows the number of requests over time and the average server response time. Which Application Insights feature should you use to create this dashboard?

A.Metrics Explorer
B.Log Analytics
C.Application Map
D.Smart Detection
AnswerA

Azure Monitor's Metrics Explorer is the dedicated tool for visualizing time-series metric data collected by Application Insights. It allows users to create customizable charts by selecting specific metrics, applying aggregations like average or sum, and splitting data by dimensions. These interactive charts can then be pinned directly to Azure dashboards, providing a consolidated view of application performance trends.

Why this answer

Metrics Explorer in Application Insights is designed for visualizing pre-aggregated metrics like request count and server response time over time. It allows you to create custom charts and pin them to an Azure dashboard, making it the correct choice for this monitoring requirement.

Exam trap

The trap here is that candidates often confuse Log Analytics (which can also create charts from log queries) with Metrics Explorer, but Metrics Explorer is the correct tool for pre-aggregated, real-time metric visualization without writing KQL queries.

How to eliminate wrong answers

Option B is wrong because Log Analytics is used for querying raw log data with Kusto Query Language (KQL), not for directly creating real-time metric dashboards from pre-aggregated metrics. Option C is wrong because Application Map provides a visual topology of service dependencies and transaction flow, not time-series charts of request counts or response times. Option D is wrong because Smart Detection uses machine learning to automatically detect anomalies and performance issues, but it does not allow you to build custom metric dashboards.

Practice this question →
30
MCQeasy

You have an Azure Cosmos DB container with a high number of physical partitions. You observe that some partitions are hitting the request unit (RU) limit while others are underutilized. What should you do to better distribute the workload?

A.Add more composite indexes
B.Increase the total provisioned throughput
C.Choose a different partition key that evenly distributes workload
D.Change the default consistency level to eventual
AnswerC

Selecting a different partition key that ensures an even distribution of data and request volume across logical partitions is the most effective solution for addressing uneven workload. A good partition key choice, such as one with high cardinality and even access patterns, prevents "hot partitions" where a disproportionate amount of requests or data are directed to a single logical partition. This allows Cosmos DB to scale throughput horizontally and efficiently, ensuring that the provisioned RUs are utilized effectively across all physical partitions.

Why this answer

The root cause of uneven RU consumption is a poorly chosen partition key that creates a hot partition. By selecting a partition key with high cardinality and even distribution, you ensure that requests and storage are spread uniformly across all physical partitions, preventing any single partition from throttling while others remain idle.

Exam trap

The trap here is that candidates often confuse throughput scaling (increasing RU/s) with workload distribution, mistakenly believing that adding more RU/s will fix a hot partition, when in fact the partition's individual RU ceiling remains unchanged.

How to eliminate wrong answers

Option A is wrong because composite indexes improve query performance and reduce RU cost per query, but they do not redistribute workload across partitions. Option B is wrong because increasing total provisioned throughput raises the RU limit for all partitions equally, which does not solve the imbalance—the hot partition will still hit its individual RU ceiling while others remain underutilized. Option D is wrong because changing the default consistency level to eventual reduces RU consumption for read operations but does not affect how data or requests are distributed across partitions.

Practice this question →
31
MCQeasy

Your web app hosted on Azure App Service is experiencing high memory usage. You need to capture a memory dump for analysis without restarting the app. Which diagnostic feature should you use?

A.Application Insights Profiler
B.Snapshot Debugger
C.Diagnostic settings
D.Azure App Service Diagnostics (Diagnose and solve problems)
AnswerD

The "Diagnose and solve problems" blade within Azure App Service Diagnostics provides a powerful suite of tools for troubleshooting various application issues, including memory-related problems. It offers proactive diagnostics, intelligent recommendations, and specific tools like "Collect Memory Dump" which allows you to capture a full memory dump of your application process. This capability is specifically designed for deep analysis of memory leaks, high memory consumption, and other memory-related performance issues without requiring an application restart.

Why this answer

Azure App Service Diagnostics (Diagnose and solve problems) provides a built-in 'Memory Dump' tool that allows you to capture a full or mini memory dump of your app's process without requiring a restart. This is accessed through the Azure portal under the 'Diagnose and solve problems' blade, specifically via the 'Collect Memory Dump' diagnostic tool, which uses the Windows Debugging Tools to snapshot the w3wp.exe process while the app continues running.

Exam trap

The trap here is that candidates often confuse the 'Diagnose and solve problems' blade with 'Diagnostic settings' or assume that only Application Insights tools (Profiler or Snapshot Debugger) can capture runtime diagnostic data, but the memory dump feature is a distinct, restart-free tool available directly under the App Service's diagnostic portal.

How to eliminate wrong answers

Option A is wrong because Application Insights Profiler is designed to trace and analyze performance bottlenecks by capturing CPU and request execution timelines, not to capture memory dumps for analyzing memory leaks or high memory usage. Option B is wrong because Snapshot Debugger captures snapshots of application state when exceptions occur, focusing on debugging code logic errors, not on collecting full memory dumps for memory analysis. Option C is wrong because Diagnostic settings are used to stream platform logs and metrics to destinations like Storage Accounts, Event Hubs, or Log Analytics, but they do not provide a mechanism to capture on-demand memory dumps of the running process.

Practice this question →
32
MCQmedium

You are running an Azure App Service web app on the Basic tier. Users report slow initial responses due to cold starts. You need to keep the app warm without upgrading the hosting plan. Which feature should you enable?

A.Enable 'Always On' in the App Service configuration.
B.Upgrade to a Premium plan to get pre-warmed instances.
C.Implement an auto-scaling rule to maintain a minimum instance count.
D.Reduce the web app's idle timeout via application code.
AnswerA

Enabling 'Always On' in the App Service configuration ensures that the web application's worker process is continuously loaded and running, even during periods of inactivity. This prevents the application from being unloaded from memory, thereby eliminating "cold starts" where the first request after an idle period incurs significant latency for the application to initialize. This crucial setting is available starting from the Basic App Service plan tier, directly addressing the problem of initial request delays.

Why this answer

The 'Always On' feature prevents the App Service from being unloaded after periods of inactivity, eliminating cold starts by keeping the application loaded in memory. This is available on the Basic tier and above, so it solves the problem without requiring a plan upgrade.

Exam trap

The trap here is that candidates often confuse auto-scaling (which handles load distribution) with keeping a single instance warm, or incorrectly assume that 'Always On' requires a Premium plan when it is actually available from the Basic tier upward.

How to eliminate wrong answers

Option B is wrong because upgrading to a Premium plan is unnecessary and violates the constraint of not upgrading the hosting plan; 'Always On' is already available on the Basic tier. Option C is wrong because auto-scaling rules maintain a minimum instance count but do not prevent individual instances from being unloaded due to idle timeouts; cold starts still occur on each instance after idle. Option D is wrong because reducing idle timeout via application code does not affect the App Service platform's idle unloading behavior, which is controlled by the 'Always On' setting.

Practice this question →
33
Matchingmedium

Match each Azure monitoring tool to its purpose.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

Collect, analyze, and act on telemetry data

Application performance monitoring (APM)

Query and analyze log data

Personalized recommendations for best practices

Why these pairings

Azure Monitor is the main service for telemetry collection and analysis. Application Insights focuses on application performance. Log Analytics is the query workspace for logs.

Azure Advisor provides optimization recommendations. The distractors swap these definitions.

Practice this question →
34
MCQeasy

You need to monitor the real-time CPU utilization of an Azure virtual machine. Which Azure Monitor feature is designed for this purpose?

A.Metrics
B.Logs
C.Alerts
D.Workbooks
AnswerA

Metrics capture numeric time-series data at near-real-time granularity, making them the Azure Monitor feature for tracking CPU percentage continuously. Logs and alerts operate on different axes: logs need ingestion and query latency, while alerts react to thresholds rather than stream the utilisation values themselves.

Why this answer

Azure Monitor Metrics is the correct feature because it collects and stores numeric time-series data from Azure resources, including CPU utilization, at near-real-time intervals (typically every 1 minute for Azure VMs). Metrics are lightweight, low-latency, and designed for real-time monitoring and alerting, making them ideal for tracking CPU usage without the overhead of log ingestion.

Exam trap

The trap here is that candidates often confuse 'real-time monitoring' with 'log-based analysis' and select Logs (Option B), not realizing that Metrics are specifically designed for low-latency, numeric performance data like CPU utilization, while Logs are for text-based events with higher latency.

How to eliminate wrong answers

Option B (Logs) is wrong because Azure Monitor Logs collects and stores textual, event-based data (e.g., system logs, application traces) with higher latency and is not optimized for real-time numeric performance counters like CPU utilization; it requires Log Analytics queries and is better suited for troubleshooting and historical analysis. Option C (Alerts) is wrong because Alerts are a notification mechanism that can be triggered by metric thresholds or log queries, but they are not a data collection or visualization feature themselves—they depend on Metrics or Logs as data sources. Option D (Workbooks) is wrong because Workbooks are interactive dashboards that combine data from multiple sources (Metrics, Logs, etc.) for visualization and reporting, but they do not natively collect or provide real-time CPU utilization data on their own.

Practice this question →
35
Drag & Dropmedium

Arrange the steps to configure auto-scaling for an Azure App Service in the correct order.

Drag or tap steps into the slots.

Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4

Why this order

First navigate to App Service, then scale out, enable autoscale, configure rules, set limits.

Practice this question →
36
MCQmedium

Your Azure Functions app (running on the Consumption plan) processes messages from an Azure Storage queue. Occasionally, the function fails due to a timeout after 5 minutes. You need to increase the maximum execution time without changing the plan. What should you do?

A.Set the functionTimeout property in host.json to 10 minutes
B.Migrate the function app to the Premium or Dedicated plan
C.Use Durable Functions to split the work
D.Increase the visibility timeout of the queue message
AnswerA

The `functionTimeout` property within the `host.json` file is the correct and most direct mechanism to adjust the execution timeout for all functions within an Azure Functions app. On the Consumption plan, this value can be increased from the default 5 minutes up to a maximum of 10 minutes. This modification directly addresses the need to extend a single function's runtime without migrating to a different hosting plan, aligning perfectly with the problem's constraints.

Why this answer

On the Consumption plan, the default function timeout is 5 minutes, but it can be extended up to 10 minutes by setting the functionTimeout property in host.json. This is the only way to increase the timeout without changing the hosting plan. The setting applies to all functions in the app.

Exam trap

AZ-204 often tests the misconception that you can increase timeout by changing queue visibility or by using Durable Functions, but the trap is not knowing the host.json setting and its plan-specific limits.

How to eliminate wrong answers

Option B is wrong because migrating to Premium or Dedicated plan would allow longer timeouts, but the requirement is to avoid changing the plan. Option C is wrong because using Durable Functions is a design pattern to orchestrate long-running workflows, but it doesn't directly increase the timeout of a single function execution; it's a workaround, not a configuration change. Option D is wrong because increasing the visibility timeout of the queue message only affects how long the message is invisible to other consumers, not the function's execution timeout.

Practice this question →
37
Matchingmedium

Match each Azure container service to its primary use case.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

Run containers on demand without orchestration

Managed Kubernetes cluster for orchestration

Serverless containers for microservices

Platform for building and managing microservices

Why these pairings

The correct matches are: AKS → orchestration with Kubernetes; ACI → on-demand containers; ACR → image registry; Container Apps → serverless containers with autoscaling. Common confusions include swapping AKS with ACI or mixing orchestration with simple container execution.

Practice this question →
38
MCQmedium

You are monitoring a web application with Application Insights. The application occasionally returns HTTP 500 errors. You want to be notified immediately when the error rate exceeds 5% of all requests in a rolling 5-minute window. Which feature of Application Insights should you configure?

A.Create a Smart Detection rule for anomalous failures.
B.Create a metric alert on the 'Failed requests' metric with a threshold of 5%.
C.Create a log alert using a Kusto query that calculates the percentage of failed requests over the last 5 minutes, with an alert condition when the result exceeds 0.05.
D.Create an availability test that checks for HTTP 200 responses and alert on failures.
AnswerC

Log alerts allow complex queries. For example: 'requests | where timestamp > ago(5m) | summarize total=count(), failures=countif(success == false) | extend percent = failures * 100.0 / total | where percent > 5'. This triggers an alert when the condition is met.

Why this answer

A log alert using a Kusto query allows you to calculate the exact percentage of failed requests over a rolling 5-minute window and trigger when that percentage exceeds 0.05 (5%). This is the only option that supports a dynamic, percentage-based threshold on a rolling time window, which is required for the stated condition. Metric alerts on 'Failed requests' measure absolute counts, not percentages, and Smart Detection does not allow custom percentage thresholds.

Exam trap

The trap here is that candidates confuse metric alerts (which work on absolute counts or rates) with log alerts (which can compute custom ratios like percentages), leading them to choose Option B without realizing that the 'Failed requests' metric cannot be configured to alert on a percentage threshold.

How to eliminate wrong answers

Option A is wrong because Smart Detection for anomalous failures uses machine learning to detect unusual patterns in failure rates, not a fixed 5% threshold over a 5-minute window; it cannot be configured to alert on a specific percentage. Option B is wrong because a metric alert on the 'Failed requests' metric measures the absolute count or rate of failed requests, not the percentage of failed requests relative to total requests; you cannot set a threshold of 5% on this metric directly. Option D is wrong because an availability test checks specific URLs for HTTP 200 responses and alerts on individual test failures, not on the aggregate error rate across all requests in a rolling time window.

Practice this question →
39
MCQhard

You deploy a microservices architecture on Azure Kubernetes Service (AKS). Some pods report OOMKilled errors. Which diagnostic step should you take first?

A.Enable cluster autoscaler to add more nodes
B.Review container resource requests and limits in the pod YAML
C.Check node memory utilization with kubectl top nodes
D.Configure horizontal pod autoscaler based on memory
AnswerB

An OOMKilled (Out Of Memory Killed) event is a direct indication that a container process attempted to consume more memory than the `resources.limits.memory` value specified in its pod's YAML definition. Reviewing these container resource limits is the most direct and effective action, as it allows you to identify if the allocated memory is insufficient for the application's actual workload. Adjusting these limits, after proper profiling, directly addresses the root cause of the termination.

Why this answer

The OOMKilled error indicates that a container exceeded its memory limit. The first diagnostic step is to review the container's resource requests and limits in the pod YAML to determine if the memory limit is set too low for the workload. This directly addresses the root cause before scaling or checking node-level metrics.

Exam trap

The trap here is that candidates often jump to scaling solutions (cluster autoscaler or HPA) or node-level monitoring, overlooking that OOMKilled is a container-level limit violation that must be diagnosed by examining the pod's resource configuration first.

How to eliminate wrong answers

Option A is wrong because enabling cluster autoscaler adds more nodes to handle node-level resource pressure, but it does not fix a container that is already hitting its memory limit; the pod will still be OOMKilled on any node. Option C is wrong because checking node memory utilization with 'kubectl top nodes' shows aggregate node memory usage, not per-container limits, and cannot identify if a specific container's limit is too low. Option D is wrong because configuring a horizontal pod autoscaler based on memory would scale the number of pods in response to average memory utilization, but it does not address the immediate cause of a single container exceeding its hard limit; the pod would still be OOMKilled before scaling occurs.

Practice this question →
40
MCQeasy

You are using Azure Application Insights to monitor a web application. You need to create a custom dashboard that shows the number of failed requests per endpoint over the last 24 hours. Which query language should you use?

A.Python
B.Kusto Query Language (KQL)
C.SQL
D.PowerShell
AnswerB

KQL is the native query language for Azure Application Insights, Log Analytics and Monitor. Writing a KQL query against the requests table, filtered on success equals false and grouped by endpoint name, returns failed requests per endpoint over the last 24 hours, satisfying the dashboard requirement.

Why this answer

Azure Application Insights stores telemetry data in a Log Analytics workspace, which is queried using Kusto Query Language (KQL). To create a custom dashboard showing failed requests per endpoint over the last 24 hours, you would use a KQL query that filters on 'requests' where 'success == false', then summarizes by 'cloud_RoleInstance' or 'url' using the 'summarize' operator and the 'bin' function for time intervals. KQL is the native query language for Azure Monitor and Application Insights, making it the correct choice for this scenario.

Exam trap

The trap here is that candidates may confuse Application Insights with traditional SQL-based monitoring tools, or assume that any scripting language (like Python or PowerShell) can be used directly in the Azure portal's query editor, when in fact KQL is the only supported query language for Application Insights log queries and dashboards.

How to eliminate wrong answers

Option A is wrong because Python is a general-purpose programming language and is not used to directly query Application Insights data; while you could use Python with the Azure Monitor SDK to retrieve data, the question specifically asks for the query language used within the Azure portal or dashboards, which is KQL. Option C is wrong because SQL is not supported for querying Application Insights telemetry; Application Insights uses KQL, which has a different syntax and operators (e.g., 'summarize', 'where', 'project') compared to SQL's SELECT/FROM/WHERE structure. Option D is wrong because PowerShell is a scripting language and automation tool, not a query language for directly querying Application Insights data; although you can use PowerShell cmdlets to retrieve logs, the native query language for dashboards and log analytics is KQL.

Practice this question →
41
MCQeasy

You need to diagnose why an Azure App Service web app returns HTTP 503 errors during peak traffic. Which Application Insights feature should you use?

A.Availability tests
B.Log Analytics query for failed requests
C.Application Map
D.Live Metrics
AnswerD

Live Metrics Stream, part of Application Insights, provides a real-time, near-instantaneous view of your application's performance and health directly from the running application instance. It streams key metrics like requests, failures, CPU usage, memory, and custom events with minimal latency. This capability is essential for diagnosing why a web app is returning errors right now, allowing developers to observe active issues, trace individual requests, and identify performance anomalies as they occur.

Why this answer

Live Metrics (D) is the correct choice because it provides real-time monitoring of server-side performance metrics, including HTTP 503 errors, as they occur during peak traffic. This allows you to immediately correlate the errors with spikes in CPU, memory, or request rates, enabling rapid diagnosis of resource exhaustion or throttling issues in the App Service plan.

Exam trap

The trap here is that candidates often choose Log Analytics queries (B) because they associate 'failed requests' with error diagnosis, but they overlook that Live Metrics provides the only real-time view necessary to diagnose transient 503 errors during active peak traffic.

How to eliminate wrong answers

Option A is wrong because Availability tests are designed to proactively monitor the uptime and responsiveness of your web app from external locations, not to diagnose the cause of 503 errors during live traffic. Option B is wrong because Log Analytics queries for failed requests are historical and require data to be ingested and indexed, which introduces latency; they cannot provide the real-time diagnostics needed during an ongoing peak traffic event. Option C is wrong because Application Map visualizes the distributed topology and dependencies of your application, but it does not offer real-time performance counters or live error rates needed to pinpoint the immediate cause of 503 errors.

Practice this question →
42
MCQmedium

You are investigating a slow API call in your Azure web app. Application Insights shows that the request took 10 seconds. You need to view all the dependencies (database calls, external HTTP requests) that contributed to this request. What should you use?

A.Application Map
B.Live Metrics
C.Transaction Search
D.Usage Analysis
AnswerC

Transaction Search in Application Insights is the ideal tool for investigating a specific slow API call because it allows you to locate individual requests using criteria like request ID, URL, or duration. Once identified, it provides a comprehensive end-to-end transaction trace, detailing all operations, dependencies (like database calls or external HTTP requests), and their respective durations within that single request. This granular view is crucial for pinpointing the exact bottleneck responsible for the slowness.

Why this answer

Transaction Search (now part of the 'Search' experience in Application Insights) allows you to query individual requests and drill into their correlated dependency calls, such as SQL queries or external HTTP requests, showing the exact duration and sequence of each dependency. This is the correct tool to identify which specific dependencies contributed to the 10-second request latency.

Exam trap

The trap here is that candidates often confuse Application Map (a high-level topology view) with the detailed dependency drill-down available in Transaction Search, leading them to choose A when they need to see the specific calls and timings for a single request.

How to eliminate wrong answers

Option A is wrong because Application Map provides a topological view of your application's components and their health, but it does not show the detailed dependency call list or timing for a specific request. Option B is wrong because Live Metrics shows real-time performance data (e.g., request rate, failure count) but does not allow you to inspect historical dependency details for a past slow request. Option D is wrong because Usage Analysis focuses on user behavior metrics (e.g., page views, sessions) and is not designed for diagnosing dependency-level performance issues.

Practice this question →
43
MCQmedium

You are troubleshooting an Azure App Service that runs a Node.js application. The application returns HTTP 500 errors intermittently. Application Insights is configured. Which telemetry item should you examine first to find the root cause?

A.Exceptions
B.Traces
C.Dependencies
D.Requests
AnswerA

When troubleshooting an application crash or unexpected behavior, Exceptions telemetry in Application Insights is the most direct and comprehensive data type. It automatically collects unhandled exceptions, including stack traces, exception types, messages, and associated request context, which are crucial for pinpointing the exact line of code or component causing the issue in an Azure App Service. This detailed information is invaluable for debugging and understanding the root cause of application failures.

Why this answer

HTTP 500 errors indicate server-side failures, and Application Insights captures these as Exception telemetry when an unhandled exception occurs in the Node.js runtime. Examining the Exception telemetry first allows you to see the stack trace, error message, and call details, which directly point to the root cause of the intermittent failures.

Exam trap

The trap here is that candidates often pick 'Requests' because they see the 500 status code, but they forget that request telemetry only shows the outcome, not the underlying exception details needed for root cause analysis.

How to eliminate wrong answers

Option B (Traces) is wrong because traces are custom log messages (e.g., console.log or app insights trackTrace) and do not automatically capture unhandled exceptions that cause HTTP 500 errors. Option C (Dependencies) is wrong because dependency telemetry tracks outbound calls (e.g., to databases or APIs) and may show failures, but it does not directly reveal the server-side exception that triggered the 500 response. Option D (Requests) is wrong because request telemetry records the incoming HTTP request and its result code (500), but it does not include the exception details or stack trace needed to diagnose the intermittent failure.

Practice this question →
44
MCQhard

You are optimizing an Azure SQL Database that runs a heavy reporting workload. Queries are slow due to high logical reads. Which index strategy should you recommend?

A.Use columnstore indexes on fact tables
B.Create nonclustered indexes with included columns
C.Disable auto-update statistics
D.Rebuild clustered indexes with higher fill factor
AnswerA

Columnstore indexes are primarily designed for data warehousing and analytical workloads, excelling at compressing and scanning large datasets for aggregations. For point queries, which retrieve specific rows, the overhead of decompressing and processing individual row groups can actually increase logical reads compared to traditional row-store indexes. They are not optimized for the rapid, single-row lookups typical of heavy read OLTP scenarios, making them unsuitable for directly reducing logical reads for such queries.

Why this answer

High logical reads in a heavy reporting workload are often best addressed by columnstore indexes. Columnstore indexes provide significant data compression, reducing the number of pages that need to be read from disk. They also enable batch mode processing and segment elimination, which dramatically improve performance for analytical queries involving large scans and aggregations, thereby directly reducing logical reads across the workload.

Exam trap

The trap here is that candidates might focus on specific query optimizations like covering indexes (Option B) to eliminate key lookups. However, for a heavy reporting workload with general high logical reads, columnstore indexes (Option A) offer a more comprehensive and impactful solution by optimizing data storage and processing for analytical queries, reducing the overall volume of data read.

How to eliminate wrong answers

Option A is wrong because columnstore indexes are optimized for large-scale analytical aggregations and data warehousing, but they do not specifically target the reduction of logical reads caused by key lookups in a heavy reporting workload; they are better suited for batch processing and compression. Option C is wrong because disabling auto-update statistics would cause the query optimizer to use stale cardinality estimates, leading to poor execution plans and potentially even higher logical reads, not lower. Option D is wrong because rebuilding clustered indexes with a higher fill factor reduces page splits during inserts/updates but does not reduce logical reads for read-heavy reporting queries; it may even increase logical reads by leaving more empty space on pages.

Practice this question →
45
MCQmedium

Your Azure Kubernetes Service (AKS) cluster experiences node failures. Which Azure service provides automated node repair?

A.Azure Sentinel
B.Microsoft Defender for Cloud
C.AKS node auto-repair
D.Azure Monitor
AnswerC

AKS node auto-repair is a built-in feature designed to automatically monitor and remediate unhealthy worker nodes within an Azure Kubernetes Service cluster. It proactively identifies issues such as unresponsive nodes, disk space problems, or failed kubelet processes. Upon detecting an unhealthy state, this feature attempts to restart the node or, if necessary, reimage it to restore its operational health without manual intervention. This directly addresses node health problems.

Why this answer

C is correct because AKS node auto-repair is a built-in feature that automatically detects unhealthy nodes (based on Node Conditions like 'NotReady' or 'DiskPressure') and initiates repair actions such as reimaging the node. This feature is specific to AKS and operates at the cluster level without requiring external services.

Exam trap

The trap here is that candidates may confuse Azure Monitor's alerting capabilities or Microsoft Defender for Cloud's security recommendations with actual automated remediation, but neither service performs node-level repair actions in AKS.

How to eliminate wrong answers

Option A is wrong because Azure Sentinel is a Security Information and Event Management (SIEM) service for threat detection and incident response, not for automated node repair in AKS. Option B is wrong because Microsoft Defender for Cloud provides security posture management and workload protection, including vulnerability assessments and threat alerts, but it does not perform automated node repair. Option D is wrong because Azure Monitor collects metrics, logs, and alerts for observability and diagnostics, but it does not execute repair actions on AKS nodes.

Practice this question →
46
MCQeasy

An application uses Azure Application Insights for monitoring. You need to write a query to analyze the number of failed requests and exceptions over the past hour. Which query language should you use?

A.SQL
B.Kusto Query Language (KQL)
C.PowerShell
D.Azure CLI
AnswerB

Kusto Query Language (KQL) is the native and primary query language for Azure Monitor Logs and Application Insights. It is specifically designed for querying large volumes of structured, semi-structured, and unstructured data, making it ideal for analyzing application telemetry like requests, dependencies, exceptions, and traces. KQL provides powerful operators for filtering, aggregating, joining, and visualizing data, enabling developers to efficiently diagnose issues and understand application performance and usage patterns.

Why this answer

Azure Application Insights stores telemetry data in a Log Analytics workspace, which is queried using Kusto Query Language (KQL). KQL is the native query language for Azure Data Explorer and is specifically designed for time-series analysis, filtering, and aggregation of log data. To analyze failed requests and exceptions over the past hour, you would use KQL operators like `where`, `summarize`, and `bin` to filter by timestamp and count events.

Exam trap

The trap here is that candidates may confuse KQL with SQL due to superficial similarities in syntax (e.g., `where` clauses), but Azure Application Insights exclusively uses KQL, not SQL, for log queries.

How to eliminate wrong answers

Option A is wrong because SQL is not supported for querying Application Insights data; the underlying storage is a column-store optimized for KQL, not a relational database. Option C is wrong because PowerShell is a scripting language used for automation and resource management, not for querying telemetry data directly from Application Insights. Option D is wrong because Azure CLI is a command-line tool for managing Azure resources, not a query language for analyzing log data.

Practice this question →
47
MCQmedium

You have an Azure Function app that uses Durable Functions. You notice that some orchestrations are taking longer than expected. You need to monitor the history of orchestration instances. What should you use?

A.Application Insights
B.Azure Monitor Metrics
C.Azure Storage Explorer
D.Durable Functions HTTP management APIs
AnswerD

The Durable Functions HTTP management APIs are specifically designed to query and manage the lifecycle of individual orchestration instances. These APIs provide comprehensive details, including the current runtime status (e.g., Running, Completed, Failed), input, output, and the complete execution history of activities and sub-orchestrations for a given instance ID. This direct access to the orchestration state machine makes them the authoritative source for detailed instance history and management.

Why this answer

D is correct because the Durable Functions HTTP management APIs provide direct access to the orchestration instance history, including status queries, raise events, and terminate operations. These APIs return the full execution history of an orchestration instance, allowing you to inspect each step and identify delays. This is the most targeted way to monitor the history of specific orchestration instances without additional configuration.

Exam trap

The trap here is that candidates often assume Application Insights is the default monitoring tool for all Azure Functions scenarios, but for Durable Functions instance-level history, the built-in HTTP management APIs are the direct and correct answer without requiring additional setup.

How to eliminate wrong answers

Option A is wrong because Application Insights is a general-purpose monitoring and diagnostics service that requires additional instrumentation and configuration to capture Durable Functions telemetry; it does not directly expose the orchestration instance history without custom queries. Option B is wrong because Azure Monitor Metrics provides aggregated performance metrics (e.g., execution count, duration) but does not offer per-instance history or detailed step-level data. Option C is wrong because Azure Storage Explorer can view the underlying storage tables and queues used by Durable Functions, but it does not provide a structured, queryable history of orchestration instances and requires manual navigation of raw storage artifacts.

Practice this question →
48
MCQhard

You query Application Insights with the KQL query in the exhibit. The chart shows a spike in 500 errors at 2:00 PM. What is the next step to diagnose the cause?

A.Check availability tests for the same period
B.Query exceptions and traces for the 2:00 PM hour
C.Scale up the App Service plan
D.Run a profiler on the 2:00 PM time range
AnswerB

Querying "exceptions" and "traces" tables in Application Insights for the specific 2:00 PM hour is the most effective diagnostic step. The "exceptions" table captures details of unhandled exceptions thrown by the application, including stack traces and error messages, directly indicating code failures. Correlating these with "traces" (custom log messages) provides crucial contextual information, such as variable states or execution flow leading up to the exception, enabling a precise root cause analysis.

Why this answer

When a spike in 500 errors is detected in Application Insights, the next logical step is to query exceptions and traces for the specific time period (2:00 PM). This allows you to correlate the error count with detailed exception messages, stack traces, and dependency calls, which directly reveal the root cause of the failures. KQL queries like `exceptions | where timestamp between (datetime(14:00) .. datetime(15:00))` or joining with `traces` provide the granular data needed for diagnosis.

Exam trap

The trap here is that candidates confuse diagnostic steps with remediation actions, choosing to scale up (Option C) or run a profiler (Option D) instead of first investigating the actual error data via exceptions and traces.

How to eliminate wrong answers

Option A is wrong because availability tests measure endpoint responsiveness and uptime from external locations, not the internal server-side errors (500s) shown in the chart; they would not provide exception details. Option C is wrong because scaling up the App Service plan is a reactive scaling action, not a diagnostic step—it does not help identify the cause of the errors and may waste resources if the issue is code-related. Option D is wrong because the Application Insights Profiler captures performance traces for slow requests, not for error diagnostics; it is designed for latency analysis, not for examining exception details or error causes.

Practice this question →
49
MCQmedium

Your team is using Azure DevOps to deploy an Azure Kubernetes Service (AKS) cluster. You want to automatically roll back a deployment if the new version causes a high error rate. Which Azure service should you use to implement this?

A.Azure Service Health
B.Azure Monitor
C.Azure Traffic Manager
D.Azure Policy
AnswerB

Azure Monitor is the comprehensive observability platform for collecting, analyzing, and acting on telemetry data from your Azure resources, including AKS. It can ingest metrics like HTTP error rates, CPU utilization, and pod restart counts, allowing you to define alert rules that trigger when deployment health degrades. These alerts can then invoke webhooks or Azure Functions, which an Azure DevOps pipeline can use as a signal to automatically initiate a rollback to a previously stable version of your application.

Why this answer

Azure Monitor, specifically Application Insights, can be configured with alert rules that trigger on metrics like server error rate. When the error rate exceeds a threshold, an Azure Monitor alert can invoke an Azure Automation runbook or a webhook to initiate a Kubernetes rollback via `kubectl rollout undo` or a Helm rollback. This provides automated, event-driven rollback without manual intervention.

Exam trap

The trap here is that candidates confuse Azure Monitor (which monitors application metrics and can trigger automated actions) with Azure Service Health (which only monitors Azure platform health, not your application's error rate).

How to eliminate wrong answers

Option A is wrong because Azure Service Health provides notifications about Azure service outages and planned maintenance, not application-level error rate monitoring or automated rollback actions. Option C is wrong because Azure Traffic Manager is a DNS-based traffic load balancer that routes traffic across endpoints; it does not monitor application error rates or trigger deployment rollbacks. Option D is wrong because Azure Policy enforces compliance rules on Azure resources (e.g., tagging, allowed SKUs) and cannot monitor runtime application errors or execute Kubernetes rollback commands.

Practice this question →
50
Multi-Selectmedium

Which TWO Azure services can be used to monitor and diagnose performance issues in an Azure Kubernetes Service (AKS) cluster?

Select 2 answers
A.Microsoft Defender for Cloud
B.Azure Network Watcher
C.Application Insights for AKS
D.Azure SQL Analytics
E.Azure Monitor Container Insights
AnswersC, E

Application Insights for AKS, a feature of Azure Monitor, provides comprehensive application performance management (APM) capabilities, including distributed tracing, dependency mapping, and real-time application telemetry. It allows developers to monitor live applications, detect performance anomalies, diagnose failures, and understand user behavior across microservices deployed on AKS. This makes it highly effective for deep application-level monitoring and diagnosis.

Why this answer

Application Insights for AKS (option C) is correct because it provides application-level monitoring, including distributed tracing, dependency tracking, and performance diagnostics for microservices running in AKS. It integrates with the AKS cluster to collect telemetry from pods and containers, enabling detection of slow requests, exceptions, and dependency failures that impact application performance.

Exam trap

The trap here is that candidates often confuse security monitoring (Defender for Cloud) with performance monitoring, or assume Network Watcher covers container-level diagnostics, when in fact only Application Insights and Container Insights provide the necessary application and container performance telemetry for AKS.

Practice this question →
51
MCQmedium

You are monitoring an Azure App Service using Application Insights. You notice that the server response time is high for certain requests. You need to drill down to see which external dependencies (like databases or APIs) are causing the delay. Which Application Insights feature should you use?

A.Live Metrics
B.Application Map
C.Profiler
D.Snapshot Debugger
AnswerC

Profiler captures detailed, per-request execution traces, including the full call stack and the precise time spent in each method, I/O operation, and external dependency call (e.g., database queries, HTTP requests). By analyzing these traces, it can pinpoint exactly which part of the code or which specific external dependency is consuming the most time within a slow request. This granular data is invaluable for identifying the root cause of performance bottlenecks, such as a slow database query or an inefficient API call, by showing its exact contribution to the overall request duration.

Why this answer

Profiler (C) is correct because it provides a detailed, code-level view of request processing, including the time spent on each external dependency call (e.g., SQL queries, HTTP calls to APIs). It captures execution traces that break down the total server response time into individual dependency durations, allowing you to pinpoint which external service is causing the delay.

Exam trap

The trap here is that candidates confuse Application Map (which shows dependency relationships) with Profiler (which shows per-request timing), leading them to select a visualization tool instead of a performance-analysis tool.

How to eliminate wrong answers

Option A is wrong because Live Metrics shows real-time telemetry (e.g., request rate, failure count) but does not provide dependency-level breakdowns or call-duration details. Option B is wrong because Application Map visualizes the topology of your application and its dependencies but does not drill into per-request timing or trace individual dependency calls. Option D is wrong because Snapshot Debugger captures debug snapshots on exceptions, not for analyzing response-time delays caused by dependencies.

Practice this question →
52
MCQhard

Refer to the exhibit. You run these Azure CLI commands for an Azure Function app. When the app is accessed from https://app.contoso.com, what is the expected behavior?

A.Only GET requests are allowed
B.Requests from the allowed origin are accepted
C.Requests are blocked because FTPS is required
D.All requests are blocked because no origins are allowed
AnswerB

The `az webapp cors add --origins https://app.contoso.com` command successfully configures the Azure Web App's Cross-Origin Resource Sharing (CORS) policy. This action explicitly adds `https://app.contoso.com` to the list of allowed origins, meaning that web browsers will permit JavaScript code running on `https://app.contoso.com` to make cross-origin HTTP requests to the web app. Consequently, requests originating from this specific URL will be accepted and processed according to the CORS specification.

Why this answer

The Azure CLI commands shown configure CORS (Cross-Origin Resource Sharing) for the Function App. The `az functionapp cors add` command adds `https://app.contoso.com` as an allowed origin, and `az functionapp cors show` confirms that this origin is in the allowed list. When a browser-based client at `https://app.contoso.com` makes a request to the Function App, the browser checks the `Access-Control-Allow-Origin` response header.

Since the origin matches, the browser permits the request to proceed, and the Function App processes it normally. Therefore, requests from the allowed origin are accepted.

Exam trap

The trap here is that candidates confuse CORS with authentication or authorization, assuming that adding an origin somehow restricts HTTP methods or enables FTPS, when in fact CORS only controls cross-origin browser access and does not affect direct server-to-server or non-browser requests.

How to eliminate wrong answers

Option A is wrong because CORS does not restrict HTTP methods globally; it only controls which origins are allowed to make cross-origin requests, and the Function App still processes GET, POST, PUT, DELETE, etc., based on its own authorization and route configuration. Option C is wrong because FTPS (FTP over SSL) is unrelated to CORS or HTTP request handling; the commands shown do not configure FTPS, and FTPS is a separate deployment protocol, not a request-level restriction. Option D is wrong because the `cors add` command explicitly added `https://app.contoso.com` as an allowed origin, so the allowed origins list is not empty; requests from that origin are permitted.

Practice this question →
53
Drag & Dropmedium

Arrange the steps to create a CI/CD pipeline using Azure DevOps for an Azure App Service in the correct order.

Drag or tap steps into the slots.

Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4

Why this order

The correct sequence for setting up a CI/CD pipeline in Azure DevOps is: First, create a repository and push your application code. Next, create a build pipeline to compile and package your application. Then, configure the CI trigger within the build pipeline to automate builds on code changes.

After that, create a release pipeline to define the deployment steps for the build artifacts. Finally, set up approval gates within the release pipeline to control deployments to different environments.

Practice this question →
54
MCQmedium

A developer needs to run a Kusto query against application request data to identify 95th percentile latency by operation. Where should the query be run? The architecture review board prefers a managed Azure-native control.

A.Logs in Application Insights or the associated Log Analytics workspace
B.Microsoft Entra audit logs
C.Azure Key Vault diagnostic settings
D.Azure Resource Graph only
AnswerA

Application Insights stores request telemetry in a Log Analytics workspace, queryable with KQL. Running the percentile query there uses the managed Azure-native control the review board prefers, avoiding self-hosted query infrastructure while still returning 95th percentile latency grouped by operation.

Why this answer

Application Insights stores telemetry data, including request latency, in a Log Analytics workspace. Kusto queries against this data can compute percentiles (e.g., 95th) using the `percentile()` function. This is the correct location because the architecture review board prefers a managed Azure-native control, and Log Analytics is the native Azure monitoring service for running such queries.

Exam trap

The trap here is that candidates may confuse Azure Resource Graph with Log Analytics, thinking it can query telemetry data, but Resource Graph only returns resource inventory and configuration state, not performance metrics.

How to eliminate wrong answers

Option B is wrong because Microsoft Entra audit logs contain sign-in and directory activity, not application request latency data. Option C is wrong because Azure Key Vault diagnostic settings capture vault access logs (e.g., get, list, delete operations), not application performance metrics like latency. Option D is wrong because Azure Resource Graph only queries Azure resource metadata and configurations, not telemetry or performance data from applications.

Practice this question →
55
MCQmedium

You have a web application monitored by Application Insights. You want to receive an alert when the average server response time exceeds 2 seconds for a rolling 5-minute period. Which alert rule type should you create?

A.Application Insights metric alert on 'Server response time' with condition 'Greater than 2' and evaluation frequency 5 minutes
B.Log alert based on a Kusto query that measures average response time in 5-minute windows
C.Smart Detection alert on response time degradation
D.Availability test alert for HTTP response time
AnswerA

This option correctly identifies the most appropriate monitoring tool for the requirement. An Application Insights metric alert on 'Server response time' directly monitors the average duration of server-side request processing, which is a standard metric collected by the Application Insights SDK. Setting a condition 'Greater than 2' with a 5-minute evaluation frequency ensures that an alert will fire efficiently when the average response time consistently exceeds 2 seconds over that period, precisely matching the scenario's need for threshold-based monitoring.

Why this answer

A metric alert on 'Server response time' is the correct choice because it continuously evaluates the average server response time over a rolling 5-minute window and triggers when the value exceeds 2 seconds. Metric alerts are designed for near-real-time monitoring of performance counters like response time, with a fixed evaluation frequency that matches the aggregation window, making them ideal for this scenario.

Exam trap

The trap here is confusing metric alerts (which evaluate pre-aggregated performance counters in near-real-time) with log alerts (which require querying raw telemetry data and have higher latency), leading candidates to incorrectly choose the log-based option for a simple threshold-based metric condition.

How to eliminate wrong answers

Option B is wrong because a Log alert based on a Kusto query is designed for analyzing log data (e.g., traces, exceptions) and incurs ingestion latency, making it unsuitable for low-latency, rolling-window performance thresholds like server response time. Option C is wrong because Smart Detection alerts use machine learning to detect anomalies in response time patterns, not a fixed threshold of 2 seconds over a 5-minute period. Option D is wrong because Availability test alerts monitor the availability and responsiveness of an endpoint from multiple locations, not the average server response time for all requests over a rolling window.

Practice this question →
56
MCQeasy

You deploy a web app to Azure App Service. Users report intermittent 500 errors. How should you enable detailed error logging?

A.Configure Azure Storage account diagnostics
B.Set up Azure DNS logging
C.Enable Application Insights for the web app
D.Enable Azure Front Door logging
AnswerC

Application Insights, a powerful feature of Azure Monitor, is specifically designed for comprehensive monitoring of live web applications, including Azure App Service. It automatically collects vital telemetry data such as request rates, response times, failure rates, dependencies, and critically, application exceptions and custom traces from within the application's code. By integrating Application Insights, developers gain deep, real-time insights into application performance, user behavior, and can effectively identify and diagnose the root cause of user-reported errors and crashes.

Why this answer

Application Insights provides built-in server-side telemetry for Azure App Service, including detailed error tracking, stack traces, and request logs. Enabling it captures the full exception details for intermittent 500 errors, which are typically unhandled exceptions or crashes in the application code. This is the most direct and integrated way to get detailed error logs without additional infrastructure.

Exam trap

The trap here is that candidates confuse platform-level diagnostics (like storage or Front Door logs) with application-level telemetry, assuming any logging option will capture detailed error details, but only Application Insights provides the deep exception context needed for intermittent 500 errors.

How to eliminate wrong answers

Option A is wrong because Azure Storage account diagnostics store platform-level metrics and logs (e.g., CPU, network) but do not capture application-level error details like stack traces for 500 errors. Option B is wrong because Azure DNS logging records DNS query traffic, not HTTP request/response details or application errors. Option D is wrong because Azure Front Door logging captures edge-level request/response data and WAF logs, but does not provide the application server's detailed error stack traces or exception logs needed to diagnose 500 errors.

Practice this question →
57
MCQmedium

You are monitoring an Azure web app using Application Insights. You need to create a query that returns the average duration of requests for each HTTP method (GET, POST, etc.) over the last hour, sorted by duration. Which Kusto query should you use?

A.requests | summarize avg(duration) by method | order by avg_duration desc
B.requests | summarize avg(duration) by method | sort by method asc
C.requests | where timestamp > ago(1h) | summarize avg(duration) by method | order by avg_duration desc
D.requests | where timestamp > ago(1h) | summarize avg(duration) by method | sort by method
AnswerC

This KQL query is correctly structured for monitoring recent web app performance. The `where timestamp > ago(1h)` clause efficiently filters the data to only the last hour, ensuring relevance for current operational insights. It then accurately calculates the `avg(duration)` for each `method` and presents the results ordered in `descending` fashion by this average duration, highlighting the slowest request types immediately.

Why this answer

It first filters requests to only those from the last hour using `where timestamp > ago(1h)`, then calculates the average duration grouped by HTTP method with `summarize avg(duration) by method`, and finally orders the results by the computed average duration in descending order using `order by avg_duration desc`. This matches the requirement exactly: last hour, average duration per method, sorted by duration.

Exam trap

The trap here is that candidates often forget to apply the time filter (`where timestamp > ago(1h)`) or mistakenly sort by the method name instead of the computed average duration, because the question explicitly says 'sorted by duration' but the options include plausible but incorrect sort columns.

How to eliminate wrong answers

Option A is wrong because it omits the time filter (`where timestamp > ago(1h)`), so it would return average durations across all historical data, not just the last hour. Option B is wrong because it also lacks the time filter and sorts by method name ascending instead of by average duration, which does not satisfy the 'sorted by duration' requirement. Option D is wrong because although it correctly filters to the last hour and summarizes by method, it sorts by the method name (alphabetically) rather than by the average duration, failing the 'sorted by duration' condition.

Practice this question →
58
MCQmedium

You are monitoring an Azure Web App with Application Insights. You notice that the dependency duration for a SQL database call has significantly increased. You need to identify the specific SQL query that is causing the slowness. Which Application Insights feature should you use?

A.Application Map
B.Performance blade and drill into Dependencies
C.Live Metrics Stream
D.Smart Detection
AnswerB

The Performance blade within Application Insights is specifically designed to analyze the performance of various operations, including external dependencies. By navigating to the 'Dependencies' tab within this blade, users can view a comprehensive list of all dependency calls, such as SQL database interactions. Crucially, it provides detailed telemetry including the full SQL query text, average duration, call count, and success rate, enabling precise identification and investigation of slow or failing database queries.

Why this answer

The Performance blade in Application Insights allows you to drill into specific operations, including dependencies. By selecting the SQL dependency with increased duration, you can view the 'Dependencies' tab to see the exact SQL query text, duration, and other details. This directly identifies the slow query without needing to instrument code changes.

Exam trap

The trap here is that candidates often confuse the high-level monitoring view (Application Map) or real-time streaming (Live Metrics) with the diagnostic drill-down capability of the Performance blade, which is specifically designed for root-cause analysis of slow operations.

How to eliminate wrong answers

Option A is wrong because Application Map provides a visual overview of component interactions and dependency health, but it does not show the specific SQL query text or allow drilling into individual slow queries. Option C is wrong because Live Metrics Stream shows real-time performance data but does not retain historical query details or allow deep analysis of specific slow dependencies. Option D is wrong because Smart Detection proactively alerts on anomalies but does not provide the raw query text or a drill-down interface to identify the specific SQL statement causing slowness.

Practice this question →
59
MCQmedium

You have an App Service web app with Application Insights configured. You want to create an alert that fires when the server response time exceeds 2 seconds for a rolling 10-minute window. Which type of alert rule should you create?

A.Log alert
B.Metric alert
C.Activity log alert
D.Smart detection alert
AnswerB

Metric alerts are the most appropriate and efficient mechanism for monitoring specific performance indicators, such as server response time, directly from Application Insights. They evaluate a numerical metric against a predefined static or dynamic threshold over a specified aggregation period and frequency. This direct integration with Azure Monitor metrics ensures low latency and cost-effective detection of performance degradation.

Why this answer

Metric alerts in Azure Monitor evaluate resource-level performance counters at regular intervals, making them ideal for threshold-based conditions like server response time. Application Insights automatically collects server response time as a pre-aggregated metric, so a metric alert can check whether the average exceeds 2 seconds over a rolling 10-minute window without needing to query raw log data.

Exam trap

The trap here is that candidates confuse log-based queries (Log Analytics) with metric-based thresholds, assuming that any Application Insights data must be queried via logs, when in fact common performance counters like server response time are exposed as metrics for simpler and faster alerting.

How to eliminate wrong answers

Option A is wrong because log alerts run Kusto queries against log data (e.g., requests table) and are better suited for complex patterns or correlation across multiple signals, not for simple, low-latency threshold checks on a single metric. Option C is wrong because activity log alerts fire only on Azure resource management events (e.g., create, delete, scale) and cannot monitor application performance metrics like server response time. Option D is wrong because smart detection alerts use machine learning to automatically detect anomalies in telemetry patterns (e.g., sudden failure spikes) and cannot be configured with a fixed threshold of 2 seconds.

Practice this question →
60
MCQmedium

An Azure web app is experiencing high memory usage. You want to collect memory dumps periodically to analyze the issue without restarting the app. Which Azure App Service diagnostic feature should you use?

A.Application Insights Profiler
B.Diagnostic Settings
C.Application Snapshot Debugger
D.Auto-healing
AnswerC

The Application Snapshot Debugger, integrated with Application Insights, is specifically engineered to capture a full memory snapshot or dump of a running application process. It can be triggered on demand or automatically upon specific exception occurrences, allowing developers to inspect the application's state, including its entire memory heap, without requiring an application restart. This capability is crucial for analyzing high memory usage by examining object allocations, identifying memory leaks, and understanding object retention paths in detail.

Why this answer

The Application Snapshot Debugger captures memory dumps (snapshots) of a production web app when an exception occurs or when configured to trigger on specific conditions, such as high memory usage, without restarting the app. It is specifically designed for debugging memory leaks and high CPU/memory issues in Azure App Service by providing detailed snapshots of the process state, including the heap, at the point of interest. While not strictly time-based periodic, if the high memory condition occurs repeatedly, the debugger can be configured to capture multiple snapshots over time for analysis.

Exam trap

The trap here is that candidates confuse Application Insights Profiler (which profiles CPU/request timing) with the Snapshot Debugger (which captures memory dumps), or they assume Diagnostic Settings can collect in-process memory dumps when it only handles log streaming.

How to eliminate wrong answers

Option A is wrong because Application Insights Profiler is a performance tracing tool that captures CPU and request execution time profiles, not memory dumps; it does not capture heap snapshots. Option B is wrong because Diagnostic Settings is used to stream platform logs and metrics to destinations like Log Analytics or Storage, not to collect in-process memory dumps. Option D is wrong because Auto-healing is a recovery feature that restarts or recycles the app based on conditions like memory thresholds, but it does not collect memory dumps for analysis and would restart the app, which contradicts the requirement to avoid restarting.

Practice this question →
61
MCQeasy

You are monitoring an Azure App Service with Application Insights. You need to create a custom dashboard that shows the number of requests over time and the average server response time. Which Application Insights feature should you use to create this dashboard?

A.Live Metrics Stream
B.Metrics Explorer
C.Analytics (Logs)
D.Availability Tests
AnswerB

Metrics Explorer is the primary tool within Application Insights for visualizing aggregated metric data over custom time ranges. It allows users to select standard or custom metrics, apply various aggregation types like sum, average, or count, and filter results to create insightful charts. These customizable charts can then be easily pinned to Azure dashboards, providing continuous historical monitoring and performance trend analysis.

Why this answer

Metrics Explorer is the correct feature because it allows you to create custom charts and dashboards by selecting specific metrics like 'Requests' and 'Server response time' from your Application Insights resource. You can aggregate these metrics over time and pin them to an Azure dashboard for monitoring. Live Metrics Stream shows real-time data but cannot be used for historical charting or dashboard pinning, while Analytics (Logs) requires Kusto queries for custom visualizations and is not optimized for simple metric dashboards.

Exam trap

The trap here is that candidates often confuse Live Metrics Stream (real-time) with Metrics Explorer (historical and dashboard-capable), or assume that Analytics (Logs) is the only way to create custom visualizations, overlooking the simpler and more appropriate Metrics Explorer for pre-aggregated metric dashboards.

How to eliminate wrong answers

Option A is wrong because Live Metrics Stream displays real-time telemetry with near-zero latency but does not support historical data aggregation or pinning to a persistent dashboard; it is designed for live debugging, not for creating a dashboard of requests over time. Option C is wrong because Analytics (Logs) uses Kusto Query Language (KQL) to query raw log data and can build charts, but it is not the primary feature for simple metric-based dashboards; Metrics Explorer is the dedicated tool for pre-aggregated metrics with built-in charting and dashboard integration. Option D is wrong because Availability Tests are used to monitor the uptime and responsiveness of your web application from multiple locations, generating test results and alerts, but they do not provide the request count or server response time metrics needed for the described dashboard.

Practice this question →
62
MCQhard

Your team uses Azure DevOps to deploy a web app to Azure App Service. The deployment fails intermittently with a '500 Internal Server Error' after successful code upload. You want to capture a memory dump of the process when the error occurs. What should you configure?

A.Configure an autoscale rule in Azure Monitor
B.Use App Service Diagnostics to collect a memory dump
C.Set up Azure API Management policies
D.Enable Application Insights Snapshot Debugger
AnswerB

App Service Diagnostics is the correct and most direct tool within Azure App Service for troubleshooting and resolving application issues, including performance problems or crashes. It provides a suite of diagnostic tools, prominently featuring the ability to collect full or mini-memory dumps on demand. These dumps are crucial for in-depth post-mortem analysis, allowing developers to inspect the application's memory state and identify root causes of complex issues.

Why this answer

App Service Diagnostics provides a built-in 'Collect Memory Dump' tool that can be triggered on specific HTTP error codes, such as 500 Internal Server Error. This allows you to capture a full process dump of the web app when the error occurs, enabling offline analysis of the failure without modifying application code.

Exam trap

The trap here is that candidates confuse Application Insights Snapshot Debugger (which captures lightweight exception snapshots) with a full memory dump, leading them to choose option D, even though Snapshot Debugger does not provide the comprehensive process memory required for deep debugging of intermittent 500 errors.

How to eliminate wrong answers

Option A is wrong because autoscale rules in Azure Monitor adjust the number of instances based on metrics like CPU or memory, but they do not capture memory dumps or diagnose application-level errors. Option C is wrong because Azure API Management policies control API gateway behavior (e.g., rate limiting, transformation) and have no capability to collect memory dumps from an App Service. Option D is wrong because Application Insights Snapshot Debugger captures snapshots of exceptions in .NET applications, but it does not produce a full memory dump of the process; it only captures a partial snapshot of the call stack and variables at the point of an exception.

Practice this question →
63
MCQeasy

The team needs to receive an email when an App Service's HTTP 5xx error rate exceeds 5 percent for more than five consecutive minutes. No custom code should be written. What combination of Azure Monitor features implements this requirement?

A.Create a metric alert on the Http5xxErrors metric with a 5-percent threshold, a 5-minute evaluation window, and an action group that sends email
B.Create a log alert that queries the App Service diagnostic log table every 5 minutes and emails the team if the 5xx count exceeds a threshold
C.Enable Application Insights availability tests and configure an alert on test failure rate
D.Configure a diagnostic setting to stream logs to Azure Storage, then write a Function that reads the storage file and sends email when errors are found
AnswerB

A log alert querying every five minutes evaluates conditions within that specific interval, not sustained breaches over consecutive periods. This fails the "more than five consecutive minutes" requirement, which demands a stateful evaluation over time. Log alerts are suitable for detecting specific event patterns or simple aggregate counts in logs within a single evaluation window, making them tempting for error detection. They would be correct if the requirement was to alert on a 5xx rate exceeding a threshold in any given five-minute period, without needing to track consecutive violations.

Why this answer

The explanation incorrectly states that a 5% threshold on the 'Http5xxErrors' metric can directly represent a 5% error rate. This metric is a count, and standard metric alerts do not provide a built-in mechanism to calculate its percentage relative to total requests. To achieve the required 'rate' calculation, a log alert with a Kusto Query Language (KQL) query is necessary to compute the ratio of 5xx errors to total requests over the specified time window.

KQL queries within log alerts are considered configuration, not custom code, thus meeting all requirements.

Exam trap

The trap here is that candidates often confuse metric alerts (which work on platform metrics like Http5xxErrors) with log alerts (which require querying diagnostic logs), or mistakenly think Application Insights availability tests are the correct tool for server-side error monitoring.

How to eliminate wrong answers

Option B is wrong because log alerts query diagnostic logs, which are not real-time and incur additional ingestion costs; they also require custom KQL queries and are not as straightforward as metric alerts for simple threshold-based monitoring. Option C is wrong because Application Insights availability tests measure endpoint responsiveness (e.g., HTTP 200/404) and failure rates, not server-side HTTP 5xx errors from App Service; they are designed for synthetic transaction monitoring, not server error rate alerts. Option D is wrong because it requires writing a custom Azure Function to read storage blobs and send emails, violating the 'no custom code' requirement; it also introduces unnecessary complexity and latency compared to built-in metric alerts.

Practice this question →
64
MCQmedium

A developer needs to run a Kusto query against application request data to identify 95th percentile latency by operation. Where should the query be run? The design must avoid adding custom operational scripts.

A.Logs in Application Insights or the associated Log Analytics workspace
B.Microsoft Entra audit logs
C.Azure Key Vault diagnostic settings
D.Azure Resource Graph only
AnswerA

Logs in Application Insights, or its integrated Log Analytics workspace, are the definitive source for application request data. Application Insights automatically collects comprehensive telemetry, including details about incoming HTTP requests, such as their duration, success status, and URL. This data is stored in dedicated tables, like `requests`, within the Log Analytics workspace, enabling powerful analysis using Kusto Query Language (KQL) to identify performance trends and troubleshoot issues.

Why this answer

Application Insights and its associated Log Analytics workspace store application request data and support Kusto Query Language (KQL) queries. Running a Kusto query against the `requests` table in the Logs workspace allows you to calculate percentile latency (e.g., using the `percentiles()` function) without custom operational scripts, as this is a built-in capability.

Exam trap

The trap here is that candidates may confuse Azure Resource Graph (which queries resource metadata) with Log Analytics (which queries telemetry data), leading them to choose Option D despite its inability to handle application performance queries.

How to eliminate wrong answers

Option B is wrong because Microsoft Entra audit logs contain sign-in and directory activity, not application request latency data. Option C is wrong because Azure Key Vault diagnostic settings capture vault access and management events, not application request performance metrics. Option D is wrong because Azure Resource Graph is designed for querying Azure resource inventory and configuration across subscriptions, not for analyzing application telemetry like request latency.

Practice this question →
65
MCQmedium

You are using Application Insights to monitor a web app. You want to automatically analyze and alert on sudden increases in request failure rates, without manually setting static thresholds. Which Application Insights feature should you use?

A.Smart Detection
B.Application Insights Profiler
C.Live Metrics Stream
D.Continuous Export
AnswerA

Azure Application Insights Smart Detection leverages machine learning algorithms to automatically identify and alert on unusual patterns in your web app's telemetry, such as sudden increases in failure rates, performance degradation, or memory leaks. It proactively analyzes incoming data without requiring manual configuration of thresholds, providing immediate insights into critical operational issues. This intelligent capability helps teams quickly pinpoint and address problems before they significantly impact users, enhancing overall application reliability.

Why this answer

Smart Detection in Application Insights automatically analyzes telemetry from your web app to detect anomalies, such as sudden increases in request failure rates, without requiring manual static thresholds. It uses machine learning models to adapt to your app's normal behavior and alert on deviations, making it ideal for dynamic monitoring scenarios.

Exam trap

The trap here is that candidates often confuse Live Metrics Stream (real-time but no analysis) with Smart Detection (which provides automatic anomaly detection and alerting), leading them to choose the wrong option for failure rate analysis.

How to eliminate wrong answers

Option B (Application Insights Profiler) is wrong because it is designed for performance profiling and tracing slow requests, not for analyzing failure rates or setting alerts. Option C (Live Metrics Stream) is wrong because it provides real-time monitoring of metrics but does not include automatic anomaly detection or alerting on failure rate changes. Option D (Continuous Export) is wrong because it exports telemetry data to storage for long-term analysis, but it does not analyze data or generate alerts for sudden failure rate increases.

Practice this question →
66
MCQmedium

Your application running on Azure App Service is experiencing intermittent timeouts. You have configured Application Insights to collect telemetry. Which metric should you analyze in the Azure portal to identify the slowest dependencies?

A.Request Duration
B.Failed Requests
C.Dependency Duration
D.Availability
AnswerC

Dependency Duration records the elapsed time of each outbound call the app makes, such as to SQL Database or an HTTP endpoint, so the slowest dependency is identified directly. It isolates downstream latency from server response time, pinpointing which external call causes the intermittent timeouts.

Why this answer

Dependency Duration in Application Insights measures the time taken by outbound calls from your application to external dependencies such as SQL databases, HTTP endpoints, and Azure services. Analyzing this metric (often in the Application Map or Performance blade) lets you pinpoint which dependency is causing the intermittent timeouts. Request Duration measures the overall server response time, which includes dependency time but does not isolate the slow dependency.

Exam trap

The trap is choosing Request Duration because it sounds like the overall slowness metric; the exam expects you to know that dependency-level telemetry is required to isolate external call latency.

How to eliminate wrong answers

Option A is wrong because Request Duration reflects total server-side processing time and does not break down which dependency is slow. Option B is wrong because Failed Requests only shows failure counts and HTTP status codes, not latency attribution. Option D is wrong because Availability measures uptime from synthetic tests, not per-dependency performance.

Practice this question →
67
Multi-Selectmedium

You are monitoring an ASP.NET Core web API with Application Insights. You want to view the SQL queries being executed, including the command text and duration, in the Application Insights portal. Which actions must you take? (Select all that apply.) (Choose 2.)

Select 2 answers
A.Install the `Microsoft.ApplicationInsights.Profiler.AspNetCore` NuGet package.
B.Install the `Microsoft.ApplicationInsights.DependencyCollector` NuGet package.
C.Set `EnableSqlCommandTextInstrumentation` to `true` in the `DependencyTrackingTelemetryModule` configuration.
D.Enable adaptive sampling to ensure all SQL queries are collected.
AnswersB, C

The Microsoft.ApplicationInsights.DependencyCollector NuGet package is the foundational component for automatically tracking outgoing calls from your application to external services, including databases, HTTP services, and message queues. This package instruments common database clients to record dependency telemetry, such as the operation name, duration, and success status for SQL calls. While it collects the fact that a SQL dependency occurred, by default, it does not capture the full SQL command text itself without further configuration.

Why this answer

The `Microsoft.ApplicationInsights.DependencyCollector` NuGet package is required to automatically collect dependency telemetry, including SQL Server calls. Without this package, Application Insights will not capture SQL dependency data at all. Option C is correct because even with the dependency collector installed, SQL command text is not collected by default for security reasons; you must explicitly set `EnableSqlCommandTextInstrumentation` to `true` in the `DependencyTrackingTelemetryModule` configuration to view the actual SQL queries and their duration in the portal.

Exam trap

The trap here is that candidates often assume installing the dependency collector alone is sufficient to see SQL command text, but they overlook the explicit configuration flag (`EnableSqlCommandTextInstrumentation`) required to enable that specific data collection.

Practice this question →
68
MCQeasy

You need to monitor the CPU and memory usage of an Azure Virtual Machine (VM) over the last 30 days. Which Azure service should you use?

A.Azure Service Health
B.Azure Advisor
C.Azure Monitor Metrics
D.Azure Log Analytics
AnswerC

Azure Monitor Metrics is specifically designed to collect numerical data from Azure resources, including virtual machines, at regular intervals. It stores time-series data for key performance counters such as CPU utilization, memory usage, disk I/O, and network traffic. This service provides the necessary infrastructure for storing, visualizing, and alerting on these granular performance metrics, making it the correct and primary tool for monitoring VM CPU and memory usage.

Why this answer

Azure Monitor Metrics is the correct service because it collects and stores numerical performance data (such as CPU and memory utilization) from Azure resources, including VMs, at near-real-time intervals and retains it for up to 93 days. This allows you to query and visualize metrics over the last 30 days using the Azure portal, REST API, or CLI, directly meeting the requirement without additional configuration.

Exam trap

The trap here is that candidates often confuse Azure Monitor Metrics with Azure Log Analytics, mistakenly thinking that all monitoring data must go through Log Analytics, when in fact Metrics is the dedicated service for numerical performance data and provides built-in retention for the required 30-day period without extra setup.

How to eliminate wrong answers

Option A is wrong because Azure Service Health provides information about service-level incidents, planned maintenance, and health advisories affecting Azure services, not granular VM performance metrics like CPU or memory usage. Option B is wrong because Azure Advisor offers personalized recommendations for cost, security, reliability, and performance optimization based on telemetry, but it does not expose raw historical metric data for the last 30 days. Option D is wrong because Azure Log Analytics is designed for collecting and querying log data (e.g., text-based events, custom logs) and requires a diagnostic extension to send VM performance counters; it is not the primary service for out-of-the-box metric retention and visualization.

Practice this question →
69
MCQmedium

You need to diagnose a slow-performing Azure Function. Application Insights shows that the function's dependency calls to an external API take an unusually long time. Which Application Insights feature should you use to visualize the end-to-end request flow?

A.Metrics Explorer
B.Live Metrics Stream
C.Application Map
D.Smart Detection
AnswerC

Application Map in Application Insights is specifically designed to visualize the logical architecture of your application, showing how different components interact and depend on each other. It automatically discovers and maps all application components, including Azure Functions, databases, and external services, displaying the call flow and highlighting performance metrics for each connection. This graphical representation makes it straightforward to identify bottlenecks, slow dependencies, and error rates across the entire distributed system, directly addressing the need to diagnose a slow performing Azure Function by pinpointing the exact problematic dependency.

Why this answer

Application Map is the correct feature because it provides a visual representation of the end-to-end request flow across distributed components, including dependency calls to external APIs. It shows the latency and failure rates for each dependency, allowing you to pinpoint where the slowdown occurs in the overall transaction.

Exam trap

The trap here is that candidates often confuse Live Metrics Stream (real-time monitoring) with Application Map (end-to-end flow visualization), or they think Metrics Explorer can trace individual requests when it only aggregates data over time.

How to eliminate wrong answers

Option A is wrong because Metrics Explorer is used to query and visualize aggregated metrics (e.g., request count, failure rate) over time, not to trace the flow of a single request through dependencies. Option B is wrong because Live Metrics Stream shows real-time telemetry (e.g., incoming requests, CPU usage) but does not provide a historical or dependency-level flow visualization. Option D is wrong because Smart Detection proactively identifies anomalies (e.g., sudden spikes in failures) using machine learning, but it does not offer a manual, interactive map of request paths.

Practice this question →
70
MCQeasy

Your application running on Azure App Service is experiencing intermittent high latency. You have enabled Application Insights and noticed that the 'Server response time' metric spikes during peak hours. What is the most likely cause of this issue?

A.Auto-scaling is configured too aggressively.
B.The application is using regional failover, causing delays.
C.The App Service plan is under-provisioned and hitting CPU limits.
D.The application is using too much memory.
AnswerC

When an App Service plan is under-provisioned, its allocated CPU resources may become fully saturated during periods of high demand, such as peak hours. Hitting CPU limits means the server cannot process new requests immediately, leading to a backlog in the request queue. This directly results in significantly increased application response times and observable latency spikes, as requests must wait for CPU cycles to become available, indicating a need for scaling up or out.

Why this answer

Intermittent high latency during peak hours, reflected in the 'Server response time' metric, typically indicates that the App Service plan is under-provisioned. When CPU usage hits the plan's limits, requests queue up and response times increase. Auto-scaling would mitigate this, but if the plan is under-provisioned (e.g., a B1 plan with limited cores), scaling out may not occur quickly enough or may be disabled, causing CPU saturation and latency spikes.

Exam trap

The trap here is that candidates confuse high memory usage with CPU saturation; memory pressure causes different symptoms (e.g., 500 errors, restarts) while CPU limits directly manifest as increased response times, making option D a distractor.

How to eliminate wrong answers

Option A is wrong because auto-scaling configured too aggressively would actually reduce latency by adding instances preemptively; the issue here is latency spikes, which suggest scaling is insufficient or not triggered. Option B is wrong because regional failover is a disaster recovery mechanism that introduces latency only during failover events, not intermittently during peak hours; it would not cause recurring daily spikes. Option D is wrong because high memory usage typically causes out-of-memory exceptions or application restarts, not directly 'Server response time' latency spikes; CPU saturation is the primary driver of response time degradation.

Practice this question →
71
MCQmedium

An Azure Function processes events from Event Hubs. You need to monitor the number of events that were successfully processed and those that were dropped due to processing errors. Which approach should you use?

A.Custom metrics in Application Insights.
B.Event Hubs metrics.
C.Stream Analytics job.
D.Log Analytics query on function logs.
AnswerA

Custom metrics in Application Insights is the most appropriate solution because it allows developers to instrument their Azure Function code directly. By utilizing the Application Insights SDK, the function can explicitly send numerical data points, such as counts of successfully processed events or dropped events, to Application Insights. This provides real-time, granular visibility into the function's internal processing logic and operational health, enabling effective monitoring and alerting based on actual event outcomes.

Why this answer

Custom metrics in Application Insights allow you to track business-specific counters like successfully processed events and dropped events directly from your Azure Function code. By using the `TelemetryClient.TrackMetric()` API within the function's event processing logic, you can increment counters for success and failure scenarios, giving you precise, real-time monitoring of processing outcomes. This approach is more granular than built-in metrics because it reflects your application's custom error handling, not just infrastructure-level throughput.

Exam trap

The trap here is that candidates confuse infrastructure-level metrics (Event Hubs metrics) with application-level custom metrics, assuming that monitoring the Event Hubs output automatically reflects function processing success, when in fact the function's own error handling must be instrumented separately.

How to eliminate wrong answers

Option B is wrong because Event Hubs metrics (e.g., incoming messages, outgoing messages, throttled requests) measure the throughput at the Event Hubs namespace level, not the success or failure of downstream processing in the Azure Function. Option C is wrong because Stream Analytics is a real-time analytics service for processing streaming data, not a monitoring tool for tracking custom application-level events like processed vs. dropped counts. Option D is wrong because Log Analytics queries on function logs can retrieve logged events, but they require parsing unstructured log text and lack the real-time, aggregated metric capabilities that custom metrics in Application Insights provide for dashboards and alerts.

Practice this question →
72
Multi-Selecthard

Which THREE tools can you use to diagnose performance issues in an Azure App Service? (Choose three.)

Select 3 answers
A.Application Insights
B.App Service diagnostics (Diagnose and Solve Problems)
C.Azure Monitor for VMs
D.Azure SQL Analytics
E.Kudu console for logging and debugging
AnswersA, B, E

Application Insights, a component of Azure Monitor, provides comprehensive Application Performance Management (APM) for live web applications. It automatically collects telemetry data such as request rates, response times, failure rates, and dependency calls, enabling developers to detect and diagnose performance anomalies, exceptions, and bottlenecks within the application code itself. Its distributed tracing capabilities are invaluable for understanding the flow of requests across different services and identifying slow components.

Why this answer

Application Insights is a feature of Azure Monitor that provides application performance management (APM) and telemetry for live web applications. It automatically detects performance anomalies, includes powerful analytics tools to help diagnose issues, and allows you to understand how an app is performing and being used. For an Azure App Service, you can enable Application Insights with just a few clicks to start collecting request rates, response times, failure rates, and dependency tracking.

Exam trap

The trap here is that candidates often confuse Azure Monitor for VMs with the general Azure Monitor platform, mistakenly thinking it applies to all Azure resources, when in fact it is VM-specific and cannot diagnose PaaS-level App Service issues.

Practice this question →
73
MCQeasy

You are using Application Insights to monitor a web application. You need to create an alert that triggers when the server response time exceeds 5 seconds for more than 10% of requests in a 5-minute window. Which type of Azure Monitor alert should you create?

A.Metric alert
B.Log alert
C.Activity log alert
D.Application Insights smart detection alert
AnswerB

Log alerts leverage Kusto Query Language (KQL) to execute custom queries against your Application Insights logs. This powerful capability allows you to filter requests by duration, count them, and then calculate the precise percentage of requests exceeding a specific threshold (e.g., 5000 ms) relative to the total requests within the evaluation period. The alert then triggers when this calculated percentage surpasses the defined custom threshold, making it ideal for complex, ratio-based performance monitoring.

Why this answer

A log alert is correct because the condition involves querying Application Insights trace data to calculate the percentage of requests with a server response time exceeding 5 seconds within a 5-minute window. Log alerts run a Kusto query against the `requests` table, allowing aggregation and threshold evaluation (e.g., >10% of requests), which is not possible with simple metric thresholds.

Exam trap

The trap here is that candidates often assume a metric alert can handle percentage-based conditions, but metric alerts only support simple aggregations (e.g., average, count, max) and cannot compute a ratio of requests meeting a custom condition without a log query.

How to eliminate wrong answers

Option A is wrong because a metric alert can only monitor a single metric value (e.g., average server response time) and cannot calculate a percentage of requests exceeding a threshold; it lacks the query capability to count requests and compute ratios. Option C is wrong because an activity log alert monitors Azure resource management events (e.g., VM creation, configuration changes), not application performance metrics like response times. Option D is wrong because Application Insights smart detection alerts use built-in machine learning models to detect anomalies automatically, but they do not allow you to define custom thresholds like '>10% of requests exceeding 5 seconds'.

Practice this question →
74
MCQeasy

You are monitoring an Azure Web App with Application Insights. You notice a sudden spike in failed requests. You need to quickly identify which specific URL path is causing the most failures. Which blade in the Application Insights portal should you use?

A.Application Map
B.Failures blade
C.Performance blade
D.Live Metrics Stream
AnswerB

The Failures blade in Application Insights is specifically engineered for detailed analysis of failed requests and exceptions within your application. It automatically groups failures by operation name, response code, and URL path, providing metrics like failure count and impact. This functionality allows developers to quickly pinpoint the most problematic endpoints, view associated samples, and drill down into specific error details, making it the ideal tool for identifying the most failing URL path during a historical spike.

Why this answer

The Failures blade in Application Insights is specifically designed to analyze failed requests, including HTTP 4xx and 5xx errors, and provides a breakdown by URL path, response code, and failure count. This allows you to quickly identify the specific URL path causing the most failures, which directly addresses the need to pinpoint the problematic endpoint.

Exam trap

The trap here is that candidates often confuse the Failures blade with the Performance blade, assuming performance metrics (like slow requests) are the root cause of failures, but the question explicitly asks for identifying failed requests by URL path, which is the sole purpose of the Failures blade.

How to eliminate wrong answers

Option A is wrong because the Application Map visualizes the dependency flow and health of your application components, but it does not provide a granular breakdown of failed requests by URL path. Option C is wrong because the Performance blade focuses on request durations, throughput, and slow operations, not on failed request analysis. Option D is wrong because Live Metrics Stream shows real-time telemetry (e.g., request rate, CPU usage) but does not aggregate historical failure data or allow sorting by URL path.

Practice this question →
75
MCQeasy

You are debugging a performance issue in a live web application monitored by Application Insights. You need to see real-time metrics such as request rate, response times, and any exceptions as they occur, without waiting for the usual telemetry pipeline. Which Application Insights feature should you use?

A.Application Insights Analytics (Log Analytics)
B.Live Metrics Stream
C.Metrics Explorer
D.Application Insights Profiler
AnswerB

Live Metrics Stream provides a near real-time, low-latency view of your application's health and performance directly from the running instances. It displays critical metrics like request rates, response times, failures, CPU utilization, and memory usage within seconds of them occurring. This immediate feedback loop is specifically engineered for actively monitoring and debugging live performance issues, allowing developers to observe the impact of changes or identify anomalies instantly.

Why this answer

Live Metrics Stream (option B) is the correct feature because it provides real-time, low-latency telemetry directly from the Application Insights SDK, bypassing the usual ingestion pipeline. This allows you to monitor request rate, response times, and exceptions as they occur, which is exactly what the scenario requires for debugging a live performance issue without waiting for data to be processed.

Exam trap

The trap here is that candidates often confuse Live Metrics Stream with Metrics Explorer, assuming both provide real-time data, but Metrics Explorer relies on pre-aggregated metrics with a built-in delay, while Live Metrics Stream is the only feature designed for true sub-second live monitoring.

How to eliminate wrong answers

Option A is wrong because Application Insights Analytics (Log Analytics) is a query-based tool for analyzing historical telemetry data after it has been ingested and stored, not for real-time monitoring. Option C is wrong because Metrics Explorer displays pre-aggregated metrics with a delay (typically 1-2 minutes) and does not provide sub-second live data. Option D is wrong because Application Insights Profiler is used for tracing performance bottlenecks in specific requests via snapshots, not for continuous real-time monitoring of request rates and exceptions.

Practice this question →
Page 1 of 2 · 102 questions totalNext →

Ready to test yourself?

Try a timed practice session using only Monitor, troubleshoot, and optimize Azure solutions questions.

Start 20-question session