Manage identity and access →hardMultiple Choice

AZ-500 Manage identity and access Practice Question

A Sentinel scheduled rule runs every 5 minutes and looks back 1 hour. Analysts see repeated alerts for the same event. Which change best prevents duplicate detections without missing late-arriving logs?

⚠ Common exam trap

Many exam-takers confuse reducing the lookback period (Option A) as a quick fix, not realizing it will miss late-arriving logs, while the correct solution uses a query-level exclusion window that preserves the lookback for completeness.

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

✓

Use an ingestion-time or event-time exclusion window in the query

Using an ingestion-time or event-time exclusion window in the query allows the rule to skip events that have already generated an alert within a specific time range, preventing duplicate detections while still accommodating late-arriving logs. This approach leverages the query logic to filter out duplicates based on a time-based deduplication key, ensuring that only new or unique events trigger alerts without altering the lookback period.

Answer analysis

Option-by-option breakdown

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

✗
Reduce the query lookback to 1 minute
Why it's wrong here
Reducing the query lookback to 1 minute would narrow the search horizon to events generated in the last minute, but the Microsoft Sentinel scheduled rule still runs every 5 minutes, so the new window is shorter than the rule frequency. This can cause missing alerts for events that arrive with ingestion delay or for slowly arriving data, and it does not prevent the same event from being returned in two adjacent runs if its timestamp falls inside both windows. It changes detection coverage rather than addressing the root cause of duplicate alert generation.
✓
Use an ingestion-time or event-time exclusion window in the query
Why this is correct
Adding a filter such as `where ingestion_time() > ago(5m)` or comparing an event-time column to the previous run's execution time creates an exclusion window in the KQL query. This ensures each scheduled run only evaluates events that are new since the last run, while keeping the original lookback for late-arriving telemetry. As a result, the query is idempotent and the same underlying event will not trigger a new alert in every 5-minute execution. This is the recommended way to meet the stated requirement directly.
✗
Disable alert grouping
Why it's wrong here
Alert grouping in Microsoft Sentinel controls whether multiple alerts are merged into a single incident, not whether the scheduled query returns the same event more than once. Disabling grouping would instruct Sentinel to create a separate incident for each matching alert, which increases noise and worsens the duplicate problem instead of solving it. The query results are unchanged, so the underlying events would still be evaluated on every 5-minute run and generate repeated alerts.
✗
Change the workspace retention period
Why it's wrong here
Changing the workspace retention period governs how far back data is available for historical searches and archiving, not how the scheduled query filters records on each execution. If the retention period is shortened, the events that fall within the rule's lookback window are still present and are still returned every five minutes, so duplicate alerts will continue. It also risks deleting logs needed for other detections and investigations, and it does not alter the query's deduplication logic.

Go deeper

AZ-500 Manage identity and access Practice Question

Why each option matters

Option-by-option breakdown

Related to this question