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

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

Exhibit

Refer to the exhibit.
```kusto
SecurityAlert
| where AlertName == "Malware detected"
| where TimeGenerated > ago(1d)
| extend ThreatFamily = tostring(parse_json(ExtendedProperties).ThreatFamily)
| where ThreatFamily == "Ransomware"
| project TimeGenerated, AlertName, Computer, ThreatFamily
```

Refer to the exhibit. You are troubleshooting a KQL query in Microsoft Sentinel that is supposed to return alerts for ransomware detections in the last day. The query returns no results, but you know there were ransomware alerts. What is the most likely cause?

⚠ Common exam trap

Candidates often assume a simple string comparison will match all alerts of a given category, overlooking that Microsoft Sentinel alert names often include variant-specific suffixes or prefixes, making exact-match filters too restrictive.

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

✓

The AlertName filter is too specific and does not match the actual alert name.

The query's `AlertName` filter is likely too specific (e.g., using a hardcoded string like 'RansomwareAlert') and does not match the actual alert name generated by Microsoft Sentinel's analytics rules. Ransomware alerts often have dynamic naming conventions that include variant names or suffixes, so an exact match filter fails to return results even though alerts exist. The query otherwise appears syntactically correct, and the `TimeGenerated` filter is set to the last day, which aligns with the known presence of alerts.

Answer analysis

Option-by-option breakdown

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

✗
The ThreatFamily field is an integer, not a string.
Why it's wrong here
The ThreatFamily field in the SecurityAlert schema is defined as a string data type, typically containing a category or family identifier such as 'Trojan:Win32/AgentTesla'. If the field were actually an integer, the KQL query would produce a type-mismatch error during comparison rather than an empty result set. Since the query executes without error, the field type is not the source of the problem.
✓
The AlertName filter is too specific and does not match the actual alert name.
Why this is correct
The AlertName filter is too specific and does not match the actual alert name. In Microsoft Sentinel, analytics rule names often include suffixes, version numbers, or localized display names, and the exact string comparison in KQL is case-sensitive. For example, an alert named 'Suspicious PowerShell Activity' might be stored as 'Suspicious PowerShell Activity (Preview)' or with a different casing. Because the query filters for an exact match, it silently returns zero rows even though alerts exist. To resolve this, use the `has` or `contains` operator to match a substring instead of exact equality.
✗
The TimeGenerated filter uses the wrong time range.
Why it's wrong here
The TimeGenerated filter uses the wrong time range is incorrect because the expression `TimeGenerated > ago(1d)` is the standard, correct way to retrieve all records from the last 24 hours. The filter is syntactically valid and will match any event with a timestamp in that window. If the time range were misconfigured, the query would still return results from the unintended range, not an empty set, unless the time window completely excludes all data—which is not the case here. Therefore, the time filter is not the cause of the empty result.
✗
The parse_json function is failing due to malformed JSON.
Why it's wrong here
The parse_json function is failing due to malformed JSON is not the reason for empty results. The `parse_json()` function in KQL is designed to handle per-row string parsing; if an individual record contains malformed JSON, the function returns a null dynamic value for that row rather than aborting the entire query. Even in the worst case where all rows have invalid JSON, the query would still return those rows with null fields, not zero rows. Consequently, a JSON parsing failure cannot cause the complete absence of results that you are observing.

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