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.

• ✗

  Edit the analytics rule that generates the incident to include the playbook as an automated response.

  Why it's wrong here

  Editing the analytics rule to include the playbook as an automated response is incorrect because analytics rules in Microsoft Sentinel support alert-based automation, not incident-created automation. They can run playbooks with the 'When an alert is created' trigger, but they do not offer a direct, native action to execute a playbook after an incident is created. Incident-driven responses, including filtering by severity High, must be handled by an automation rule that listens for the incident creation event and invokes the playbook with the full incident payload.

• ✓

  Create an automation rule that triggers when an incident is created with severity High and runs the playbook.

  Why this is correct

  Creating an automation rule that triggers when an incident is created with severity High and runs the playbook is correct because automation rules are Microsoft Sentinel's native, event-driven mechanism for incident lifecycle automation. The rule evaluates the incident immediately on creation, checks the severity condition, and executes the playbook via the Actions pane, passing the complete incident context. This approach is consistent, auditable, and ensures that every High-severity incident triggers the playbook without relying on alert-level logic or custom polling.

• ✗

  Modify the playbook to add a trigger of 'When an incident is created' and set the severity condition.

  Why it's wrong here

  Modifying the playbook to add a trigger of 'When an incident is created' and set the severity condition is wrong because stand-alone playbooks (Logic Apps) cannot directly subscribe to Sentinel incident creation events in the recommended, event-driven pattern. Although the Sentinel Logic Apps connector may expose incident triggers, Microsoft's supported design is to use an automation rule to invoke playbooks; embedding the trigger inside the playbook bypasses native incident lifecycle integration and makes severity filtering less maintainable. The automation rule should hold the condition and the playbook should only contain the response actions, keeping orchestration logic in Sentinel where it belongs.

• ✗

  Configure the playbook's Logic Apps designer to use an HTTP trigger that polls Sentinel for new incidents.

  Why it's wrong here

  Using an HTTP trigger that polls Sentinel fails because it does not provide the immediate, event-driven automation required for every new incident. Sentinel Logic Apps offer a dedicated "When a Microsoft Sentinel incident is created" trigger for this precise scenario, which reacts instantly to incident creation. An HTTP trigger is designed for external system integration or scheduled polling of non-event-driven APIs, making it tempting for general integration, but unsuitable for direct, real-time Sentinel incident response.

Go deeper

Related to this question