Respond to security incidents →mediumMultiple Choice

SC-200 Respond to security incidents Practice Question

Exhibit

Refer to the exhibit.

```json
{
  "id": "/subscriptions/.../resourceGroups/rg-sentinel/providers/Microsoft.OperationalInsights/workspaces/workspace-sentinel/providers/Microsoft.SecurityInsights/alertRules/5b7c8d9e-...",
  "kind": "Scheduled",
  "properties": {
    "displayName": "RDP brute force success",
    "query": "SecurityEvent | where EventID == 4625 | summarize count() by Account, IpAddress, bin(TimeGenerated, 5m) | where count_ > 10",
    "queryFrequency": "PT5M",
    "queryPeriod": "PT10M",
    "triggerOperator": "GreaterThan",
    "triggerThreshold": 0,
    "severity": "High",
    "enabled": true
  }
}
```

Refer to the exhibit. A Microsoft Sentinel scheduled rule is configured as shown. The rule generates an alert, but the incident created contains only the first alert, and subsequent alerts do not update the incident. What is the most likely cause?

⚠ Common exam trap

It's easy for candidates to confuse alert grouping (which controls incident creation) with query logic or severity, assuming that a high severity or a missing join would cause the incident not to update, when in fact the root cause is the disabled grouping setting.

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 rule does not have incident grouping enabled.

The exhibit shows the rule is configured to create a single incident from alerts grouped by entities, but the 'Grouping' settings are not enabled. Without incident grouping enabled, each alert generates a separate incident, and subsequent alerts do not update the existing incident. Enabling incident grouping allows alerts matching the same grouping criteria to be merged into the same incident, ensuring updates occur.

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 triggerOperator and triggerThreshold are misconfigured.
Why it's wrong here
The triggerOperator and triggerThreshold in a scheduled analytics rule define when an alert is fired based on the query's result count. Here, GreaterThan with a threshold of 0 is exactly correct—it means 'create an alert if there is at least one failed sign-in count,' which matches the brute-force detection intent. This configuration has no bearing on incident grouping; the alert fires properly every time the condition is met. The problematic behavior occurs later, when multiple alerts are (or are not) merged into incidents.
✗
The KQL query is missing a join to include more data.
Why it's wrong here
The KQL query here already performs a summarize count on failed sign-in events, which is sufficient to produce the alert condition. Adding a join would only pull in additional data sources or enrich the result set, but it would not alter how Sentinel aggregates alerts into incidents. Incident grouping is governed exclusively by the 'Incident settings' tab in the rule configuration, not by the query's shape or content. Therefore, the missing join is irrelevant to the reported symptom of duplicate incidents.
✗
The severity is set to High, which prevents incident updates.
Why it's wrong here
Severity is an alert/incident metadata attribute that drives triage priority and reporting, but it has no influence on incident grouping or update behavior. Setting a rule to High simply labels the generated incidents as High; it does not disable the ability to append subsequent alerts to an existing incident. Whether a new incident is created or an existing one is updated depends entirely on the grouping settings (e.g., whether 'group related alerts into a single incident' is enabled and which entities are used). The High severity setting is therefore not the cause of separate incidents.
✓
The rule does not have incident grouping enabled.
Why this is correct
The rule does not have incident grouping enabled, which means each time the scheduled query fires and creates an alert, Sentinel provisions a brand-new incident instead of attaching the alert to an already open incident. In the analytics rule's Incident settings, the 'Group related alerts into a single incident' option is either unchecked or set to 'do not group,' resulting in a one-to-one alert-to-incident relationship. Consequently, the second brute-force attempt generates a new incident rather than updating the existing one, exactly as described in the exhibit. Enabling grouping with an appropriate entity (e.g., target username) and time window would cause subsequent alerts to update the original incident.

Go deeper

SC-200 Respond to security incidents Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question