Manage a security operations environment →mediumMultiple Choice

SC-200 Manage a security operations environment Practice Question

Exhibit

Refer to the exhibit.
```kusto
SecurityAlert
| where TimeGenerated > ago(24h)
| where AlertSeverity == "High"
| where AlertName contains "malware"
| summarize Count = count() by AlertName, AlertSeverity
| order by Count desc
```

Refer to the exhibit. You are a security analyst reviewing a KQL query in Microsoft Sentinel. The query is intended to show the count of high-severity malware alerts in the last 24 hours. However, the query returns results only for alerts with exact severity string 'High', but you also need to include 'Informational' severity alerts that are related to malware. What should you modify?

⚠ Common exam trap

It's easy for candidates to think the issue is with the time range (Option D) or the aggregation (Option A), when the actual problem is a simple missing filter condition for the 'Informational' severity level, which is a common oversight when requirements specify multiple severity values.

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

✓

Change the 'where AlertSeverity == "High"' to 'where AlertSeverity in ("High", "Informational")'.

The query currently filters only for alerts where AlertSeverity equals 'High', but the requirement is to also include 'Informational' severity alerts related to malware. By changing the condition to 'where AlertSeverity in ("High", "Informational")', the query will return both severity levels while keeping the malware-related filter and the 24-hour time window intact.

Answer analysis

Option-by-option breakdown

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

✗
Remove the 'summarize' and 'order by' clauses.
Why it's wrong here
Removing the 'summarize' and 'order by' clauses would eliminate the aggregation that groups alerts by severity and the formatting that sorts the output, but it would not change the underlying rows being evaluated. The query would still apply the 'where AlertSeverity == "High"' filter, so only High-severity alerts would ever appear in the raw event list. Since the goal is to include Informational-severity malware alerts, deleting these operators leaves the restrictive severity predicate untouched and therefore fails to solve the root problem.
✗
Remove the 'where AlertName contains "malware"' condition.
Why it's wrong here
Deleting the 'where AlertName contains "malware"' condition would broaden the query to include every alert type, not just malware-related ones. That would change the investigation's scope and likely return a large number of unrelated alert results, while still applying the same 'where AlertSeverity == "High"' filter. Informational-severity malware alerts would remain excluded because the severity filter is independent of the alert-name filter. The alert-name condition is a legitimate narrowing criterion and is not the reason Informational severity alerts are missing.
✓
Change the 'where AlertSeverity == "High"' to 'where AlertSeverity in ("High", "Informational")'.
Why this is correct
Changing the equality filter to use the 'in' operator with a set of allowed values is the correct fix because it explicitly instructs the query to include rows where AlertSeverity is either "High" or "Informational". The original predicate 'where AlertSeverity == "High"' only passes rows with that exact value, so anything marked Informational is discarded before aggregation. Using 'in' with both severity levels preserves the malware-name filter and the 24-hour timeframe while expanding the severity scope to match the investigation's requirement to review both High and Informational alerts.
✗
Change 'ago(24h)' to 'ago(48h)'.
Why it's wrong here
Extending the time range from 24 hours to 48 hours affects only the temporal window of the query, not the severity values accepted by the filters. If Informational-severity malware alerts are absent from the last 24 hours, a longer window could theoretically retrieve older ones, but the query itself is still filtering on 'AlertSeverity == "High"' only. The missing Informational results are caused by the restrictive severity predicate, not by the time-window length, so this change would not resolve the issue. Moreover, if such alerts did occur within 24 hours, the current query would still omit them regardless of how far back the timeframe extends.

Go deeper

SC-200 Manage a security operations environment Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question