AZ-104 Monitor and Maintain Azure Resources Practice Question
A production VM must generate an alert when average CPU exceeds 80 percent for 10 minutes. The alert must be evaluated continuously, but email notifications should be suppressed outside 08:00 to 18:00 on weekdays. What should the administrator configure?
⚠ Common exam trap
Test-takers frequently confuse alert processing rules with action group schedules or diagnostic settings, failing to realize that alert processing rules are the correct mechanism to suppress notifications based on time without altering the alert rule's evaluation frequency.
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
✓
A metric alert rule with an action group and an alert processing rule that suppresses actions outside business hours
It combines a metric alert rule (which continuously evaluates the CPU threshold) with an alert processing rule that suppresses notifications outside business hours. The metric alert rule evaluates every minute by default, meeting the 'continuously evaluated' requirement, while the alert processing rule (formerly action rule) allows you to suppress actions based on a schedule without altering the alert rule itself.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
A log query alert only, with the query scheduled to run during business hours
Why it's wrong here
A log query alert is indeed a valid alert type, but the phrase 'scheduled to run during business hours' means the query is simply not executed outside that time window, so CPU spikes at 2 AM generate no alert entries. Because the alert rule's evaluation clock is gated by the schedule, you lose detection for the other 16 hours a day — which fails any requirement that production VMs be continuously monitored. Moreover, metric data first has to flow into a Log Analytics workspace (if you're using custom logs) which introduces ingestion latency, making this less precise than a native metric alert that evaluates against the original time series.
When this WOULD be correct
If the question required alerting based on a complex KQL query (e.g., joining multiple tables or calculating custom metrics) and the evaluation frequency could be scheduled (e.g., every 5 minutes), then a log query alert would be appropriate. For example: 'Alert when average CPU exceeds 80% over the last 10 minutes, evaluated every 5 minutes.'
- ✓
A metric alert rule with an action group and an alert processing rule that suppresses actions outside business hours
Why this is correct
A metric alert rule natively evaluates the host's average CPU every minute using a stateless threshold check, so it detects sustained load 24x7 even if you're not watching. To avoid knocking people at night for off-hours spikes, you add an alert processing rule (suppression effect) scoped to that action group; the rule can be configured with a recurrence for business hours so notifications are muted only then, while the underlying alert still fires and appears in the Azure Portal/API. This gives continuous monitoring with silent nights, which is exactly the requirement.
- ✗
A diagnostic setting that sends CPU logs to a storage account and a Logic App for email delivery
Why it's wrong here
Diagnostic settings only stream Azure platform metrics (including Percentage CPU) to a Storage Account, Event Hub, or Log Analytics workspace; they do not contain any logic to compare values against thresholds or raise an alert. To get email from a Logic App, you'd need custom code to poll the blob storage, deserialize the metrics, calculate averages, and send an email — this adds significant latency, requires manual handling of truncation and time windows, and misses the native support in Azure Monitor for stateful alerting, action groups, and processing rules. Therefore it's an indirect, brittle pipeline, not a threshold-based monitoring solution.
When this WOULD be correct
A question requiring long-term historical analysis of CPU usage for compliance or capacity planning, where the alert is not time-sensitive and can tolerate delays, and where email delivery is needed only during specific hours via a Logic App.
- ✗
An action group with an email receiver and a virtual machine extension to pause the workload outside business hours
Why it's wrong here
This design mistakes a mitigation action for a notification-suppression mechanism. A VM extension that pauses the workload will stop the application or shut down the VM outside business hours, causing downtime and potentially breaking availability health checks — it does not suppress notifications or control alerting behavior. Additionally, an action group with only an email receiver is inert unless it is attached to a scoped alert rule; without a metric/log alert rule there is nothing to trigger the email, so the combination never generates the required alert. The correct approach is to keep the alert active and let an alert processing rule suppress actions during off-hours.
When this WOULD be correct
Option D would be correct in a scenario where the requirement is to automatically shut down or pause a non-production VM during off-hours to save costs, and an action group is used to notify administrators of the shutdown. For example: 'A development VM must be automatically stopped outside business hours and send an email notification when stopped.'
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.
✓A metric alert rule with an action group and an alert processing rule that suppresses actions outside business hoursCorrect answer▾
Why this is correct
A metric alert rule natively evaluates the host's average CPU every minute using a stateless threshold check, so it detects sustained load 24x7 even if you're not watching. To avoid knocking people at night for off-hours spikes, you add an alert processing rule (suppression effect) scoped to that action group; the rule can be configured with a recurrence for business hours so notifications are muted only then, while the underlying alert still fires and appears in the Azure Portal/API. This gives continuous monitoring with silent nights, which is exactly the requirement.
✗A log query alert only, with the query scheduled to run during business hoursWrong answer — click to see why▾
Why this is wrong here
A log query alert runs on a schedule (e.g., every 5 minutes) and evaluates historical data, not continuously. The requirement for continuous evaluation (real-time) is better met by a metric alert, which monitors metrics in near real-time.
★ When this WOULD be the correct answer
If the question required alerting based on a complex KQL query (e.g., joining multiple tables or calculating custom metrics) and the evaluation frequency could be scheduled (e.g., every 5 minutes), then a log query alert would be appropriate. For example: 'Alert when average CPU exceeds 80% over the last 10 minutes, evaluated every 5 minutes.'
Why candidates choose this
Candidates may think that scheduling the query to run only during business hours achieves the suppression requirement, but this fails the continuous evaluation requirement and does not properly suppress notifications outside hours.
✗A diagnostic setting that sends CPU logs to a storage account and a Logic App for email deliveryWrong answer — click to see why▾
Why this is wrong here
This option does not meet the requirement for continuous evaluation of CPU metrics; it relies on logs sent to a storage account, which introduces latency and does not support real-time metric alerting. Additionally, it lacks a mechanism to suppress notifications outside business hours.
★ When this WOULD be the correct answer
A question requiring long-term historical analysis of CPU usage for compliance or capacity planning, where the alert is not time-sensitive and can tolerate delays, and where email delivery is needed only during specific hours via a Logic App.
Why candidates choose this
Candidates may think that sending logs to a storage account and using a Logic App provides flexibility for custom processing and scheduling, but they overlook that metric alerts are simpler and more appropriate for real-time threshold monitoring.
✗An action group with an email receiver and a virtual machine extension to pause the workload outside business hoursWrong answer — click to see why▾
Why this is wrong here
Option D is wrong because it suggests pausing the workload outside business hours, which is not required by the question. The requirement is to suppress email notifications, not to alter VM operation. Additionally, using a VM extension to pause workloads is an overly complex and inappropriate solution for notification suppression.
★ When this WOULD be the correct answer
Option D would be correct in a scenario where the requirement is to automatically shut down or pause a non-production VM during off-hours to save costs, and an action group is used to notify administrators of the shutdown. For example: 'A development VM must be automatically stopped outside business hours and send an email notification when stopped.'
Why candidates choose this
Candidates may choose D because they think suppressing notifications requires modifying the VM's behavior, or they confuse the need to suppress actions with the need to stop the workload itself. The mention of 'pause the workload' might seem like a direct way to avoid high CPU alerts outside hours.
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
Azure Alerts and Action Groups
Key term
Metric
A metric is a quantifiable measurement used to assess the performance, health, or status of IT systems, networks, or applications.
Key term
Alert rule
An alert rule is a set of conditions and actions that trigger a notification when a monitored metric or log reaches a predefined threshold.
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 →
Same concept, more angles
1 more way this is tested on AZ-104
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A team already has a metric alert on a production VM. The alert should continue evaluating 24/7, but email notifications must be sent only Monday through Friday from 08:00 to 18:00 local time. What should the administrator add or change?
hard- A.Replace the metric alert with a diagnostic setting and store the data in Log Analytics.
- ✓ B.Create an alert processing rule that suppresses notifications outside business hours.
- C.Lower the alert threshold so fewer alerts occur during the week.
- D.Use an autoscale profile instead of an alert rule.
Why B: An alert processing rule (formerly action rule) can suppress notifications for a metric alert based on a schedule. By creating a rule with a suppression action that applies outside business hours (e.g., 18:00 to 08:00 and weekends), the alert continues to evaluate and fire, but email notifications are blocked during those times. This meets the requirement without altering the alert rule itself.
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.