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.

• ✓

  where

  Why this is correct

  The `where` operator in Kusto Query Language (KQL) filters a tabular input based on a boolean predicate, returning only rows for which the expression evaluates to true. In a heartbeat query, this is the primary way to restrict results to a relevant time window or status, such as `where TimeGenerated > ago(30m)` or `where Computer == "webserver1"`. Unlike operators that transform or aggregate data, `where` preserves the original columns and row structure, making it the correct choice when you need to retrieve actual heartbeat record details rather than summaries.

• ✓

  ago()

  Why this is correct

  The `ago()` function is a KQL scalar function that returns a datetime value representing the current UTC time minus a specified timespan, for example `ago(30m)` yields the timestamp 30 minutes before the query execution. It is not a tabular operator itself, but rather a time-boundary generator commonly used inside a `where` clause to create a sliding window filter: `where TimeGenerated > ago(15m)`. This function is essential for queries that must find recent heartbeats because it dynamically calculates the cutoff time relative to 'now', ensuring the filter stays current without hardcoding a fixed timestamp.

• ✗

  summarize

  Why it's wrong here

  The `summarize` operator groups rows and aggregates them into a new table using functions like `count()`, `max()`, or `avg()`, which inherently reduces the result set to one row per group and loses the individual heartbeat records. For a task asking to 'find heartbeat records', summing or grouping would defeat the purpose because you need the raw rows, not aggregate statistics. Even if you used `summarize` to compute the last heartbeat per computer (e.g., `summarize max(TimeGenerated) by Computer`), you would still first need a `where` filter to constrain to recent records; otherwise, you scan all historical data and return a summary rather than the actual heartbeat entries.

  When this WOULD be correct

  A question that asks: 'Which KQL element should be used to count the number of heartbeat records per hour for the last 24 hours?' In that case, summarize with bin(TimeGenerated, 1h) would be correct to group and count records.

• ✗

  join

  Why it's wrong here

  The `join` operator combines rows from two different tables by matching values on one or more key columns, producing a new table with columns from both sources. In a basic heartbeat query, there is no second table to bring in, and joining adds unnecessary complexity and performance overhead without helping to filter recent records. To find heartbeats logged within a time range, you only need to filter the existing heartbeat table using `where` on the `TimeGenerated` column; introducing a join would require an additional data source and a join condition, which is irrelevant to the core task.

  When this WOULD be correct

  A question asks: 'You need to combine heartbeat records from two different Azure VMs into a single result set based on a common field like ResourceId.' In that case, 'join' would be correct.

• ✗

  extend

  Why it's wrong here

  The `extend` operator in KQL adds a new calculated column (or modifies an existing one) to every row in a table, but it does not remove or exclude any rows from the result set. For example, `extend Minute = datetime_part("minute", TimeGenerated)` would append a column showing the minute of each heartbeat, yet all rows—including both old and new—remain present. Since the task is to identify recent heartbeats, the essential operation is row filtering, not column creation. `extend` could be useful after a `where` filter to shape output, but it cannot itself restrict records by time or status, making it an incorrect standalone choice.

  When this WOULD be correct

  When you need to add a new column to query results, such as calculating uptime from heartbeat timestamps, 'extend' is correct. For example: 'Heartbeat | extend Uptime = now() - TimeGenerated'.

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