SC-100 Practice Question: Design security operations, identity, and compliance capabilities
Your company uses Microsoft Sentinel to manage security incidents. You need to design a solution that automatically triages low-severity incidents and enriches them with threat intelligence. Which THREE capabilities would you include? (Choose three.)
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
✓
Playbooks to perform enrichment actions like querying threat intelligence.
Option C is correct because Microsoft Sentinel playbooks, built on Azure Logic Apps, are the automation mechanism that can call the Threat Intelligence connectors and other enrichment actions to add context (for example, IP/domain reputation) to an incident. Option D is correct because automation rules evaluate incident conditions (such as severity or title) at incident creation and can trigger the playbook, which is exactly how low-severity incidents get automatically triaged and enriched. Option E is correct because watchlists let you upload and correlate known indicators (IPs, domains, hashes) against incident entities, providing a lightweight threat-intelligence enrichment source within Sentinel. Option A is not appropriate here because advanced hunting queries are manual, interactive KQL investigations rather than an automated triage/enrichment capability. Option B is not appropriate because analytics rules generate alerts and incidents; they do not perform the automated triage or threat-intelligence enrichment the scenario requires.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Advanced hunting queries to investigate incidents.
Why it's wrong here
Advanced hunting is a KQL-based interactive search tool used by analysts to proactively hunt for suspicious activity or perform deep forensic investigation after an incident has already been detected. It is fundamentally manual and designed for iterative exploration—there is no native mechanism to invoke it automatically on incident creation, nor can it enrich incidents with external data. Therefore, it cannot serve as an automated triage or enrichment step for low-severity incidents.
- ✗
Analytics rules to generate alerts for low-severity incidents.
Why it's wrong here
Analytics rules are the detection logic that continuously run on data connectors and, when a match occurs, create alerts and incidents in Microsoft Sentinel. They are the source of incident generation, not a downstream action that processes existing incidents. Once an incident exists, analytics rules are not re-triggered by that incident and have no capability to modify its severity, assign ownership, or add context—this is the role of automation rules and playbooks, not analytics rules.
- ✓
Playbooks to perform enrichment actions like querying threat intelligence.
Why this is correct
Playbooks are Azure Logic Apps workflows that can be automatically invoked by automation rules to perform enrichment operations on an incident, such as querying Threat Intelligence platforms like MISP or Microsoft Graph Security API. By pulling threat intel about involved entities (IPs, hashes, domains) and writing those findings back to the incident, playbooks give analysts and automated rules the context needed to rapidly triage and prioritize low-severity incidents without manual querying.
- ✓
Automation rules to trigger playbooks on incident creation.
Why this is correct
Automation rules are the orchestration engine within Sentinel that react to lifecycle events, the most common being incident creation, and can execute a defined set of actions such as changing status, assigning a user, adding tags, and most importantly triggering one or more playbooks. For low-severity incidents, an automation rule scoped by severity can immediately invoke an enrichment playbook, ensuring consistent, hands-off triage and allowing SOC staff to focus on high-fidelity alerts.
- ✓
Watchlists to store known indicators for correlation.
Why this is correct
Watchlists are persistent, high-performance key-value stores in Sentinel that hold curated reference data—such as known malicious IPs, compromised usernames, or highly sensitive assets—uploaded from CSV files or Azure Data Lake. They are not automation tools per se, but they become powerful when consumed by playbooks: a playbook can take entity values from an incident, look them up in the relevant watchlist, and automatically tag the incident if a match is found, enabling correlation against known indicators as part of an automated triage workflow.
Go deeper
Related to this question
About these practice questions
Courseiva writes every SC-100 question from scratch — 605 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-100 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-100 exam.