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.

• ✓

  Customize the anomaly threshold in UEBA

  Why this is correct

  Customizing the anomaly threshold in UEBA is the correct approach because UEBA uses machine learning models that assign anomaly scores to user behaviors, and these models expose threshold and sensitivity settings you can tune. By adjusting the sensitivity, you directly influence the score required to trigger an alert, effectively filtering out low-confidence anomalies that cause false positives while still detecting genuinely suspicious activity. This is the intended, documented method for reducing noise from UEBA-detected behaviors without sacrificing the underlying behavioral analytics capability.

• ✗

  Disable UEBA for that user

  Why it's wrong here

  Disabling UEBA for that user completely removes behavioral analytics and anomaly detection for their account, so no anomalies will be generated at all—neither false positives nor legitimate detections. This is a heavy-handed administrative action that strips the user of security monitoring, increasing the risk that real malicious behavior goes unnoticed. It does not tune detection; it eliminates it, and it also breaks Sentinel's ability to build a behavioral baseline for that user, which is why it is not a valid way to reduce false positives while preserving detection.

• ✗

  Modify the analytics rule that triggered the alert

  Why it's wrong here

  The alert was generated by UEBA's anomaly detection engine, not by a scheduled or near-real-time analytics rule that you could independently modify in Sentinel. Analytics rules are separate constructs that produce incidents from KQL queries, whereas UEBA anomalies are evaluated by a different pipeline with its own model parameters and thresholds. Editing an unrelated analytics rule would have no effect on the UEBA alert, so this option mistakes the source of the detection and would leave the false-positive issue completely unresolved.

• ✗

  Create a playbook to auto-acknowledge the alert

  Why it's wrong here

  Creating a playbook to auto-acknowledge the alert is merely an automation workaround that hides the false positive from the queue without addressing the root cause. Playbooks are designed to respond to incidents with actions like enrichment, notification, or remediation—they have no control over the UEBA detection threshold or the anomaly score calculation. Auto-acknowledging would only suppress the alert's visibility, which risks missing a future genuine anomaly that generates a similar alert and also leaves the underlying false positive recurring continuously.

Go deeper

Related to this question