Courseiva

AZ-204 Practice Question: Monitor, troubleshoot, and optimize Azure solutions

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.)

⚠ Common exam trap

Many exam-takers 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.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Create a metric alert rule that triggers when average CPU exceeds 90% over 5 minutes.

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.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • ✓

    Create a metric alert rule that triggers when average CPU exceeds 90% over 5 minutes.

    Why this is correct

    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.

  • ✗

    Scale up the App Service plan to a higher tier to ensure sufficient resources.

    Why it's wrong here

    Scaling up an App Service plan to a higher tier permanently allocates more CPU, memory, and other resources to the web app. While this might temporarily alleviate high CPU issues, it is a static, manual intervention that leads to increased costs even during periods of low demand. It does not provide dynamic resource adjustment based on actual load fluctuations, making it an inefficient and unsustainable solution for variable workloads.

  • ✓

    Create a Log Analytics workspace and configure diagnostic settings to send platform logs.

    Why this is correct

    A Log Analytics workspace serves as a centralized repository for collecting various types of operational data, including platform logs from Azure App Services. Configuring diagnostic settings to send these logs (e.g., App Service HTTP logs, App Service console logs, metrics) enables detailed analysis of application behavior, resource consumption, and potential errors that contribute to high CPU usage. This is fundamental for effective troubleshooting and understanding the root cause of performance issues.

  • ✗

    Enable Application Insights and configure autoscale based on custom metrics.

    Why it's wrong here

    Application Insights is a powerful Application Performance Management (APM) service that provides deep insights into application code, dependencies, and user experience. While it can collect custom metrics, directly configuring autoscale rules based on *custom metrics* from Application Insights is more complex and often less direct than using built-in platform metrics like CPU percentage. Its primary strength lies in diagnosing application-level performance bottlenecks, not as the primary mechanism for infrastructure autoscaling.

  • ✗

    Create an autoscale rule for the App Service plan to scale out when CPU > 80%.

    Why it's wrong here

    An autoscale rule dynamically adjusts the number of instances (scale out) or the size of instances (scale up/down) for an App Service plan based on predefined metrics and thresholds. By configuring a rule to scale out when CPU usage exceeds 80%, the system automatically adds more instances to distribute the load, effectively mitigating high CPU pressure and maintaining application responsiveness. This proactive approach ensures optimal resource utilization and consistent performance during fluctuating demand.

Go deeper

Related to this question

About these practice questions

This AZ-204 question is part of Courseiva's 883-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This AZ-204 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-204 exam.