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

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

Exhibit

KQL query:
```kusto
let threshold = 5;
SigninLogs
| where TimeGenerated >= ago(1h)
| where ResultType == "50057"
| summarize Count = count() by UserPrincipalName, IPAddress
| where Count > threshold
```

Refer to the exhibit. A security analyst runs this KQL query in Microsoft Sentinel. The query returns a list of users and IP addresses with failed sign-ins due to 'User Account Disabled' (ResultType 50057). The analyst wants to create a scheduled analytics rule that generates an incident when a user exceeds 5 such failures from the same IP in an hour. Which setting is missing from the query to meet the requirement?

⚠ Common exam trap

Microsoft often tests the candidate's understanding that time-based analytics rules require explicit time-windowing in the query (via bin or bin_at) rather than relying on the rule's run frequency or lookback period alone.

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 a 'bin' or 'bin_at' to group by time windows.

The query currently returns all failed sign-ins due to 'User Account Disabled' but does not aggregate them into time-based windows. To meet the requirement of generating an incident when a user exceeds 5 failures from the same IP in an hour, the query must group the results into 1-hour time buckets using 'bin' or 'bin_at' on the timestamp column, then count the failures per user and IP per bucket, and filter for counts greater than 5. Without this time-windowing, the query cannot enforce the 'in an hour' condition.

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 a 'let' statement to define the threshold.
Why it's wrong here
A let statement merely assigns a reusable variable, and the threshold is already hard-coded in the query's where clause. Moving a literal into a let does not alter the evaluation scope or fix the aggregation granularity. The real defect is that the count() is computed over the entire 1-hour lookback, so re-declaring the threshold is cosmetic, not corrective.
✗
Add a 'project' to select columns.
Why it's wrong here
Project controls column selection and output shape, which is purely cosmetic for incident generation because the detection logic only requires the aggregation result. Omitting project does not change how count() is bucketed over time, and the missing bin is what causes overlap across scheduled runs. Adding project might improve readability but would not prevent double-counting.
✓
Add a 'bin' or 'bin_at' to group by time windows.
Why this is correct
Without a bin or bin_at, the query computes a single count over the entire 1-hour period, and every time the scheduled rule runs it re-counts all events in that sliding window, creating duplicate incidents. Binning by a fixed interval (e.g., 5m) groups events into distinct time buckets, so each event contributes to exactly one bucket and the rule can reference the previous run's bucket to avoid reprocessing. Use bin_at with a fixed reference point to align buckets across runs when the schedule offset matters.
✗
Add a 'where' clause to filter by ResultType.
Why it's wrong here
The query already includes a where filter on ResultType, so another where clause is redundant and cannot correct the time-window double-counting. Even if the filter were absent, narrowing by ResultType only reduces the event set; it does not change how the remaining events are grouped. The defect is in the aggregation granularity, not in the filtering predicate.

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