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.

• ✓

  Configure an automation rule to run a playbook automatically

  Why this is correct

  Automation rules in Microsoft Sentinel are event-driven orchestration mechanisms that evaluate newly created or updated incidents against configured conditions—such as severity or name—and then execute one or more linked playbooks automatically. Playbooks are Azure Logic Apps that can perform remediation steps like isolation, data collection, or notification, ensuring consistent, immediate response without human involvement. This is the only approach listed that satisfies 'automatically' while honoring incident context, since automation rules trigger exactly when incidents are created or changed.

• ✗

  Create a playbook and run it manually for each incident

  Why it's wrong here

  Although playbooks can be launched from the Sentinel blade when you open an incident, relying on manual invocation for every case is neither scalable nor reliable, especially during high alert volume or 24x7 operations. Manual runs depend on an analyst remembering to click 'Run playbook,' and they are not governed by incident properties or policies, so the response may be inconsistent. To meet an 'automatic' requirement, the playbook must be tied to an automation rule that applies the trigger logic uniformly, eliminating human latency and oversight.

• ✗

  Set up an analytics rule with automatic response

  Why it's wrong here

  Analytics rules in Sentinel are detection mechanisms—they run KQL queries on log sources, alert on suspicious activity, and generate security incidents. They do not contain a native action that runs a Logic App or otherwise performs a response; even the rule's 'Alert automation' tab actually expects you to create an automation rule, which then triggers playbooks. Therefore, an analytics rule alone cannot automate a fix; it only supplies the incident that a separate automation rule must consume.

• ✗

  Use a workbook to trigger a playbook

  Why it's wrong here

  Workbooks are Azure Monitor-based interactive dashboards designed for visualization, aggregation, and exploration of security data; they graph metrics, trends, and entity details. A workbook has no runtime ability to call a playbook or send an incident-response action—any button or link in it would be a user-initiated manual step, not a system-triggered automation. So, for the stated goal of automatic incident response, workbooks are strictly a reporting layer, not an orchestration control plane.

Go deeper

Related to this question