SC-200 Respond to security incidents Practice Question
Your organization uses Microsoft Sentinel with Microsoft Defender XDR integration. You have a scheduled analytics rule that detects failed logon attempts across multiple on-premises domain controllers. The rule is configured to run every 5 minutes and create an incident when more than 10 failed attempts occur from a single IP address within 5 minutes. Recently, the SOC team noticed that the rule is generating a high volume of low-fidelity incidents, mostly from legitimate users mistyping passwords. You need to reduce the number of false positive incidents while still detecting real brute-force attacks. What should you do?
⚠ Common exam trap
SC-200 often tests the misconception that simply lowering thresholds or increasing frequency improves detection, when in fact it amplifies false positives; candidates must recognize that adding specificity (multi-account condition) is the correct tuning strategy.
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
✓
Modify the query to require at least 20 failed attempts from a single IP and include a condition that the attempts are against multiple user accounts.
The correct approach is to tune the analytics rule to be more specific: raising the threshold to 20 failed attempts and requiring attempts against multiple user accounts filters out single-user password mistypes while still catching brute-force attacks that spray across accounts. This directly reduces false positives without losing detection fidelity.
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 query frequency to every 1 minute and reduce the threshold to 5.
Why it's wrong here
Lowering the threshold to 5 and shortening the query frequency to 1 minute will cause the rule to fire on routine password mistypes and transient user errors, drastically amplifying noise and alert fatigue. Additionally, because most organizations already enforce account lockout policies after a handful of failed attempts, a one-minute window with a threshold of 5 will frequently match legitimate lockout sequences, drowning out genuine brute-force activity and increasing operational overhead.
- ✓
Modify the query to require at least 20 failed attempts from a single IP and include a condition that the attempts are against multiple user accounts.
Why this is correct
Requiring at least 20 failed attempts from a single IP together with the condition that those attempts target multiple user accounts directly targets deterministic password-spray behavior while filtering out a single user's accidental mistypes. A single IP sending many failures against many distinct accounts is a strong signal for credential stuffing or password spraying, whereas failures against one account are commonly caused by a user forgetting a password. This tuning raises the confidence level of the alert without compromising detection of sustained attacks.
- ✗
Disable the rule and create a new rule based on successful logons followed by failed attempts.
Why it's wrong here
Basing the rule on successful logons followed by failed attempts redefines the detection into a post-compromise pattern and will completely miss classic brute-force attacks that never result in a successful authentication. Attackers often attempt to guess passwords over a long period, and if they never actually succeed, the rule would generate no alerts. Moreover, successful-then-failed sequencing is more indicative of a different threat, such as account usage after an attacker has already obtained valid credentials, so it should not replace a dedicated brute-force rule.
- ✗
Decrease the threshold to 5 and add a condition to exclude known good IP addresses.
Why it's wrong here
Decreasing the threshold to 5 while adding a known-good IP exclusion does not solve the underlying false-positive problem—five failed attempts from a single IP is, by itself, a weak indicator that commonly appears during legitimate account recovery or simple typos. Additionally, IP exclusion lists are brittle: attackers can easily spoof or route through allowed ranges, and legitimate but dynamic IP ranges may be inadvertently excluded, creating blind spots. The rule would still fire for many benign scenarios and would require constant maintenance, making it both noisy and unreliable for high-fidelity detection.
Go deeper
Related to this question
About these practice questions
One of 1,303 original SC-200 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Microsoft exam blueprint
This SC-200 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SC-200 exam.