Secure Azure using Microsoft Defender for Cloud and Microsoft Sentinel →mediumMultiple Choice

AZ-500 Practice Question: Secure Azure using Microsoft Defender for Cloud and Microsoft Sentinel

Exhibit

SigninLogs
| where TimeGenerated > ago(1d)
| summarize Attempts = count() by IPAddress
| where Attempts > 10

Refer to the exhibit. You are analyzing a KQL query in Microsoft Sentinel. The query returns a list of IP addresses that have attempted to sign in more than 10 times in the last day. You notice that the query does not filter out successful sign-ins. You need to modify the query to count only failed sign-in attempts. What should you add?

⚠ Common exam trap

Many exam-takers confuse the field names (e.g., 'Status' or 'Result') or mistakenly filter for 'ResultType == "0"' (success) instead of 'ResultType != "0"' (failure), because the question explicitly asks to count only failed attempts.

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

✓

Add '| where ResultType != "0"' before the summarize

In Microsoft Sentinel, the KQL query for sign-in logs uses the 'ResultType' field to indicate success or failure. A 'ResultType' of '0' represents a successful sign-in, while any non-zero value indicates a failure. Therefore, to count only failed sign-in attempts, you must filter with '| where ResultType != "0"' before the summarize operator. Option D correctly applies this filter, excluding successful sign-ins and ensuring the count reflects only failures.

Answer analysis

Option-by-option breakdown

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

✗
Add '| where Status == "Failure"' before the summarize
Why it's wrong here
SigninLogs does not expose a column named `Status`; the outcome is stored in the numeric `ResultType` column, where 0 denotes success and any nonzero value denotes a failed sign-in. Referencing a nonexistent column causes the query to fail with a semantic error before any filtering can occur. The correct predicate must target `ResultType` and exclude the success value.
✗
Add '| where Result == "Failure"' before the summarize
Why it's wrong here
There is no `Result` column in SigninLogs, and a string value like `Failure` cannot represent the numeric ResultType codes that Kusto stores for each authentication attempt. Successful sign-ins are recorded as 0, while failures map to specific non-zero codes such as 50057 or 50126, so no `Failure` literal exists in the data. Using this predicate would either error or return no rows instead of isolating failed sign-ins.
✗
Add '| where ResultType == "0"' before the summarize
Why it's wrong here
Filtering with `ResultType == '0'` does exactly the opposite of what is needed: it keeps only successful sign-ins because SigninLogs records a successful authentication as ResultType 0. This predicate strips away every failure from the event stream before the summarize step, so the resulting time-series would count only healthy logins. The correct condition must reject the success code rather than accept it.
✓
Add '| where ResultType != "0"' before the summarize
Why this is correct
Placing `ResultType != '0'` before the summarize filters the stream down to failed authentication attempts, because every successful sign-in shares ResultType 0 and every non-zero code represents a specific failure condition. Kusto evaluates row filters before aggregations, so the subsequent summarize counts only the intended failure events and produces the required hourly failure trend. This predicate also avoids the non-existent columns and string labels used in the incorrect options.

Go deeper

AZ-500 Practice Question: Secure Azure using Microsoft Defender for Cloud and Microsoft Sentinel

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question