Design security operations, identity, and compliance capabilities →mediumMultiple Choice

SC-100 Practice Question: Design security operations, identity, and compliance capabilities

Exhibit

SecurityEvent
| where EventID == 4625
| where Account !contains "$"
| summarize FailedLogins = count() by Account, IPAddress, bin(TimeGenerated, 1h)
| where FailedLogins > 10

Refer to the exhibit. A security analyst runs this KQL query in Microsoft Sentinel. What is the primary purpose of this query?

⚠ Common exam trap

Microsoft often tests the distinction between identifying brute-force attempts (failed logins) and confirming successful brute-force attacks (failed logins followed by a successful login), so candidates may incorrectly choose Option B without checking for a successful logon event.

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

✓

Identify accounts that have experienced more than 10 failed login attempts from the same IP address within an hour

The KQL query uses the `summarize` operator to count failed logon events (EventID 4625) grouped by account and IP address, then filters for counts greater than 10 within a 1-hour time window. This directly identifies accounts that have experienced more than 10 failed login attempts from the same IP address within an hour, which is a classic indicator of a brute-force attack targeting a specific account.

Answer analysis

Option-by-option breakdown

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

✓
Identify accounts that have experienced more than 10 failed login attempts from the same IP address within an hour
Why this is correct
This query correctly identifies the specified brute-force pattern: it groups failed sign-in events (e.g., ResultType indicating failure) by user account, source IP address, and a 1-hour time bucket using bin(), then filters for groups where the failure count exceeds 10. That precisely matches 'accounts with more than 10 failed login attempts from the same IP within an hour.' It deliberately ignores successful logons and post-incident account states, which is exactly the described behavior.
✗
Identify IP addresses that have successfully brute-forced an account
Why it's wrong here
The query counts only failed authentication attempts; it never evaluates whether a subsequent sign-in succeeded. To detect a successful brute-force attack, you would need to join these failed attempts to later successful logon events (e.g., ResultType == 0) from the same IP and account to confirm the attacker gained access. Because the query lacks any success criteria and merely tallies failures, it cannot identify accounts that were actually compromised.
✗
Identify users who have logged in from multiple IPs in a short time
Why it's wrong here
The query uses a single IPAddress as a grouping key, so each result is scoped to one IP per account per hour, never to a set of different IPs. Identifying users who logged in from multiple IPs would require summarizing distinct IP addresses per user (e.g., dcount(IPAddress)) and applying a threshold across all IPs, which is a fundamentally different aggregation. Thus, this query cannot reveal multi-IP sign-in behavior.
✗
Identify accounts that have been disabled due to multiple failures
Why it's wrong here
The query inspects only failed sign-in events in SigninLogs; it does not query administrative audit logs or directory management events that indicate an account was disabled. An account can exceed the failure threshold and still remain enabled if no automated disable policy exists, or it can be disabled for unrelated reasons. Therefore, inferring disabled status from this failure count is unsupported by the data the query examines.

Go deeper

SC-100 Practice Question: Design security operations, identity, and compliance capabilities

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question