AZ-104 Monitor and Maintain Azure Resources Practice Question
Exhibit
Alert rule name: CPUSpikeAlert Scope: /subscriptions/11111111-1111-1111-1111-111111111111/resourceGroups/RG-App/providers/Microsoft.Compute/virtualMachines/VM1 Condition: Average Percentage CPU > 80 Window size: 5 minutes Evaluation frequency: 1 minute Action group: Ops-Email Recent alert history: 6 alerts between 23:10 and 23:25 during patching
Based on the exhibit, the operations team says the alert is too noisy because short CPU spikes after nightly maintenance trigger notifications. They want an alert only when VM1's average CPU stays above 80% for at least 10 minutes. What should you change?
⚠ Common exam trap
Candidates often confuse 'window size' with 'evaluation frequency' and think increasing the evaluation frequency alone would solve the noise, but it is the window size that controls the duration over which the metric must remain above the threshold.
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
✓
Increase the window size to 10 minutes and keep the evaluation frequency at 1 minute.
Increasing the window size to 10 minutes while keeping the evaluation frequency at 1 minute means the alert will only fire when the average CPU over the last 10 minutes exceeds 80%. This filters out transient spikes from nightly maintenance, as the alert requires sustained high CPU for the full duration. The evaluation frequency of 1 minute ensures the alert is checked every minute, but the condition is based on the 10-minute rolling average.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Lower the threshold to 70% so the alert becomes less sensitive.
Why it's wrong here
Lowering the threshold to 70% actually makes the alert fire earlier and therefore produce more notifications, because the condition is satisfied by smaller CPU increases. The stated intent to make it 'less sensitive' is inverted; a 70% threshold will be crossed by the same brief maintenance spikes, so noise increases. To reduce sensitivity you would raise the threshold, not lower it.
When this WOULD be correct
In a scenario where the operations team wants earlier warning of potential performance issues and is willing to accept more alerts, lowering the threshold could be correct. For example, if the goal is to detect any CPU usage above 70% to proactively address issues before they reach critical levels.
- ✓
Increase the window size to 10 minutes and keep the evaluation frequency at 1 minute.
Why this is correct
Increasing the window size to 10 minutes while keeping the evaluation frequency at 1 minute causes each evaluation to use a rolling 10-minute average of the CPU percentage. A short maintenance spike is diluted within that longer aggregation window, so the alert will not fire unless the sustained average actually exceeds the threshold. A one-minute check cadence still detects genuine sustained load within at most a couple of minutes after it begins, so you keep responsiveness.
- ✗
Replace the metric alert with a Log Analytics query alert against the activity log.
Why it's wrong here
A Log Analytics query alert against the activity log cannot evaluate virtual machine CPU usage because the activity log only records control-plane operations such as create, delete, and restart. The CPU percentage counter is a platform metric collected by Azure Monitor, so it should be evaluated with a metric alert rule (or, if using Log Analytics, a query against Performance data, not the activity log). Therefore this replacement would completely miss the intended performance condition.
When this WOULD be correct
This option would be correct if the question asked for an alert based on a specific event in the activity log, such as when a VM is started or stopped, and the alert needed to trigger on that event rather than on performance metrics.
- ✗
Move the alert scope from the VM to the resource group.
Why it's wrong here
Moving the alert scope from the VM to the resource group changes which resources are monitored but leaves the threshold and the small evaluation window unchanged. If the rule is applied to the whole resource group, every VM in that group is now evaluated with the same 1-minute window, so transient spikes from any VM can trigger alerts — likely generating even more noise. The fix for short-lived CPU spikes is about the time aggregation, not the target scope.
When this WOULD be correct
If the question required monitoring the average CPU of all VMs in a resource group and alerting when the group-wide average exceeds a threshold, then moving the alert scope to the resource group would be correct.
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.
✓Increase the window size to 10 minutes and keep the evaluation frequency at 1 minute.Correct answer▾
Why this is correct
Increasing the window size to 10 minutes while keeping the evaluation frequency at 1 minute causes each evaluation to use a rolling 10-minute average of the CPU percentage. A short maintenance spike is diluted within that longer aggregation window, so the alert will not fire unless the sustained average actually exceeds the threshold. A one-minute check cadence still detects genuine sustained load within at most a couple of minutes after it begins, so you keep responsiveness.
✗Lower the threshold to 70% so the alert becomes less sensitive.Wrong answer — click to see why▾
Why this is wrong here
Lowering the threshold to 70% would make the alert more sensitive, not less, and does not address the requirement to filter out short spikes by requiring sustained high CPU for 10 minutes.
★ When this WOULD be the correct answer
In a scenario where the operations team wants earlier warning of potential performance issues and is willing to accept more alerts, lowering the threshold could be correct. For example, if the goal is to detect any CPU usage above 70% to proactively address issues before they reach critical levels.
Why candidates choose this
Candidates may mistakenly think that lowering the threshold reduces alert frequency, but in reality it increases sensitivity, leading to more alerts. They might also confuse 'threshold' with 'sensitivity' in a way that seems intuitive but is technically incorrect.
✗Replace the metric alert with a Log Analytics query alert against the activity log.Wrong answer — click to see why▾
Why this is wrong here
The question requires a metric-based alert for CPU spikes, not a Log Analytics query alert. Activity logs track operational events, not performance metrics like CPU usage, so this change would not address the noisy alert issue.
★ When this WOULD be the correct answer
This option would be correct if the question asked for an alert based on a specific event in the activity log, such as when a VM is started or stopped, and the alert needed to trigger on that event rather than on performance metrics.
Why candidates choose this
Candidates may think Log Analytics offers more flexibility for complex conditions, or they confuse activity log alerts with metric alerts, assuming a query can filter CPU data from logs.
✗Move the alert scope from the VM to the resource group.Wrong answer — click to see why▾
Why this is wrong here
Moving the alert scope to the resource group does not address the alert noise from short CPU spikes; it would aggregate metrics across all VMs in the group, potentially increasing noise rather than reducing it.
★ When this WOULD be the correct answer
If the question required monitoring the average CPU of all VMs in a resource group and alerting when the group-wide average exceeds a threshold, then moving the alert scope to the resource group would be correct.
Why candidates choose this
Candidates may think that broadening the scope reduces sensitivity by averaging metrics across multiple resources, but this does not filter out short spikes on a single VM.
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
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.