Articles · Microsoft

Microsoft Sentinel Interview Questions: Detection Rules, Incident Grouping, and Investigation

Prepare for Microsoft Sentinel interview questions with late-event windows, alert versus incident grouping, entity mappings, and reproducible investigation.

Microsoft Sentinel interview questions often start with a detection rule and turn into an evidence problem: an event exists now, but did it exist when the rule ran? Two alerts appear in one incident, but do they describe the same activity? A strong answer follows source data through the query, alert and investigation instead of treating the incident count as a security verdict.

Official scope: Microsoft's current integration guidance recommends custom detections for new unified Defender/Sentinel detection work, while scheduled analytics rules remain available. This article deliberately examines scheduled-rule mechanics and their relationship with Defender correlation. Confirm the rule family and portal before applying an answer to a different detection experience.

The time ledgers, grouping examples and interview recommendations below are original exercises. Their Python logic was checked locally; no Azure workspace, Sentinel rule or Defender incident was created.

What does a scheduled detection rule actually evaluate?

Begin with the source table, expected schema, data availability and query output grain. A rule looking for repeated failures by account and host should not return an unexplained mixture of raw failures, aggregate counts and unrelated identities.

Official configuration: The scheduled-rule creation guide separates query interval from lookback and requires lookback to cover at least the interval. It also describes rule thresholds and event grouping. A query's business count is not automatically the same quantity as the number of result rows used by the rule configuration.

For our original contract, two qualifying failures for the same account-host pair are suspicious enough to produce one result row. The query performs that count and filters on it. A rule threshold asking whether at least one result row exists then tests for a qualifying pair. Setting the rule threshold to two rows would instead require two qualifying pairs.

State the intended behavior in ordinary language before KQL: “For each account-host pair, emit one row when its selected failures meet the threshold.” Then identify which fields must survive aggregation for entity mapping and investigation. A scalar count with no actor or host can fire an alert while leaving the analyst unable to establish scope.

Treat a template as a starting contract, not evidence that your source follows it. Check that the mapped action, status code and identity fields mean the same thing in the actual feed. A parser change that turns a success into a failure can change detection meaning without producing a syntax error.

Why can an event in the table be absent from an earlier alert?

Separate event generation, ingestion and rule evaluation. The data available when an analyst later reruns a query can be different from the data available at the original execution.

Official timing behavior: The scheduled-rule overview documents a five-minute delay from scheduled execution to account for ingestion latency. That does not prove every source arrives within five minutes. Microsoft's ingestion-delay guidance explains why event-time lookbacks can still miss records that arrive late.

Our original fixture uses fixed UTC evaluation endpoints of 12:10 and 12:15 on one date. They are exercise query endpoints, not nominal scheduler labels; we do not add the service's documented delay again. Each window is open at its lower boundary and closed at its upper boundary, and an event is available only after ingestion.

Event	Generated	Ingested	Account / host	Teaching role
E1	12:04	12:11	U1 / H1	Late enough to miss a five-minute event window
E2	12:09	12:09	U2 / H2	Can repeat in overlapping wider windows
E3	12:12	12:13	U1 / H1	Arrives within the second ordinary window
E4	12:00	12:14	U3 / H3	Too old even for the chosen wider window

At 12:10, a five-minute query sees E2. E1 is not ingested yet. At 12:15, it sees E3, but E1's generation time is now older than the window. Inspecting E1 in the table afterward does not establish that the original rule could have selected it.

The useful follow-up is the delay distribution of the required sources, including tails and disruptions. An average delay can look acceptable while a minority of relevant events repeatedly arrives outside the window. Compare event and ingestion timestamps, and preserve the original run endpoint when reproducing a miss.

Does extending the lookback solve both loss and duplication?

In our fixture, a 12-minute event lookback sees E2 at 12:10 and E1, E2 and E3 at 12:15. E1 is recovered, but E2 appears twice. E4 remains excluded because its event time falls outside the extended window. The extension has a bounded benefit; it is not a complete lateness guarantee.

Official mitigation pattern: Microsoft's delay guidance combines a broader event window with an ingestion-time restriction to associate incoming records with an evaluation interval. For our idealized timestamps, add a fresh-ingestion window of five minutes. The selections become E2, then E1 and E3, avoiding E2's repetition in these two runs.

Official limitation: Kusto's ingestion_time reference returns an approximate timestamp and can return null when the relevant ingestion policy was not enabled. It is not a durable ordering or exactly-once mechanism. Our deterministic fixture uses explicit timestamps; it does not establish a production guarantee from that function.

Here is a documentation-reviewed KQL sketch for a hypothetical custom table. The fixed endpoint makes the exercise reproducible; a deployed rule needs its actual schedule, source schema and supported time behavior validated.

let run_end = datetime(2026-10-06T12:15:00Z);
let event_window = 12m;
let fresh_window = 5m;
InterviewEvents
| where TimeGenerated > run_end - event_window
    and TimeGenerated <= run_end
| where ingestion_time() > run_end - fresh_window
    and ingestion_time() <= run_end
| summarize EventCount = count(),
            TimeGenerated = max(TimeGenerated)
    by AccountKey, HostKey
| where EventCount >= 2

For E1 and E3, the teaching model yields one U1/H1 result row with EventCount 2 and TimeGenerated 12:12. The count of returned rows is 1. The preserved timestamp and entity keys explain both the threshold decision and what the resulting alert can identify.

This sketch counts newly ingested selected events. For a rolling-count or multi-event rule, filtering to fresh rows before aggregation can remove older evidence needed to meet the condition. Our additional two-event control has one old and one fresh failure: the full history meets a count of two, while the fresh-only subset does not. Preserve the required detection history and design the emission or deduplication boundary separately.

If a run is retried or skipped, reconsider the fresh interval and replay boundary. Repeating the same endpoint repeats the same selection in our model. Production deduplication or recovery needs stable event identity, an explicit replay policy and observable run history. Increasing a time window alone does not supply those properties.

How do event grouping and incident grouping differ?

Official distinction: The scheduled-rule overview offers a single alert summarizing the query results or an alert for each returned result. Its incident settings then separately control how alerts are turned into incidents and grouped. Read “event” in that UI in the context of the query result, especially after aggregation.

Our U1/H1 query result represents two selected raw events but one aggregate row. Per-result alerting produces one alert for that row, not one alert for each underlying failure. If a query returns three aggregate rows, combining the results into one alert changes the analyst's evidence container without changing the underlying three rows.

For a separate original grouping exercise, assume three alerts from one rule, within its configured grouping period. A1 and A2 identify U1/H1; A3 identifies U1/H2. We map both account and host and compare two documented grouping concepts:

Configured grouping concept	Exercise grouping	What is retained or combined?
All mapped entities match	A1+A2; A3 separate	Host difference preserves two groups
All alerts from this rule together	A1+A2+A3	Rule identity combines the host cases

This matrix models configuration meaning, not a promise about the final Defender incident count. Decide whether host separation fits the investigation: two hosts can be one attack sequence, or two independent problems. Neither a shared account nor a shared rule name proves the answer by itself.

What changes when Defender correlates the alerts?

Official correlation boundary: The Defender correlation reference describes an internal engine that creates or updates incidents and can merge incidents as relationships become apparent. Its criteria include entities, artifacts, time and activity sequences, but the complete correlation logic is proprietary. Do not predict its output solely from the grouping matrix above.

Also identify whether the workspace is primary or secondary in the Defender portal. The same reference distinguishes their correlation scope. A claim that every onboarded workspace's alerts are freely correlated across all workspaces would ignore that boundary.

The current reference describes the existing incident experience and points to incident cases as the recommended management experience. Confirm which experience the interviewer means before giving UI-specific recovery steps. A portal migration can change the operating surface while leaving the core evidence question intact.

Official current date: The entity-mapping guidance, checked October 6, 2026, says Azure-portal support ends after March 31, 2027. Older walkthroughs that imply an earlier retirement are not an adequate basis for current navigation instructions. Use the actual portal and rule family rather than memorizing screenshots.

For an unexpected merge, retain the original alert IDs, rule IDs, mapped identities and merge history. Compare the evidence in the resulting incident with the earlier containers. A lower incident count could reflect consolidation, not reduced suspicious activity; a changed title could reflect correlation, not a newly detected event.

What evidence makes an investigation defensible?

Official identity guidance: Entity mapping connects query fields to recognized identities and recommends strong identifiers. A display name alone can combine different accounts or hosts. Preserve the relevant tenant/domain context and stable identity fields when the source supports them; a graph edge is only as interpretable as the mapped identity.

Our original investigation note records rule version, run endpoint, source coverage, selected event IDs, account-host identifiers, returned row, alert ID and incident context. It separates observation—two qualifying failures—from hypothesis—possible credential misuse—and next check—whether a successful sign-in or known user activity explains the sequence.

Official evidence caution: The troubleshooting guide explains that rerunning an original query can yield different results because of ingestion delay or aggregation. For per-result alerts, distinguish the saved event record from OriginalQuery. Reconstruct the original boundary before describing a changed result as proof that the alert was wrong.

The same guide distinguishes transient failures from permanent failures that can disable a rule. If expected alerts disappear, inspect rule health, access and source/schema changes before tuning the threshold. A rule that never executed and a rule that executed with zero qualifying rows require different repairs.

For Azure-portal investigations specifically, Microsoft's investigation guide describes drilling into alerts and raw queries and reviewing the incident activity log. Use those surfaces to distinguish analyst actions from automation. Closing an incident is a workflow action, not evidence that the original source stopped producing events.

Finish with a bounded finding and an explicit unresolved check. For example: “E1 was absent at the first run and too old for the next narrow lookback; the wider fixture recovers it, but E4 demonstrates the remaining late-data gap.” That is stronger than claiming complete detection coverage from a successful simulation.