AZ-104 Monitor and Maintain Azure Resources Practice Question
A production subscription contains 20 virtual machines across two resource groups. Operations needs an email and SMS notification whenever any single VM's average Percentage CPU stays above 85 for 10 minutes. The alert should be managed as one rule, and evaluation must happen independently for each VM. What should the administrator configure?
⚠ Common exam trap
It's easy for candidates to assume a single alert rule cannot monitor multiple VMs independently, leading them to choose option C (subscription-wide average) or option D (diagnostic settings), when in fact Azure Monitor supports multi-resource metric alerts with per-resource evaluation.
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 one metric alert scoped to the 20 VM resources, using Percentage CPU and the shared action group.
A single metric alert rule can be scoped to multiple resources (up to 20 VMs) in Azure Monitor, allowing independent evaluation of each VM's Percentage CPU metric. When the average CPU exceeds 85% for 10 minutes on any individual VM, the alert fires and triggers the shared action group to send email and SMS notifications. This meets the requirement of one rule with per-VM independent evaluation.
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 log query alert that uses the Heartbeat table and the existing action group.
Why it's wrong here
The Heartbeat table in Log Analytics stores agent liveness records, not performance counters. A log query alert against Heartbeat can only detect when a VM stops sending heartbeats (unavailability), so it cannot trigger at a 90% CPU threshold; Percentage CPU is exposed through metrics or the Perf table, not Heartbeat. Thus this option cannot satisfy the alerting requirement.
When this WOULD be correct
This option would be correct if the requirement was to alert when a VM stops sending heartbeat signals (i.e., becomes unavailable) for a specified duration, using a log query alert scoped to the VMs.
- ✓
Create one metric alert scoped to the 20 VM resources, using Percentage CPU and the shared action group.
Why this is correct
A metric alert is the correct signal for CPU threshold monitoring, and scoping the rule to the VM resources lets Azure evaluate each VM independently while keeping a single alert definition. The action group handles the email and SMS delivery. This avoids creating 20 separate rules and prevents fleet-wide averaging from hiding one overloaded server. It is the simplest design that still evaluates each VM separately.
- ✗
Create one subscription-wide metric alert and average CPU across all virtual machines.
Why it's wrong here
A native metric alert scoped to a subscription or resource group evaluates each VM's Percentage CPU individually, but this option explicitly proposes averaging CPU across all 20 VMs. A fleet-wide average dilutes a single overloaded VM: one machine at 99% is hidden when the other 19 are near 5%, so the alert never fires. The correct multi-resource design keeps independent per-VM evaluation, not cross-resource averaging.
When this WOULD be correct
This option would be correct if the requirement was to alert when the average CPU across all VMs in the subscription exceeds 85% for 10 minutes, indicating a fleet-wide performance issue rather than per-VM monitoring.
- ✗
Configure diagnostic settings on each VM and use the action group for threshold processing.
Why it's wrong here
Diagnostic settings are the pipeline that streams a VM's platform metrics and logs to destinations such as a Log Analytics workspace, Event Hub, or storage account; they perform no condition evaluation or threshold processing. An action group is simply a collection of notification channels (email, SMS, webhook) invoked by an alert rule. Without an actual scheduled query rule or metric alert rule that references Percentage CPU, no alert will ever be raised.
When this WOULD be correct
If the question required collecting VM metrics into Log Analytics for historical analysis or custom log-based alerting, configuring diagnostic settings on each VM would be necessary to send metrics to a Log Analytics workspace.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The AZ-104 exam frequently reuses these exact scenarios with slightly different constraints.
✓Create one metric alert scoped to the 20 VM resources, using Percentage CPU and the shared action group.Correct answer▾
Why this is correct
A metric alert is the correct signal for CPU threshold monitoring, and scoping the rule to the VM resources lets Azure evaluate each VM independently while keeping a single alert definition. The action group handles the email and SMS delivery. This avoids creating 20 separate rules and prevents fleet-wide averaging from hiding one overloaded server. It is the simplest design that still evaluates each VM separately.
✗Create a log query alert that uses the Heartbeat table and the existing action group.Wrong answer — click to see why▾
Why this is wrong here
A log query alert using the Heartbeat table cannot measure Percentage CPU; Heartbeat logs only indicate VM availability, not performance metrics like CPU usage.
★ When this WOULD be the correct answer
This option would be correct if the requirement was to alert when a VM stops sending heartbeat signals (i.e., becomes unavailable) for a specified duration, using a log query alert scoped to the VMs.
Why candidates choose this
Candidates may confuse log-based alerts with metric alerts, or mistakenly think Heartbeat logs contain CPU performance data, leading them to choose this option for a CPU alert.
✗Create one subscription-wide metric alert and average CPU across all virtual machines.Wrong answer — click to see why▾
Why this is wrong here
Option C averages CPU across all VMs, but the requirement is for independent evaluation per VM. A subscription-wide metric alert with average aggregation would not trigger individually for each VM exceeding 85%.
★ When this WOULD be the correct answer
This option would be correct if the requirement was to alert when the average CPU across all VMs in the subscription exceeds 85% for 10 minutes, indicating a fleet-wide performance issue rather than per-VM monitoring.
Why candidates choose this
Candidates may think a subscription-wide alert is efficient and covers all VMs, overlooking the need for per-VM independent evaluation. The phrase 'average CPU across all virtual machines' seems like a simple way to monitor overall health.
✗Configure diagnostic settings on each VM and use the action group for threshold processing.Wrong answer — click to see why▾
Why this is wrong here
Diagnostic settings stream metrics to Azure Monitor, but they do not create alerts. Threshold processing and alerting require an alert rule, which is not configured by diagnostic settings alone.
★ When this WOULD be the correct answer
If the question required collecting VM metrics into Log Analytics for historical analysis or custom log-based alerting, configuring diagnostic settings on each VM would be necessary to send metrics to a Log Analytics workspace.
Why candidates choose this
Candidates may confuse diagnostic settings with alert rules, thinking that sending metrics to an action group directly triggers notifications, or they may overcomplicate the solution by assuming metrics must be routed through diagnostic settings before alerting.
Analysis generated from the official AZ-104blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
Go deeper
Related to this question
Learn chapter
Dynamic Membership Groups
Key term
Azure Monitor
Azure Monitor is a cloud service that collects, analyzes, and acts on telemetry data from your Azure and on-premises resources to help you understand performance and availability.
Key term
Metric
A metric is a quantifiable measurement used to assess the performance, health, or status of IT systems, networks, or applications.
About these practice questions
This AZ-104 question is part of Courseiva's 1,049-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 →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This AZ-104 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-104 exam.