Respond to security incidents →easyMultiple Choice

SC-200 Respond to security incidents Practice Question

Exhibit

Refer to the exhibit.
```kql
// KQL query in Microsoft Sentinel
let TimeRange = 1h;
IdentityLogonEvents
| where Timestamp > ago(TimeRange)
| where Application == "Microsoft Entra ID"
| summarize LogonAttempts = count() by UserPrincipalName, IPAddress, ResultType
| where ResultType == "Failed"
| where LogonAttempts > 5
```

Refer to the exhibit. The KQL query runs in Microsoft Sentinel and returns no results. The analyst expects to see failed logon attempts. What is the most likely reason?

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

✓

The ResultType field does not exist in IdentityLogonEvents.

The query filters on ResultType == 'Failed', but the field is likely named 'Result' or uses different values like 'Failure'. Also, the table 'IdentityLogonEvents' may not exist; it might be 'AADSignInEventsBeta' or similar. But the most common issue is incorrect field name for result type.

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 Application filter is incorrect.
Why it's wrong here
The Application filter is not the cause of the empty result because `Application` is a legitimate column in the `IdentityLogonEvents` table, and `"Microsoft Entra ID"` is a standard value that appears in that column. Any failed logon events originating from Microsoft Entra ID would satisfy this filter and be returned, so the filter would not suppress valid rows. Therefore, the issue is not the application name but rather an invalid field referenced elsewhere in the query, such as `ResultType`, which does not exist in this table.
✓
The ResultType field does not exist in IdentityLogonEvents.
Why this is correct
The `IdentityLogonEvents` table, which aggregates logon activities primarily from Microsoft Entra ID, does not utilise a field named `ResultType` for indicating logon outcomes. Instead, this table typically uses `LogonResult` (e.g., "Success", "Failed") or `ActionType` to categorise events. Consequently, filtering on a non-existent `ResultType` field will cause the KQL query to return no results, even if numerous failed logon attempts are present within the `IdentityLogonEvents` data.
✗
The summarize operator is misused.
Why it's wrong here
The `summarize` operator is not misused; its syntax is correct for grouping and counting rows by the specified dimensions, and it does not filter or discard any records that reach it. Even if the grouping keys were suboptimal, the operator would still produce a row for each unique combination of values passed from the preceding `where` clause. Since the query returns no rows at all, the problem lies upstream—specifically in the `where` clause, which filters out all events because it references the non-existent `ResultType` field, leaving the `summarize` operator nothing to aggregate.
✗
The TimeRange variable is too short.
Why it's wrong here
The TimeRange variable is not too short; a one-hour window is a reasonable and common timeframe for detecting recent failed logon attempts, and any such events occurring within that period would be included in the query results. Extending the time range would not change the outcome because the query's filter conditions, particularly the invalid reference to `ResultType`, prevent any rows from being selected regardless of the time span. Thus, the time range is not the underlying issue; the query fails due to a schema mismatch, not a lack of data in the specified window.

Go deeper

SC-200 Respond to security incidents Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question