Design identity, governance, and monitoring solutions →hardMultiple Choice

AZ-305 Practice Question: Design identity, governance, and monitoring solutions

Exhibit

Refer to the exhibit.
```kusto
Heartbeat
| where TimeGenerated > ago(1h)
| summarize LastHeartbeat = max(TimeGenerated) by Computer
| where LastHeartbeat < ago(5m)
```

Refer to the exhibit. You run this Kusto query in Azure Monitor Logs. What does it return?

⚠ Common exam trap

The trap here is that candidates misread the comparison operator: `TimeGenerated < ago(5m)` selects records older than 5 minutes (not newer), leading them to incorrectly think the query returns computers that recently sent a heartbeat.

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

✓

Computers that have not sent a heartbeat in the last 5 minutes.

The query uses the `Heartbeat` table and filters for heartbeats older than 5 minutes (`ago(5m)`). The `where` clause selects records where `TimeGenerated` is less than 5 minutes ago, meaning it finds heartbeats that were sent before that threshold. The `distinct Computer` then returns only computers whose most recent heartbeat is older than 5 minutes, i.e., computers that have not sent a heartbeat in the last 5 minutes. This is a common pattern for detecting unresponsive or offline machines.

Answer analysis

Option-by-option breakdown

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

✗
The number of heartbeats per computer in the last hour.
Why it's wrong here
The query does not count heartbeats; it identifies the latest heartbeat timestamp per computer. The aggregation used is a maximum (e.g., `max(TimeGenerated)` or `arg_max`), not a `count()`. The `where` clause then filters based on that maximum timestamp against `ago(5m)`, so the output is a set of computer names whose newest heartbeat is older than five minutes — it never computes how many heartbeats occurred in the last hour.
✗
Computers that sent a heartbeat in the last 5 minutes.
Why it's wrong here
The filter condition `LastHeartbeat < ago(5m)` selects computers whose most recent heartbeat occurred more than five minutes in the past. A computer that sent a heartbeat within the last five minutes would yield a `LastHeartbeat` value greater than or equal to `ago(5m)` and would be excluded by the filter. Therefore the result is the opposite of 'sent in the last 5 minutes' — it is precisely the set of computers that have not been heard from recently.
✓
Computers that have not sent a heartbeat in the last 5 minutes.
Why this is correct
This is the correct interpretation. The query first obtains each computer's latest heartbeat timestamp (typically via `summarize max(TimeGenerated) by Computer` or `arg_max`), then applies a `where` clause that retains only rows where that latest timestamp is less than `ago(5m)`. Computers that satisfy this predicate have not emitted a heartbeat in the past five minutes, so they are correctly identified as stale or offline.
✗
The average heartbeat frequency per computer.
Why it's wrong here
The query produces a per‑computer maximum timestamp, which is a point in time, not a rate or frequency. Computing heartbeat frequency would require counting heartbeats over a defined interval and dividing by the interval length — for example, using `bin(TimeGenerated, 1m)` to count events per minute or `count() / timespan`. No such time‑based aggregation or rate calculation appears anywhere in the query, so the output cannot express average heartbeat frequency.

Go deeper

AZ-305 Practice Question: Design identity, governance, and monitoring solutions

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question