SC-200 Manage a security operations environment Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  Create separate incidents for each alert.

  Why it's wrong here

  Creating separate incidents for each alert fragments the analyst's view of an attack chain. A single attacker action or multi-stage campaign often produces several alerts within a short window; splitting them into distinct incidents forces analysts to manually correlate timestamps, entities, and kill-chain phases, increasing triage time and the likelihood of missing the broader context. This practice directly contradicts Microsoft Sentinel's incident-centric approach, which is designed to consolidate alerts into actionable units.

• ✗

  Create automation rules to close all low-severity incidents automatically.

  Why it's wrong here

  An automation rule that indiscriminately closes every low-severity incident removes the opportunity to detect patterns, such as repeated low-severity events that indicate progressive compromise or staging activity. These incidents may also represent genuine misconfigurations or early indicators that warrant a quick investigation, and automated closure without any condition on entity, tactic, or source suppresses that visibility. While closing known false positives is valid, a blanket rule overrides analyst judgment and can hide meaningful low-level signals.

• ✓

  Configure alert grouping in analytics rules to combine related alerts into one incident.

  Why this is correct

  Alert grouping in an analytics rule, configured under 'Incident settings,' consolidates alerts that share the same group key—commonly entity mappings like account, host, or IP—into a single incident. This reduces alert volume while preserving the correlation between related events, enabling the analyst to see the full attack narrative in one place. Grouping also lets you set a display name and alert severity for the aggregated incident, which improves triage prioritization and reduces the operational overhead of handling many separate incident objects.

• ✓

  Use suppression and tuning rules to filter out known benign activity.

  Why this is correct

  Suppression and tuning rules, such as Sentinel's built-in alert suppression in analytics rules or custom automation to close benign incidents, filter out known-good user agent strings, internal test traffic, or other predictable activity that triggers rules without representing a real threat. This approach reduces false positives at the source, decreasing the number of incidents analysts must investigate, but it requires careful scoping to avoid hiding legitimate anomalies. Properly tuned suppression complements alert grouping by lowering noise before correlation happens.

• ✗

  Increase the severity of all low-severity alerts to high.

  Why it's wrong here

  Raising the severity of all low-severity alerts to high is a blunt, counterproductive measure that destroys the prioritization signal. High-severity incidents typically correspond to critical impact, urgent containment, or active lateral movement; if every alert is marked high, SOC analysts will suffer from alert fatigue and may begin ignoring even genuinely critical incidents. Severity should reflect the true risk and context, not a desire to make alerts more visible, and mislabeling severity can also break SLA-based automation and reporting.

Go deeper

Related to this question