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

Answer analysis

Option-by-option breakdown

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

• ✓

  Tune analytics rules to generate incidents only for high-fidelity alerts and use automation rules to collect feedback on incident closure

  Why this is correct

  Tuning analytics rules is the correct approach because it targets the root cause of alert fatigue: noisy or overly broad detection logic. By refining query thresholds, alert grouping, and incident creation settings, you ensure that only high-fidelity findings become incidents, while automation rules can trigger a playbook (e.g., an HTTP request or Teams message) to gather analyst feedback at incident closure. This feedback loop lets security operations continuously improve rule tuning without adding manual burden.

• ✗

  Create a separate analytics rule for each severity level

  Why it's wrong here

  Creating a separate analytics rule for each severity level is ineffective because it multiplies the number of rule definitions while leaving the underlying alert volume unchanged. Each rule still triggers on the same detection logic, so analysts receive the same number of incidents—just artificially segmented by severity. This fragmentation also increases administrative overhead and makes it harder to tune a detection pattern holistically, as you must edit multiple rules for a single false-positive source.

• ✗

  Implement a playbook that automatically closes low-severity alerts and collects feedback

  Why it's wrong here

  Automatically closing low-severity alerts via a playbook is dangerous because it dismisses events without any analyst judgment, potentially hiding true positives that exhibit low severity but high risk. Collecting feedback on closure is a separate operations process and does not reduce the number of incidents that initially reach the queue; it only records opinion after the fact. A successful reduction strategy must lower the volume of alerts that become incidents, not blindly suppress them after generation.

• ✗

  Increase the severity threshold for all analytics rules

  Why it's wrong here

  Increasing the severity threshold for all analytics rules is a blunt instrument that would prevent legitimate low-severity detections from ever becoming incidents, allowing subtle but important threats to slip through unnoticed. Severity is not a simple global threshold in Sentinel—it is configured per rule, and globally raising it would require editing every rule to only emit high severity, which defeats rule-specific context. This approach sacrifices detection coverage and fails to distinguish between noisy false positives and meaningful low-severity findings.

Go deeper

Related to this question