AZ-104 Monitor and Maintain Azure Resources Practice Question
A help desk analyst needs a KQL query that identifies each VM's most recent heartbeat so computers can be flagged if their last check-in is older than 20 minutes. Which two KQL elements should be used? Select two.
⚠ Common exam trap
The trap here is that candidates mistakenly think filtering before summarizing is more efficient, but doing so removes the very data needed to identify the most recent heartbeat, leading to incorrect results.
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
✓
Query the Heartbeat table, because it stores the heartbeat records for Azure VMs.
The Heartbeat table in Azure Monitor Logs (Log Analytics) is specifically designed to store heartbeat records from Azure Monitor Agent (AMA) or the legacy Log Analytics agent. Each heartbeat record contains a TimeGenerated timestamp, making it the authoritative source for determining when a VM last reported its health status.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Query the Heartbeat table, because it stores the heartbeat records for Azure VMs.
Why this is correct
The Heartbeat table is the correct source because the Log Analytics agent emits a Heartbeat record every minute by default, capturing the VM's Computer name, TimeGenerated, and agent health metadata. These records are explicitly designed to indicate that the VM agent is alive and communicating with the workspace, making them the authoritative signal for determining each VM's last check-in time. Without these records, there is no direct way to determine the freshest contact from a VM in Log Analytics.
- ✓
Summarize max(TimeGenerated) by Computer to get the most recent heartbeat per VM.
Why this is correct
Using summarize max(TimeGenerated) by Computer is the standard KQL pattern to collapse the potentially dozens of Heartbeat rows per VM into a single representative row showing the most recent check-in. This aggregation must be performed because Heartbeat returns one record per heartbeat interval, and comparing raw timestamps would require filtering each VM independently. The resulting dataset gives a clean per-machine list suitable for further comparison against a threshold like ago(5m).
- ✗
Join the results to AzureActivity to calculate service health.
Why it's wrong here
AzureActivity is an audit log for control-plane operations such as virtual machine creation, starting, stopping, and resizing—it does not contain any heartbeat or agent-level connectivity timestamps. Joining Heartbeat to AzureActivity would introduce irrelevant events and could cause duplicate rows, yet it would not help calculate service health because service health relies on agent liveness signals, not configuration operations. Therefore, this join adds complexity and noise without contributing any information needed for the query.
When this WOULD be correct
When the question requires correlating VM heartbeat status with Azure service health events, such as identifying VMs that missed heartbeats during a service outage.
- ✗
Filter where TimeGenerated is older than 20 minutes before summarizing.
Why it's wrong here
The filter 'where TimeGenerated older than 20 minutes' is logically backwards: it selects only stale records that are at least 20 minutes old, excluding the fresh heartbeats that the query needs to identify the latest check-in per VM. For example, if a VM checked in 2 minutes ago, it would be removed by this filter, causing the query to report a much older heartbeat time and falsely mark the VM as unavailable. The correct filter would be 'where TimeGenerated > ago(20m)' to focus on recent activity before or after summarization.
When this WOULD be correct
This option would be correct in a question asking: 'Which KQL query element identifies VMs that have not sent a heartbeat in the last 20 minutes?' where you first summarize max(TimeGenerated) by Computer, then filter where max_TimeGenerated is older than 20 minutes.
- ✗
Use the Perf table because it stores heartbeat timestamps.
Why it's wrong here
The Perf table contains sampled performance counters like processor time, available memory, and disk queue length, collected at configurable intervals. While a healthy VM may emit Perf records, these records are not heartbeat check-ins; a VM agent could stop reporting Heartbeat while still producing some performance data, so Perf cannot reliably indicate whether the agent is fully operational. Heartbeat is the dedicated table for that purpose.
When this WOULD be correct
In a scenario where you need to analyze VM performance metrics (e.g., average CPU usage over the last hour) and flag VMs with high resource consumption, querying the Perf table 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.
✓Query the Heartbeat table, because it stores the heartbeat records for Azure VMs.Correct answer▾
Why this is correct
The Heartbeat table is the correct source because the Log Analytics agent emits a Heartbeat record every minute by default, capturing the VM's Computer name, TimeGenerated, and agent health metadata. These records are explicitly designed to indicate that the VM agent is alive and communicating with the workspace, making them the authoritative signal for determining each VM's last check-in time. Without these records, there is no direct way to determine the freshest contact from a VM in Log Analytics.
✗Join the results to AzureActivity to calculate service health.Wrong answer — click to see why▾
Why this is wrong here
Joining to AzureActivity is unnecessary for identifying VMs with heartbeats older than 20 minutes; the Heartbeat table alone provides the required timestamp data.
★ When this WOULD be the correct answer
When the question requires correlating VM heartbeat status with Azure service health events, such as identifying VMs that missed heartbeats during a service outage.
Why candidates choose this
Candidates may think AzureActivity is needed to check service health or correlate with VM status, but the Heartbeat table already contains the necessary check-in timestamps.
✗Filter where TimeGenerated is older than 20 minutes before summarizing.Wrong answer — click to see why▾
Why this is wrong here
Filtering where TimeGenerated is older than 20 minutes before summarizing would exclude recent heartbeats, making it impossible to identify the most recent heartbeat per VM. The correct approach is to summarize first to get the latest timestamp per computer, then filter on that result.
★ When this WOULD be the correct answer
This option would be correct in a question asking: 'Which KQL query element identifies VMs that have not sent a heartbeat in the last 20 minutes?' where you first summarize max(TimeGenerated) by Computer, then filter where max_TimeGenerated is older than 20 minutes.
Why candidates choose this
Candidates may think filtering by time first reduces data volume, but they overlook that this removes the most recent records needed to determine the last check-in time per VM.
✗Use the Perf table because it stores heartbeat timestamps.Wrong answer — click to see why▾
Why this is wrong here
The Perf table stores performance counters (e.g., CPU, memory), not heartbeat timestamps. Heartbeat data is stored in the Heartbeat table, so using Perf would not yield the required heartbeat information.
★ When this WOULD be the correct answer
In a scenario where you need to analyze VM performance metrics (e.g., average CPU usage over the last hour) and flag VMs with high resource consumption, querying the Perf table would be correct.
Why candidates choose this
Candidates may confuse the Perf table with the Heartbeat table, assuming that performance data includes check-in timestamps, or they may think 'heartbeat' is a performance metric.
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
Managed Identities for Azure Resources
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
KQL
Kusto Query Language is a powerful read-only query language used to explore, analyze, and visualize large datasets, most notably in Azure Data Explorer and Microsoft Sentinel.
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.