AZ-104 Monitor and Maintain Azure Resources Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  Heartbeat | where Computer == "VM01" | summarize LastHeartbeat = max(TimeGenerated) | where LastHeartbeat > ago(15m)

  Why it's wrong here

  This query finds the most recent heartbeat for VM01 and checks whether it is newer than 15 minutes ago. When VM01 is healthy and sending heartbeats, the comparison returns a row, causing an alert to fire—which means the alert is triggered on normal operation, not on failure. If the VM stops reporting, the last heartbeat becomes older than 15 minutes, the where clause evaluates to false, and the query returns no rows, so the alert stays silent. To detect a missing heartbeat, the comparison must be reversed to where LastHeartbeat < ago(15m) so a stale timestamp yields a row and triggers the alert as intended.

  When this WOULD be correct

  This query would be correct for an alert that fires when VM01 has sent a heartbeat in the last 15 minutes, e.g., 'Alert if VM01 has sent a heartbeat recently' or 'Alert if VM01 is healthy and reporting.'

• ✓

  Heartbeat | where Computer == "VM01" | summarize LastHeartbeat = max(TimeGenerated) | where LastHeartbeat < ago(15m)

  Why this is correct

  This query finds the most recent heartbeat for VM01 and compares it to the 15-minute threshold. If the latest heartbeat is older than that, the query returns a result that can be used to trigger an alert. That directly matches the requirement to detect when the VM has stopped reporting heartbeats.

• ✗

  Heartbeat | where Computer == "VM01" and TimeGenerated > ago(15m) | summarize count() by Computer

  Why it's wrong here

  This query filters for VM01 heartbeats with a TimeGenerated within the last 15 minutes and then summarizes a count. If recent heartbeats exist, it returns a row with a count, which would trigger an alert while the VM is healthy. Conversely, when the VM stops sending heartbeats, the filtered query returns zero rows, and because most log alert rules trigger on returned rows, no alert is generated for the outage. The query never compares the most recent heartbeat timestamp against a staleness threshold, so it cannot detect that the VM has gone silent.

  When this WOULD be correct

  This query would be correct for an alert that fires if VM01 has sent at least one heartbeat in the last 15 minutes (i.e., a heartbeat existence alert).

• ✗

  Heartbeat | where Computer == "VM01" | summarize count() by bin(TimeGenerated, 15m)

  Why it's wrong here

  This query groups all heartbeat records from VM01 into 15-minute time bins without filtering by a recent time range, producing a historical count of events per bucket. It does not compute the latest heartbeat timestamp nor apply a predicate like where LastHeartbeat < ago(15m), so it cannot evaluate whether the current state is stale. Even if the VM has not reported for hours, the most recent time bucket will still contain the count from the last active period, and the query will never indicate that heartbeats are missing. This approach is suitable for trend analysis or capacity planning, not for a real-time availability alert that must trigger on an outdated last heartbeat.

  When this WOULD be correct

  This query would be correct for an alert that fires if VM01 has sent fewer than a certain number of heartbeats in each 15-minute window, e.g., to detect intermittent connectivity.

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.

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