Courseiva

CCNA Monitor Troubleshoot And Optimize Azure Solutions Questions

30 of 105 questions · Page 2/2 · Monitor Troubleshoot And Optimize Azure Solutions topic · Answers revealed

Practice these questionsExam hubAll questions
76
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 →
77
MCQmedium

An Azure App Service application has memory pressure. The developer needs distributed tracing across requests and dependencies. What should be enabled?

A.Application Insights with dependency tracking
B.Azure Policy compliance scan
C.Cost Management budgets only
D.Storage account static website logs
AnswerA

Application Insights provides request, dependency, exception, and trace telemetry for application diagnostics.

Why this answer

Application Insights with dependency tracking enables distributed tracing by automatically collecting telemetry across HTTP requests, database calls, and external service dependencies. This allows developers to correlate end-to-end transactions and identify the root cause of memory pressure, such as a specific dependency causing excessive resource consumption.

Exam trap

The trap here is that candidates may confuse Azure Policy (governance) or Cost Management (budgeting) with monitoring tools, or think static website logs can trace application dependencies, when only Application Insights provides the necessary distributed tracing and dependency correlation.

How to eliminate wrong answers

Option B is wrong because Azure Policy compliance scans enforce governance rules on resources (e.g., tagging or location restrictions) and do not provide any tracing or monitoring of application-level requests or dependencies. Option C is wrong because Cost Management budgets only track and alert on spending; they have no capability to trace distributed requests or diagnose memory pressure. Option D is wrong because Storage account static website logs capture only HTTP access logs for static content hosted in Azure Storage, not the distributed tracing of an App Service application's requests and dependencies.

Practice this question →
78
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 →
79
MCQmedium

You have an Azure CDN profile that caches content from a storage account. Users in Europe report that images load slowly. You need to improve performance for European users. What should you do?

A.Enable compression on the CDN
B.Enable prefetching on the CDN
C.Configure caching rules to cache longer
D.Add an additional CDN endpoint with a European origin
AnswerD

Adding an additional CDN endpoint with an origin server physically located in Europe is the most direct and effective method to reduce geographic latency for users in that region. This strategy ensures that content is served from a data center much closer to European users, minimizing the physical distance data must travel between the client, the CDN edge node, and the origin, thereby directly addressing and significantly reducing the round-trip time and overall latency.

Why this answer

Adding an additional CDN endpoint with a European origin (e.g., an Azure Storage account in a European region) reduces latency by serving content from a geographically closer point of presence (PoP). Azure CDN uses a global network of edge servers, but if the origin server is far from the users, the first-hop latency from the edge to the origin can still be high. By placing an origin in Europe, the CDN can fetch content from a nearby origin, minimizing the distance data must travel and improving load times for European users.

Exam trap

The trap here is that candidates often assume caching or compression alone can solve geographic latency, but the real bottleneck is the origin's physical distance from the users, which requires a geographically closer origin to minimize first-hop latency.

How to eliminate wrong answers

Option A is wrong because enabling compression reduces the size of the transferred data but does not address the root cause of high latency due to geographic distance between the origin and European users. Option B is wrong because prefetching (pre-loading content to the edge) can improve cache hit ratios but does not reduce the latency of the initial fetch from a distant origin; it only helps if content is already cached. Option C is wrong because configuring caching rules to cache longer increases the time content stays in the edge cache, but if the cache is cold or content is not popular, European users still experience slow first-time loads due to the distant origin.

Practice this question →
80
MCQmedium

A high-traffic API sends approximately 80,000 telemetry events per second to Application Insights. Monthly ingestion costs are too high. The team wants to reduce data volume by roughly 80 percent while still seeing representative samples of all request types. What should the developer configure?

A.Enable adaptive sampling in the Application Insights SDK and set a target events-per-second limit
B.Configure ingestion sampling in the Azure portal to retain 20 percent of incoming telemetry
C.Increase the TelemetryClient flush interval from 30 seconds to 5 minutes to batch events
D.Filter all events with HTTP status code 200 from the telemetry pipeline before sending
AnswerA

Adaptive sampling runs in the SDK. It monitors the outgoing telemetry rate and automatically raises or lowers the sample percentage to stay near the target rate. All operation types are sampled proportionally, so statistical trends remain meaningful even at 20 percent of raw volume. Data is reduced before transmission, lowering both network and ingestion costs.

Why this answer

Adaptive sampling in the Application Insights SDK automatically adjusts the volume of telemetry sent to the service, targeting a specified rate of events per second. By setting a target that reduces the original 80,000 events/sec to roughly 20%, the SDK will intelligently sample all request types proportionally, preserving representative data while cutting costs.

Exam trap

The trap here is that candidates confuse ingestion sampling (a portal-level fixed filter) with adaptive sampling (an SDK-level dynamic filter), assuming any sampling in the portal will suffice, but only adaptive sampling can meet the dual goals of volume reduction and representativeness across all request types.

How to eliminate wrong answers

Option B is wrong because ingestion sampling in the Azure portal is a fixed-rate filter applied after telemetry is already sent, which does not reduce network and SDK overhead, and it cannot adapt to traffic spikes or maintain representativeness across all request types. Option C is wrong because increasing the flush interval only batches events into larger payloads, reducing the number of HTTP calls but not the total number of events ingested, so it does not reduce data volume or cost. Option D is wrong because filtering all HTTP 200 status codes would discard successful requests entirely, losing critical health and performance data and violating the requirement to see representative samples of all request types.

Practice this question →
81
MCQmedium

An Azure App Service application has availability failures. The developer needs distributed tracing across requests and dependencies. What should be enabled?

A.Application Insights with dependency tracking
B.Storage account static website logs
C.Azure Policy compliance scan
D.Cost Management budgets only
AnswerA

Application Insights automatically collects telemetry including requests, exceptions, and traces for live applications. Its dependency tracking feature is crucial for diagnosing availability failures in an Azure App Service because it visualizes calls to external services like databases, other APIs, or storage accounts. This allows developers to pinpoint if a slowdown or failure originates within the App Service itself or from an unresponsive downstream dependency, providing a clear path to resolution and improving overall application reliability.

Why this answer

Application Insights with dependency tracking is the correct choice because it provides distributed tracing across requests and dependencies in an Azure App Service application. It automatically collects telemetry data, including end-to-end transaction details, and maps dependencies like SQL databases, HTTP calls, and Azure services, enabling developers to diagnose availability failures by correlating traces across components.

Exam trap

The trap here is that candidates may confuse general monitoring tools (like logs or compliance) with the specific need for distributed tracing, overlooking that only Application Insights with dependency tracking provides the correlation and dependency mapping required for diagnosing availability failures across requests and dependencies.

How to eliminate wrong answers

Option B is wrong because Storage account static website logs only capture HTTP request logs for static content hosted in Azure Storage, not distributed tracing across application dependencies or requests. Option C is wrong because Azure Policy compliance scan evaluates resource configurations against policies for governance and compliance, not for monitoring application performance or tracing distributed requests. Option D is wrong because Cost Management budgets only track and alert on spending, providing no telemetry or tracing capabilities for application availability or dependencies.

Practice this question →
82
MCQeasy

You need to monitor the CPU utilization of an Azure VM in real-time and set up an alert when it exceeds 90%. Which Azure Monitor feature should you use?

A.Log Analytics Workspace
B.Metrics Explorer
C.Application Insights
D.Azure Monitor for VMs
AnswerB

Metrics Explorer, an integral part of Azure Monitor, is the dedicated tool for visualizing and analyzing platform metrics emitted by Azure resources, including VM CPU utilization. It provides near real-time data with minimal latency, enabling users to interactively chart metrics, apply aggregations, and directly create metric alerts based on specific thresholds. This capability directly addresses the requirement for real-time monitoring and setting alerts on VM CPU utilization with high responsiveness.

Why this answer

Metrics Explorer is the correct Azure Monitor feature for real-time monitoring of CPU utilization on an Azure VM because it provides near real-time metric collection (typically every 1 minute) and supports alerting based on threshold conditions. It allows you to chart performance counters like Percentage CPU and configure metric alerts that trigger when the value exceeds 90%.

Exam trap

The trap here is that candidates often confuse Azure Monitor for VMs (which provides a dashboard view) with the actual alerting mechanism, or they mistakenly think Log Analytics is needed for metric alerts when Metrics Explorer handles them directly.

How to eliminate wrong answers

Option A is wrong because Log Analytics Workspace is designed for collecting and querying log data (e.g., Windows Event Logs, Syslog) using KQL, not for real-time metric monitoring or threshold-based alerts on CPU utilization. Option C is wrong because Application Insights is an Application Performance Management (APM) service focused on monitoring live web applications, not infrastructure-level metrics like VM CPU utilization. Option D is wrong because Azure Monitor for VMs (now VM Insights) provides a pre-built experience with performance charts and dependency mapping, but it relies on underlying Metrics Explorer for alerting and is not the direct feature for setting a metric alert on CPU utilization.

Practice this question →
83
Multi-Selecteasy

Which TWO actions can help you reduce latency for a globally distributed web application? (Choose two.)

Select 2 answers
A.Use Azure Application Gateway with Web Application Firewall
B.Scale up the App Service plan to a higher tier
C.Use Azure Traffic Manager with performance routing
D.Enable multi-region writes on Azure Cosmos DB
E.Use Azure Front Door to route traffic to the nearest region
AnswersC, E

Azure Traffic Manager is a DNS-based traffic load balancer that distributes incoming user requests across multiple Azure regions or external endpoints. When configured with performance routing, it intelligently directs users to the endpoint with the lowest latency, typically by resolving the DNS query to the closest available Azure region based on the user's DNS resolver location. This approach effectively minimizes the network round-trip time for users accessing a globally distributed application, significantly reducing perceived latency.

Why this answer

Azure Traffic Manager with performance routing directs user traffic to the closest endpoint based on the lowest network latency, reducing response times for globally distributed users. Option E is correct because Azure Front Door uses anycast and global edge points of presence (PoPs) to route traffic to the nearest region, providing both latency reduction and application acceleration.

Exam trap

The trap here is that candidates confuse regional services like Application Gateway with global traffic management solutions, or mistakenly think scaling up or multi-region writes alone reduce latency without a routing mechanism.

Practice this question →
84
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 reduces telemetry volume while preserving representative diagnostic data.

Why this answer

Adaptive sampling in Application Insights automatically reduces the volume of telemetry data sent from high-traffic apps by intelligently selecting a representative subset of events. This preserves statistical utility for analysis while significantly lowering ingestion costs, making it the ideal solution for the described scenario.

Exam trap

The trap here is that candidates may confuse sampling with other cost-reduction methods like scaling up or disabling telemetry, not realizing that adaptive sampling is the only option that balances cost reduction with statistical validity.

How to eliminate wrong answers

Option A is wrong because moving to a larger App Service plan increases compute resources but does not reduce telemetry volume or ingestion costs; it may even increase costs. Option C is wrong because disabling all exception telemetry would eliminate critical diagnostic data, undermining the team's need for statistically useful telemetry. Option D is wrong because increasing log verbosity to debug would dramatically increase telemetry volume, worsening the ingestion cost problem.

Practice this question →
85
MCQeasy

You are monitoring an Azure web application with Application Insights. You notice a sudden increase in the number of failed requests. You want to be notified automatically when such anomalies occur, without manually setting static thresholds. Which Application Insights feature should you use?

A.Create a metric alert on the 'failed requests' metric with a static threshold.
B.Enable Smart Detection for failure anomalies.
C.Use Log Analytics to run a query every 5 minutes and trigger an action.
D.Create an availability test that periodically pings the application.
AnswerB

Enabling Smart Detection for failure anomalies is the most effective solution as it leverages machine learning to automatically analyze application telemetry and establish dynamic baselines for normal behavior. It proactively identifies sudden, statistically significant deviations from these baselines, such as an unexpected spike in failed requests, without requiring manual configuration of thresholds. This intelligent analysis provides timely and relevant alerts, minimizing alert fatigue and focusing on true operational issues.

Why this answer

Smart Detection for failure anomalies in Application Insights uses machine learning to automatically detect unusual patterns in failed request rates without requiring manual threshold configuration. This feature is specifically designed to notify you of anomalies based on historical behavior, making it the correct choice for the scenario described.

Exam trap

The trap here is that candidates often confuse metric alerts with static thresholds as the only way to get notified, overlooking the machine learning-based Smart Detection feature that is purpose-built for anomaly detection without manual thresholds.

How to eliminate wrong answers

Option A is wrong because creating a metric alert with a static threshold requires manual configuration and does not adapt to changing traffic patterns, which contradicts the requirement to avoid setting static thresholds. Option C is wrong because using Log Analytics to run a query every 5 minutes is a custom, manual approach that lacks the built-in anomaly detection capabilities of Smart Detection and requires additional setup for scheduling and action groups. Option D is wrong because an availability test periodically pings the application to check endpoint availability, not to detect anomalies in failed request rates; it is designed for availability monitoring, not for analyzing historical failure patterns.

Practice this question →
86
MCQmedium

Your Azure Logic Apps workflow fails intermittently with timeout errors. What should you do to improve reliability?

A.Configure retry policies for failed actions
B.Increase the action timeout to maximum
C.Reduce the number of parallel branches
D.Use Azure API Management in front of Logic Apps
AnswerA

Configuring retry policies directly addresses intermittent timeouts by instructing the Logic App to automatically re-attempt failed actions after a specified delay. This mechanism is crucial for handling transient faults, such as temporary network issues or service unavailability, without requiring manual intervention. Logic Apps offer built-in retry policies like default, exponential interval, and fixed interval, allowing developers to tailor the retry behavior to the specific characteristics of the external service or API being called, significantly enhancing workflow reliability.

Why this answer

Intermittent timeout errors in Azure Logic Apps indicate that some actions are taking longer than the default timeout to complete. Configuring retry policies for failed actions allows the workflow to automatically reattempt the operation, which can resolve transient failures due to network congestion or temporary service unavailability. This directly improves reliability by handling intermittent timeouts without manual intervention.

Exam trap

The trap here is that candidates often confuse increasing the timeout as a reliability fix, when in fact it only postpones the failure, whereas retry policies actively handle transient errors by reattempting the operation.

How to eliminate wrong answers

Option B is wrong because increasing the action timeout to its maximum (e.g., 120 seconds for HTTP actions) only delays the failure; it does not address the root cause of intermittent timeouts and can lead to longer workflow execution times. Option C is wrong because reducing the number of parallel branches may decrease concurrency but does not prevent individual actions from timing out; it can even reduce throughput without resolving timeout issues. Option D is wrong because Azure API Management is a gateway for managing APIs, not a tool for handling timeout errors within Logic Apps; it adds latency and complexity without fixing action-level timeouts.

Practice this question →
87
MCQmedium

An e-commerce application emits a high volume of telemetry data to Azure Application Insights. You need to reduce the cost of data ingestion while preserving statistical accuracy for performance metrics. Which sampling technique should you use?

A.Adaptive sampling
B.Fixed-rate sampling with a 1% rate
C.Ingestion sampling
D.Head-based sampling
AnswerA

Adaptive sampling in Application Insights automatically adjusts the sampling rate based on the volume of telemetry and a target maximum data ingestion rate. This dynamic adjustment ensures that a representative sample of data is collected during both low and high traffic periods, preventing excessive costs while maintaining sufficient data for accurate diagnostics and performance analysis. It intelligently reduces the sampling rate during spikes and increases it during lulls to meet the configured daily cap, preserving statistical validity.

Why this answer

Adaptive sampling is the correct choice because it automatically adjusts the sampling rate based on the volume of telemetry data, ensuring that during low-traffic periods all data is retained for statistical accuracy, while during high-traffic periods it reduces the rate to control costs. This technique is specifically designed for high-volume scenarios like e-commerce telemetry, where preserving statistical accuracy for performance metrics (e.g., request durations, failure rates) is critical, and it avoids the manual tuning required by fixed-rate sampling.

Exam trap

The trap here is that candidates often confuse adaptive sampling with fixed-rate sampling, assuming a constant low rate (like 1%) is always cheaper, but they miss that adaptive sampling preserves accuracy by retaining all data during low-volume periods and only reduces during spikes.

How to eliminate wrong answers

Option B is wrong because fixed-rate sampling with a 1% rate applies a constant sampling percentage regardless of traffic volume, which can lead to under-sampling during low-traffic periods (losing statistical accuracy) or over-sampling during high-traffic periods (not reducing costs effectively). Option C is wrong because ingestion sampling occurs at the Application Insights ingestion endpoint after telemetry is sent, meaning you still pay for the data transmitted to the endpoint, and it does not reduce network bandwidth or SDK-side processing costs. Option D is wrong because head-based sampling (e.g., fixed-rate sampling at the SDK level) samples telemetry before any processing, which can break end-to-end transaction correlation if not all components use the same sampling rate, and it does not adapt to changing traffic patterns.

Practice this question →
88
MCQhard

You need to reduce costs for an Azure Functions app that runs intermittently. The current Consumption plan bills for execution time. Which change would be MOST cost-effective?

A.Switch to Premium plan with pre-warmed instances
B.Migrate to Flex Consumption plan with higher memory
C.Use an App Service plan with Always On
D.Deploy to Azure Container Instances
AnswerB

Migrating to an Azure Functions Flex Consumption plan with higher memory is an effective strategy for cost reduction. This plan offers a consumption-based model with more granular control over resource allocation, allowing you to optimize memory for specific function needs. By providing sufficient memory, execution times can be significantly reduced, directly lowering the billed duration and overall cost, especially for memory-intensive or CPU-bound functions, while maintaining serverless benefits.

Why this answer

The Flex Consumption plan allows you to configure per-instance memory and concurrency settings, which can reduce costs for intermittent workloads by optimizing resource usage. Unlike the standard Consumption plan, Flex Consumption lets you set higher memory limits without paying for idle time, making it more cost-effective for functions that run sporadically but require more memory when active.

Exam trap

The trap here is that candidates often assume higher memory always increases cost, but in Flex Consumption, higher memory can reduce execution time and overall cost for intermittent workloads, while options like Premium or App Service plans introduce fixed costs that are wasteful for sporadic usage.

How to eliminate wrong answers

Option A is wrong because the Premium plan with pre-warmed instances incurs higher baseline costs due to reserved instances and always-on features, which are not cost-effective for intermittent workloads. Option C is wrong because an App Service plan with Always On keeps the app continuously running, leading to constant billing even when functions are idle, increasing costs. Option D is wrong because Azure Container Instances bill per second of container runtime and require manual scaling or orchestration, which adds complexity and cost for intermittent function execution without the serverless benefits of Azure Functions.

Practice this question →
89
MCQmedium

Refer to the exhibit. You run this KQL query in Azure Monitor Logs. What does the timechart display?

A.Multiple lines, one for each result code, showing request count over time
B.A single line of total requests over time
C.Total requests per 5 minutes
D.Requests grouped by result code only
AnswerA

The `summarize count() by bin(timestamp, 5m), resultCode` clause explicitly groups the request counts by both 5-minute time intervals and distinct `resultCode` values. Consequently, the `render timechart` operator will generate a separate line for each unique `resultCode` encountered within the dataset, plotting its count over the binned time periods. This provides a clear visualization of how the volume of requests for each specific result code changes over time.

Why this answer

The KQL query uses `summarize count() by ResultCode, bin(TimeGenerated, 5m)` which groups requests by both `ResultCode` and 5-minute time bins. When rendered with `render timechart`, each distinct `ResultCode` value produces a separate series (line) on the chart, showing the request count over time for that result code. This is why multiple lines appear, one per result code.

Exam trap

The trap here is that candidates often overlook the `by ResultCode` clause and assume the query simply counts all requests over time, leading them to choose a single-line option (B or C) instead of recognizing that each distinct result code generates its own series.

How to eliminate wrong answers

Option B is wrong because the query does not summarize total requests; it groups by `ResultCode`, so the timechart shows separate lines per result code, not a single aggregated line. Option C is wrong because while the query bins time into 5-minute intervals, the timechart displays multiple lines (one per result code) rather than a single line of total requests per 5 minutes. Option D is wrong because the query includes a time bin (`bin(TimeGenerated, 5m)`) and renders a timechart, which shows trends over time, not just a static grouping by result code.

Practice this question →
90
MCQmedium

You manage a web application hosted on Azure App Service. You need to monitor the application's availability from multiple geographic locations. The test should check that the homepage loads successfully and returns HTTP 200 within 5 seconds. You want to receive an alert if the test fails from any location. Which type of Application Insights test should you create?

A.Multi-step web test
B.URL ping test
C.Custom availability test using TrackAvailability
D.Continuous export test
AnswerB

A URL ping test, provided by Azure Monitor Application Insights, is specifically designed to check the availability and responsiveness of a single URL from multiple global points of presence. It periodically sends a simple GET request to the specified endpoint, monitoring HTTP response codes, DNS resolution, SSL handshake, and overall response time. This perfectly matches the requirement for a simple, external availability check with alerting capabilities.

Why this answer

The URL ping test is the correct choice because it is a simple, single-URL availability test that checks whether a specific endpoint (the homepage) returns HTTP 200 within a specified timeout (5 seconds). It can be configured to run from multiple geographic locations and trigger an alert on failure, meeting all requirements without the complexity of multi-step or custom code.

Exam trap

The trap here is that candidates often confuse the URL ping test with the multi-step web test, assuming that any availability check requires a multi-step test, but the URL ping test is specifically designed for single-URL validation with geographic distribution and alerting.

How to eliminate wrong answers

Option A is wrong because a multi-step web test is designed to validate a sequence of user actions (e.g., login, navigate, submit) across multiple URLs, which is overkill and unnecessary for a simple homepage load check. Option C is wrong because TrackAvailability is a custom method used in code to report availability results manually, requiring you to write and deploy custom application logic, which is not needed for a basic HTTP 200 check. Option D is wrong because continuous export is a feature for exporting Application Insights telemetry data to storage or Event Hubs, not a mechanism for creating or running availability tests.

Practice this question →
91
MCQeasy

You have enabled Application Insights on your Azure Web App. You notice that some server-side exceptions are not appearing in the Application Insights portal. What is the most likely reason?

A.The Application Insights SDK is not installed in the application
B.The developer forgot to set the Instrumentation Key in the application configuration
C.The web app is running on a Free tier App Service plan
D.The exceptions are being caught and handled in code without being re-thrown or explicitly logged
AnswerD

Application Insights' automatic exception tracking primarily captures unhandled exceptions that propagate up the call stack and cause the application to crash or terminate a request. When exceptions are caught within `try-catch` blocks and handled gracefully without being re-thrown or explicitly logged using `telemetryClient.TrackException()`, Application Insights does not automatically detect them. Developers must explicitly log these handled exceptions to ensure they appear in the telemetry.

Why this answer

Application Insights only captures exceptions that are unhandled or explicitly logged via the SDK. If an exception is caught in a try-catch block and not re-thrown or logged using `TelemetryClient.TrackException()`, it will not appear in the portal. This is a common oversight when developers handle exceptions silently without instrumentation.

Exam trap

The trap here is that candidates assume enabling Application Insights on the Azure portal automatically captures all exceptions, but in reality, caught exceptions require explicit logging via the SDK.

How to eliminate wrong answers

Option A is wrong because the question states that Application Insights is enabled on the Azure Web App, which implies the SDK is installed (e.g., via the App Insights extension or auto-instrumentation). Option B is wrong because if the Instrumentation Key were missing, no telemetry at all would appear, not just missing server-side exceptions. Option C is wrong because the Free tier App Service plan does not prevent exception telemetry from being sent; it only limits compute resources and does not affect Application Insights data collection.

Practice this question →
92
MCQeasy

You need to monitor the performance of an Azure web app. You want to track the average response time and the number of failed requests over the last hour. Which Azure service should you use?

A.Application Insights
B.Azure Monitor
C.Log Analytics
D.Azure Advisor
AnswerA

Application Insights is the correct choice as it provides comprehensive Application Performance Management (APM) capabilities specifically designed for monitoring live web applications. It automatically instruments your application to collect detailed telemetry, including request response times, failure rates, dependency performance, and exceptions. This service offers deep insights into application health and user experience, enabling proactive identification and diagnosis of performance bottlenecks.

Why this answer

Application Insights is the correct choice because it is an extensible Application Performance Management (APM) service designed specifically for monitoring live web applications. It can track metrics like average response time and failed request counts out of the box, and it integrates directly with Azure Web Apps via the Application Insights SDK or auto-instrumentation, providing real-time telemetry without requiring custom logging code.

Exam trap

The trap here is that candidates often confuse Azure Monitor (the umbrella service) with Application Insights, assuming Azure Monitor alone can track application-level metrics like response time, when in fact it requires Application Insights for that granular, code-level telemetry.

How to eliminate wrong answers

Option B (Azure Monitor) is wrong because while it collects and stores platform-level metrics and logs (e.g., CPU, memory), it does not natively capture application-level metrics like average response time or failed request counts without additional configuration or integration with Application Insights. Option C (Log Analytics) is wrong because it is a query and analysis tool for log data stored in Log Analytics workspaces, not a real-time application performance monitoring service; it lacks built-in application telemetry collection. Option D (Azure Advisor) is wrong because it is a personalized cloud consultant that provides best practice recommendations for cost, security, reliability, and performance, but it does not collect or display live application performance metrics such as response time or failure counts.

Practice this question →
93
MCQmedium

Users of a web application hosted on App Service are randomly signed out when the app is scaled out to three instances. Investigation shows that session data stored in in-process memory is not available when subsequent requests hit a different instance. What is the recommended solution?

A.Store session data in Azure Cache for Redis and configure all App Service instances to connect to the same Redis endpoint
B.Enable ARR affinity (sticky sessions) on the App Service to route each user's requests to the same instance
C.Write session data to Azure Blob Storage as a JSON file keyed by session ID on every request
D.Store session state in a Cosmos DB container with a TTL equal to the session timeout
AnswerA

Redis acts as a shared external session store. Each instance serializes the session to Redis on write and deserializes it on read. Because all instances point to the same Redis instance, any instance can serve any user's requests correctly, making the session store horizontally scalable and instance-independent.

Why this answer

When an App Service scales out to multiple instances, in-process session state is stored locally on each instance and is not shared. Azure Cache for Redis provides a centralized, in-memory data store that all instances can access, ensuring session data is available regardless of which instance handles a request. This is the recommended pattern for distributed session state in Azure.

Exam trap

The trap here is that candidates often confuse ARR affinity (sticky sessions) as a complete solution, not realizing it only masks the problem by pinning users to instances, but fails to provide resilience against instance failures or scaling operations.

How to eliminate wrong answers

Option B is wrong because enabling ARR affinity (sticky sessions) only routes requests from the same user to the same instance, but it does not solve the underlying problem of session data loss if that instance fails or is recycled, and it can lead to uneven load distribution. Option C is wrong because writing session data to Azure Blob Storage on every request introduces high latency and is not designed for low-latency, high-frequency session reads/writes; it is a file storage service, not a session store. Option D is wrong because Cosmos DB is a NoSQL database with higher latency and cost compared to Redis for session state, and its TTL feature is for document expiration, not for efficient session management; it is overkill and not the recommended solution for this scenario.

Practice this question →
94
MCQmedium

You are developing a solution that uses Azure Functions with a consumption plan. The function processes messages from an Azure Service Bus queue. During a load test, you notice that the function takes a long time to start processing messages after a period of inactivity. What is the most likely cause of this cold start delay?

A.The function is using a consumption plan, which may scale to zero instances.
B.The function timeout is set too low.
C.The function is using a premium plan with pre-warmed instances.
D.The Service Bus namespace is using the Premium tier.
AnswerA

This is the correct answer. Azure Functions running on a Consumption plan are dynamically allocated and deallocated based on demand. When no requests are received for a period, the function app may scale down to zero instances. The subsequent first request after this inactivity requires the Azure Functions host to provision new compute resources, load the function code, and initialize the runtime environment, leading to a noticeable delay known as a cold start.

Why this answer

The cold start delay occurs because the consumption plan scales the function app to zero instances after a period of inactivity. When a new message arrives, Azure Functions must allocate a new instance, load the function code, and initialize the runtime, which introduces latency. This is a well-known characteristic of the consumption plan's scale-to-zero behavior.

Exam trap

The trap here is that candidates may confuse function timeout settings with cold start latency, or incorrectly assume that Service Bus tier affects function startup behavior.

How to eliminate wrong answers

Option B is wrong because the function timeout setting controls the maximum execution duration for a single invocation, not the startup latency after inactivity. Option C is wrong because a premium plan with pre-warmed instances eliminates cold starts by keeping instances running, which would reduce rather than cause the delay. Option D is wrong because the Service Bus namespace tier (Premium) affects throughput and features, not the cold start behavior of the function app.

Practice this question →
95
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? The design must avoid adding custom operational scripts.

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 is an intelligent, automatic feature within the Application Insights SDK that dynamically adjusts the rate at which telemetry items are collected and sent to the service. It works by discarding a percentage of telemetry items (like requests, dependencies, and traces) at the client-side before they are transmitted, ensuring that a representative sample is retained while significantly reducing the overall data volume. This direct reduction in ingested data volume is highly effective in lowering Application Insights costs, as billing is primarily based on the amount of data ingested.

Why this answer

Adaptive sampling is the correct solution because it automatically adjusts the volume of telemetry data collected from your application, ensuring that only a representative fraction of events is sent to Application Insights while preserving statistical accuracy for analysis. This reduces ingestion costs without requiring custom scripts or manual intervention, as it is a built-in feature of the Application Insights SDK that dynamically adapts based on traffic patterns.

Exam trap

The trap here is that candidates often confuse scaling (Option A) with cost optimization, or they mistakenly believe that disabling all telemetry (Option C) is a valid cost-saving measure, when in fact adaptive sampling provides a balanced approach that maintains data utility without manual overhead.

How to eliminate wrong answers

Option A is wrong because moving to a larger App Service plan increases compute resources but does not reduce telemetry volume or ingestion costs; it only addresses performance scaling, not data management. Option C is wrong because disabling all exception telemetry would eliminate critical diagnostic data needed for monitoring application health, potentially masking issues and violating the requirement for statistically useful telemetry. 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 →
96
Multi-Selecthard

A production API needs proactive alerting for unexpected exceptions. 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.An action group for notification or automation
C.A public IP address on the app
D.A manually exported CSV report
AnswersA, B

To establish proactive alerting, an Azure Monitor alert rule must be configured with a specific signal, such as a metric (e.g., CPU utilization, HTTP error rate) or a log query (e.g., KQL query detecting specific error messages). This signal acts as the data source, and the alert condition defines the threshold or pattern that, when met, indicates an unexpected situation requiring attention. Without a defined signal and condition, there is no mechanism to detect the problem.

Why this answer

A is correct because an Azure Monitor alert requires a signal (such as a metric, log query, or activity log event) to define the condition that triggers the alert. Without a signal, the alert has no basis for evaluation, making it impossible to detect unexpected exceptions proactively.

Exam trap

The trap here is that candidates may think a public IP or exported report is needed for monitoring, but Azure Monitor alerts only require a signal and an action group, not network-level or manual data exports.

Practice this question →
97
MCQmedium

An Azure App Service application has slow API requests. The developer needs distributed tracing across requests and dependencies. What should be enabled?

A.Azure Policy compliance scan
B.Application Insights with dependency tracking
C.Storage account static website logs
D.Cost Management budgets only
AnswerB

Application Insights is an Application Performance Management (APM) service specifically designed to monitor live web applications and collect detailed telemetry. Its dependency tracking feature automatically captures data on all outgoing calls made by the application to external services, including databases, other APIs, and HTTP endpoints, providing crucial insights into their duration and success. This comprehensive telemetry is vital for identifying which specific external calls are contributing to slow API requests in an Azure App Service application.

Why this answer

Application Insights with dependency tracking is the correct choice because it provides distributed tracing across requests and dependencies, enabling developers to correlate end-to-end transactions in a microservices or multi-component application. It automatically collects telemetry for HTTP calls, database queries, and other external service calls, which is essential for diagnosing slow API requests in an Azure App Service environment.

Exam trap

The trap here is that candidates may confuse Azure Policy or storage logs with monitoring tools, but only Application Insights provides the distributed tracing and dependency correlation needed for diagnosing slow API requests across multiple components.

How to eliminate wrong answers

Option A is wrong because Azure Policy compliance scan enforces organizational rules and governance on Azure resources, but it does not collect runtime telemetry or trace requests across dependencies. Option C is wrong because Storage account static website logs capture HTTP access logs for static content hosted in blob storage, not distributed tracing for dynamic API requests in App Service. Option D is wrong because Cost Management budgets only track and alert on spending, providing no insight into application performance or dependency call chains.

Practice this question →
98
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?

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 telemetry that can be queried with KQL in Logs.

Why this answer

Application Insights stores application request data, including latency metrics, and supports Kusto queries via its Logs blade. The associated Log Analytics workspace also provides the same query capabilities, making it the correct location to run a Kusto query for 95th percentile latency by operation.

Exam trap

The trap here is that candidates may confuse Azure Resource Graph with Log Analytics, but Resource Graph only queries Azure resource properties and configurations, not application telemetry data.

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 performance logs, not application request metrics. Option D is wrong because Azure Resource Graph is designed for resource inventory and configuration queries across subscriptions, not for querying application telemetry like request latency.

Practice this question →
99
MCQhard

You have an Azure App Service web app that experiences intermittent slowness. You enable Application Insights and notice that the "Failed Requests" metric is low, but "Server Response Time" is high for a subset of requests. You want to identify the specific code path causing the delay. Which feature should you use?

A.Live Metrics.
B.Snapshot Debugger.
C.Profiler.
D.Availability tests.
AnswerC

Application Insights Profiler continuously collects performance traces from your live Azure App Service application, even when it's under load. It automatically identifies the "hot paths" in your code that consume the most time during web requests, database calls, or other operations. By visualizing the call stack and execution times for individual requests, the Profiler helps pinpoint the exact methods responsible for application slowness, enabling targeted optimization.

Why this answer

C is correct because the Application Insights Profiler captures detailed call stacks and execution timing for slow requests, allowing you to pinpoint the exact code path causing high server response time. Unlike other features, Profiler is specifically designed for performance troubleshooting by tracing request execution at the code level.

Exam trap

The trap here is confusing the Profiler (for performance diagnostics) with the Snapshot Debugger (for exception debugging), leading candidates to choose Snapshot Debugger when the question explicitly asks about identifying the cause of high response times, not failures.

How to eliminate wrong answers

Option A is wrong because Live Metrics provides real-time monitoring of metrics like request rate and response times but does not capture detailed code-level call stacks to identify the specific slow code path. Option B is wrong because Snapshot Debugger is designed to capture debug snapshots on exceptions, not for analyzing slow response times; it helps diagnose crashes, not performance bottlenecks. Option D is wrong because Availability tests monitor the endpoint's availability and responsiveness from external locations, but they do not provide code-level profiling to identify the internal code path causing delays.

Practice this question →
100
MCQhard

You are monitoring an Azure App Service using Application Insights. You notice that HTTP 500 errors are increasing, but the standard server response time metric remains normal. You suspect that the errors are occurring in an external API call made by the application. How can you identify the dependency that is failing?

A.Enable snapshot debugging for the application.
B.Use Application Insights Profiler to capture code-level traces.
C.Configure Application Insights dependency tracking and view the Dependency Metrics blade.
D.Set up a custom event telemetry for each external call.
AnswerC

Configuring Application Insights dependency tracking automatically instruments and records calls made by your application to external services, such as databases, HTTP endpoints, and message queues. The Dependency Metrics blade then aggregates this telemetry, providing a comprehensive view of success rates, average durations, and counts of failed requests for each unique dependency. This built-in functionality offers the most efficient and accurate way to identify and monitor external service failures.

Why this answer

Application Insights dependency tracking automatically monitors HTTP calls, SQL queries, and other external dependencies made by your application. By viewing the Dependency Metrics blade, you can see failure rates, durations, and dependency names, allowing you to identify which external API call is failing without modifying code.

Exam trap

The trap here is that candidates may confuse dependency tracking with custom event telemetry or think that snapshot debugging or profiling can identify external API failures, but only dependency tracking provides automatic, aggregated metrics for outbound calls.

How to eliminate wrong answers

Option A is wrong because snapshot debugging captures the state of the application when exceptions occur, but it does not provide aggregated metrics or dependency-specific failure data; it is for debugging individual exceptions, not for identifying failing dependencies. Option B is wrong because Application Insights Profiler captures code-level traces and performance bottlenecks within your application's own code, not external API calls; it focuses on CPU time and request processing, not dependency failures. Option D is wrong because setting up custom event telemetry for each external call would require manual instrumentation and code changes, whereas dependency tracking is automatic and provides built-in metrics; custom events add overhead and are not necessary when dependency tracking is available.

Practice this question →
101
MCQmedium

You are monitoring an Azure web application with Application Insights. You need to identify the top 5 slowest API endpoints over the last 7 days. The results should show the endpoint URL, average response time, and request count. Which feature or query should you use?

A.Use Log Analytics and run a query on the 'requests' table to aggregate by URL and sort by avg(duration).
B.Use the 'Performance' blade under 'Investigate' in the Application Insights resource.
C.Use the 'Application Map' feature to visualize dependencies and endpoints.
D.Configure Smart Detection to automatically identify slow API endpoints.
AnswerB

The Performance blade within Application Insights is purpose-built to identify and analyze slow operations and dependencies. It automatically aggregates request telemetry, displaying a ranked list of operations (e.g., web requests, API calls) by their average duration, total duration, and request count. This provides an immediate, visual overview of performance bottlenecks, allowing users to quickly drill down into specific slow requests for detailed transaction diagnostics without writing any queries.

Why this answer

The 'Performance' blade in Application Insights provides a pre-built, optimized view that automatically aggregates request data by endpoint URL, displaying average response time and request count. It allows you to sort by average duration to quickly identify the top 5 slowest API endpoints over the last 7 days without writing any custom query.

Exam trap

The trap here is that candidates often assume Log Analytics is always the best tool for any custom aggregation, overlooking that Application Insights provides purpose-built blades (like Performance) that offer the same functionality with zero query effort and faster results.

How to eliminate wrong answers

Option A is wrong because while Log Analytics can query the 'requests' table, it requires writing a Kusto query manually (e.g., 'requests | summarize avg(duration) by url | top 5 by avg_duration desc'), which is more complex and time-consuming than using the built-in Performance blade. Option C is wrong because the Application Map visualizes dependencies and call flows between components, not aggregated performance metrics like average response time and request count for endpoints. Option D is wrong because Smart Detection is an automated alerting feature that proactively identifies anomalies (e.g., sudden degradation), not a tool for manually querying historical top-N slowest endpoints over a fixed period.

Practice this question →
102
MCQmedium

You are monitoring an Azure Web App with Application Insights. You notice that certain requests have high server response times. You need to identify which specific database queries are causing the delays. Which Application Insights feature should you use?

A.Application Insights Profiler
B.Live Metrics Stream
C.Performance blade
D.Application Map
AnswerA

Application Insights Profiler is the correct tool because it captures detailed execution traces of requests, providing a granular view of method calls and dependency durations. It specifically instruments code paths to show the exact time spent in each operation, including the duration of individual database queries and even the specific SQL commands executed, making it ideal for pinpointing performance bottlenecks at the query level.

Why this answer

Application Insights Profiler is the correct feature because it provides detailed, code-level diagnostics for requests with high server response times, including per-operation breakdowns of database query durations. It captures execution traces that show exactly which SQL queries or external calls are contributing to latency, enabling you to pinpoint the specific database queries causing delays.

Exam trap

The trap here is that candidates often confuse the Performance blade (which shows aggregated dependency durations) with the Profiler (which provides per-request, code-level traces), leading them to choose the Performance blade when they need to identify specific slow queries rather than overall trends.

How to eliminate wrong answers

Option B (Live Metrics Stream) is wrong because it shows real-time metrics like request rate and failure counts but does not provide per-query profiling or detailed database query timings. Option C (Performance blade) is wrong because it aggregates performance data (e.g., average response times, dependency durations) but lacks the granular, per-request trace-level detail needed to identify specific slow queries. Option D (Application Map) is wrong because it visualizes the topology and dependencies of your application components but does not drill into individual query execution times or provide profiling data.

Practice this question →
103
Multi-Selectmedium

Which TWO actions should you take to reduce the cost of an Azure App Service plan that is underutilized?

Select 2 answers
A.Deploy the application to a different region
B.Enable auto-scaling
C.Purchase Reserved Instances
D.Scale out to fewer instances
E.Scale down the App Service plan to a lower tier
AnswersD, E

"Scaling out" refers to adjusting the number of instances running within an App Service plan. If an application is underutilized, it means it has more instances than required to handle its current workload efficiently. Reducing the instance count directly decreases the total computational resources consumed by the application, as each instance incurs a cost. This action directly lowers the operational expenditure for the App Service plan by aligning the provisioned capacity more closely with the actual demand.

Why this answer

Scaling out to fewer instances directly reduces the number of VMs running the App Service plan, which lowers the compute cost. Since the plan is underutilized, fewer instances can handle the existing load without performance degradation, making this a cost-optimization action.

Exam trap

The trap here is that candidates confuse scaling out (adding instances) with scaling down (reducing tier), or think auto-scaling always saves money, when in fact it can increase costs if the base load is already low.

Practice this question →
104
MCQmedium

After deploying a new version to the staging slot and swapping to production, users report a 60-second spike in 503 errors. The application takes 45 seconds to initialize its connection pools and caches before it can serve traffic. What is the root cause, and what should the developer configure to prevent this?

A.Configure Application Initialization in the App Service settings so the swap waits for the warm-up path to return 200 before redirecting production traffic
B.Roll back the slot swap and investigate the new version for bugs that only appear in production
C.Increase the App Service health check grace period so the load balancer waits longer after the swap
D.Disable Always On for the staging slot so the slot starts fresh on every swap
AnswerA

Application Initialization instructs the App Service platform to send a warm-up request to a configured URL path after the slot starts and before the swap completes. The platform holds traffic on the old slot until the warm-up succeeds. This makes swaps zero-downtime even for applications with long initialization times.

Why this answer

The root cause is that the swap operation immediately redirects production traffic to the new slot before the application has finished its 45-second initialization (connection pools, caches). Application Initialization (warm-up) in Azure App Service can be configured to send a request to a specified path and wait for a 200 response before completing the swap, ensuring the app is ready to serve traffic. This eliminates the 503 errors by preventing the swap from routing users to an uninitialized instance.

Exam trap

The trap here is that candidates confuse the health check feature (which monitors instance health after traffic is routed) with Application Initialization (which delays the swap until the app is ready), leading them to incorrectly choose Option C.

How to eliminate wrong answers

Option B is wrong because the issue is not a bug in the new version—the application initializes successfully after 45 seconds, and the 503 errors only occur during the swap window, indicating a warm-up timing problem, not a code defect. Option C is wrong because the health check grace period controls how long the load balancer waits before marking an instance as unhealthy after a failed health check; it does not delay the swap itself or wait for the app to initialize before routing traffic. Option D is wrong because disabling Always On would cause the staging slot to cold-start on every swap, which would actually increase initialization time and worsen the 503 spike, not prevent it.

Practice this question →
105
MCQmedium

You are developing a web app that experiences intermittent slow responses. You enable Application Insights and notice that the server-side request duration is normally under 200ms, but some requests take over 5 seconds. Which diagnostic tool should you use to identify the root cause?

A.Availability Tests
B.Application Insights Profiler
C.Snapshot Debugger
D.Live Metrics Stream
AnswerB

Application Insights Profiler is the correct tool because it automatically collects detailed performance traces from your live application, even during intermittent slowdowns. It captures call stacks and execution times for requests, identifying the specific code paths, methods, and dependencies (like database calls or external HTTP requests) that consume the most time or block execution. This allows developers to pinpoint the exact source of intermittent performance bottlenecks at a code level.

Why this answer

The Application Insights Profiler is the correct tool because it provides a flame chart of per-request CPU and wall-clock time, allowing you to identify which code path is causing the 5-second latency. Unlike other tools, the Profiler captures detailed execution traces for slow requests, pinpointing the exact method or dependency that is blocking the thread.

Exam trap

The trap here is that candidates confuse the Profiler (for performance bottlenecks) with the Snapshot Debugger (for exception debugging), because both involve code-level diagnostics, but they serve different triggers—duration vs. exception.

How to eliminate wrong answers

Option A is wrong because Availability Tests measure endpoint uptime and response from external locations, not internal server-side code execution. Option C is wrong because Snapshot Debugger captures state on exceptions, not on slow requests without errors. Option D is wrong because Live Metrics Stream shows real-time aggregated metrics (e.g., request rate, failure count) but does not provide per-request call stack or method-level timing data.

Practice this question →
← PreviousPage 2 of 2 · 105 questions total

Ready to test yourself?

Try a timed practice session using only Monitor Troubleshoot And Optimize Azure Solutions questions.

Start 20-question session