SC-200 Respond to security incidents 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.

• ✗

  Increase the alert threshold to require more than one anomalous sign-in per hour.

  Why it's wrong here

  Raising the alert threshold to require more than one anomalous sign-in per hour merely suppresses alert volume; it does not remediate the underlying UserAgent anomalies causing false positives. A burst of multiple malicious sign-ins within a short window is a classic indicator of credential stuffing or session replay, and raising the threshold would cause the rule to miss that genuine attack. Threshold tuning is a blunt instrument that sacrifices detection fidelity for noise reduction, unlike a query-level filter that targets the exact condition responsible for the false positives.

• ✗

  Create a watchlist of legitimate IP addresses and reference it in the rule.

  Why it's wrong here

  Creating a watchlist of legitimate IP addresses and referencing it in the rule addresses source IP reputation, not the UserAgent field that is actually generating false positives. Legitimate user agents can originate from many IPs, including shared cloud egress ranges or proxy services, so an IP allowlist would be either too permissive (if broad) or would require constant maintenance to stay accurate. Additionally, a watchlist lookup adds complexity to the KQL query and does not diminish the alerts triggered by an unrecognized but benign UserAgent string.

• ✗

  Disable the analytics rule and create a new one with different MITRE tactics.

  Why it's wrong here

  Disabling the analytics rule and creating a new one with different MITRE tactics changes only the rule's metadata classification (e.g., from CredentialAccess to InitialAccess) without altering the query logic that produces false positives. This action also removes the existing rule's alert history, breaks any automated playbooks or incident correlation tied to the rule ID, and degrades the overall security coverage by introducing a gap during the transition. It is an operational mistake to sacrifice an active detection merely to reassign tactics when a precise query adjustment would resolve the real problem.

• ✓

  Add a condition to the rule query to filter out known legitimate user agents.

  Why this is correct

  Adding a condition to the rule query to filter out known legitimate user agents is the targeted fix because it directly removes the benign UserAgent strings from the anomaly-detection scope. In KQL, you can implement this with a `where UserAgent notin (~['LegitAgent1', 'LegitAgent2'])` clause or a regex pattern like `where UserAgent !matches regex @"(Chrome/120\.0|Edge/120\.0)"`, preserving the rule's ability to detect truly anomalous strings. This approach reduces false positives while maintaining full detection fidelity for other anomalous sign-in attributes such as geographic location, device compliance, or risk score, aligning with Sentinel best practices for rule tuning.

Go deeper

Related to this question