hardMultiple ChoiceObjective-mapped
SC-200 A SOC team uses Microsoft Sentinel Practice Question
A SOC team uses Microsoft Sentinel. They receive a large volume of low-severity incidents from a specific analytics rule that causes alert fatigue. They want to automatically close incidents that match certain criteria (e.g., originating from a known test IP). Which feature should they configure?
⚠ Common exam trap
Microsoft often tests the distinction between automation rules (native, condition-based actions) and playbooks (external Logic Apps workflows), leading candidates to incorrectly choose a playbook when a simpler automation rule suffices.
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
✓
Automation rules with a condition to close incidents
Automation rules in Microsoft Sentinel allow you to automatically close incidents based on specific conditions, such as a known test IP address. This directly addresses alert fatigue by suppressing low-severity incidents without manual intervention. Unlike playbooks, automation rules are lightweight and run natively within Sentinel without requiring a Logic Apps instance.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Automation rules with a condition to close incidents
Why this is correct
Automation rules are native Sentinel orchestration objects that trigger synchronously on incident creation or update. Under a condition such as an entity matching a watchlist or a low severity classification, the rule can execute the 'Close incident' action with a chosen classification and comment, requiring no external logic app and no analyst intervention. This is the correct low-code way to suppress noisy alerts.
- ✗
Playbook with a timer trigger
Why it's wrong here
A timer-triggered playbook uses a Logic Apps Recurrence trigger, which fires on a fixed schedule rather than in response to a generated incident. It would have to run an API/Sentinel query to find open incidents and then pair them with condition criteria, adding latency and requiring extra permissions, and it cannot consume the incident payload from the incident-creation workflow. Therefore it is not the right mechanism for immediate, condition-based incident closure.
- ✗
Watchlist integration
Why it's wrong here
A watchlist is a persisted CSV-like reference dataset that you load into Sentinel for lookups in KQL, analytics rules, and automation condition definitions. It does not itself contain executable logic or incident lifecycle actions; there is no 'close incident' action on a watchlist. To leverage it for suppression, you must reference it from an automation rule or playbook that evaluates the condition and performs the close.
- ✗
Fusion rule
Why it's wrong here
A Fusion rule is an analytics correlation engine that uses ML to combine low-fidelity alerts from multiple sources into a single high-fidelity, multi-stage attack incident. It is designed to detect and escalate complex threats, not to act as a response mechanism; it neither evaluates conditions for closing existing incidents nor exposes a close action. Enabling it would increase incident count, not suppress it.
Go deeper
Related to this question
About these practice questions
Courseiva writes every SC-200 question from scratch — 209 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
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.