SC-200 Manage a security operations environment 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.

• ✗

  Set the playbook trigger to 'When an incident is created' and add a condition inside

  Why it's wrong here

  Setting the playbook trigger to 'When an incident is created' and placing the condition inside the Logic App is inefficient because the playbook will run for every incident, regardless of whether it meets the intended criteria. Microsoft Sentinel automation rules provide a built-in condition engine that evaluates incident properties before invoking a playbook, which is the recommended place to filter incidents. Using a playbook-level condition also introduces latency and unnecessary Logic App executions, and it bypasses the centralized management that automation rules offer.

• ✗

  Add a condition in the playbook to check if the incident is assigned

  Why it's wrong here

  Adding a condition inside the playbook to check if the incident is assigned is technically feasible using a Logic App 'Condition' action, but it suffers from the same drawback as option 1: the playbook is triggered for all incidents during the creation phase. Moreover, at the moment of incident creation the owner property is always null because Sentinel does not auto-assign incidents; the playbook would not be able to differentiate between 'unassigned' and 'assigned after creation' without additional logic. Automation rules are the recommended approach because they natively evaluate incident properties at trigger time, allowing you to run the playbook only when the owner is null.

• ✓

  Configure the automation rule trigger to include a condition for 'Incident owner equals null'

  Why this is correct

  This is the correct approach because Microsoft Sentinel automation rules can be configured with trigger conditions based on incident properties, including the Incident owner field. By setting a condition such as 'Incident owner equals null', the automation rule will only execute when the incident is unassigned, ensuring that any associated playbook runs only for those incidents. This leverages Sentinel's native conditional logic, avoids unnecessary playbook executions, and is the recommended pattern for automating responses based on incident ownership status.

• ✗

  Modify the analytics rule to only generate unassigned incidents

  Why it's wrong here

  Modifying the analytics rule to 'only generate unassigned incidents' is not a valid solution because analytics rules do not have any setting that controls incident assignment. In Sentinel, all newly created incidents start with an owner of null (unassigned); assignment is a separate process performed either manually or through automation rules and playbooks. Therefore, you cannot configure an analytics rule to produce a different owner value, making this option ineffective for the stated requirement.

Go deeper

Related to this question