SC-200 Practice Question: A security analyst is configuring a playbook in…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Create an automation rule with a condition on 'Owner' field equals 'Unassigned'

  Why this is correct

  Automation rules in Microsoft Sentinel are the recommended way to conditionally invoke playbooks based on incident properties at creation or update. Setting a condition on the Owner field equals 'Unassigned' ensures the playbook runs only for incidents that are both unassigned and (with an additional severity condition) High severity, avoiding unnecessary executions. This pre-filtering at the platform level reduces resource consumption and is more efficient than inside the playbook.

• ✗

  Use a playbook trigger 'When a Microsoft Sentinel incident is created' and add a condition in the playbook

  Why it's wrong here

  Using a playbook trigger 'When a Microsoft Sentinel incident is created' directly means the Logic App is invoked for every incident that is created, regardless of its owner or severity. While you could add a condition step inside the workflow to check ownership, this architecture wastes compute time and API calls for incidents that don't match the criteria. Automation rules are the proper mechanism to pre-filter incidents before invoking the playbook, making this approach less efficient and harder to maintain.

• ✗

  Configure a watchlist to filter incidents

  Why it's wrong here

  Watchlists are collections of external data used in analytics rules, hunting queries, and sometimes within playbooks for lookups and enrichment—they are not event-driven triggers. Configuring a watchlist does not cause a playbook to execute when an incident is created, nor can it filter incident properties like Owner. To conditionally trigger a playbook, an automation rule with appropriate conditions is required; a watchlist would simply be a data source if referenced later.

• ✗

  Use a Logic Apps trigger for all incidents and check owner within the playbook

  Why it's wrong here

  Creating a generic Logic Apps trigger for all incidents, rather than using Sentinel's automation rules, bypasses the native incident creation event and forces the workflow to handle every incoming incident without pre-filtering. This approach often requires polling the Microsoft Sentinel API or using a broad trigger, then adding internal condition logic to check the Owner field, which is less efficient and more complex than a platform-level automation rule. It also increases operational overhead because the playbook runs and incurs costs even when the incident does not meet the target criteria.

Go deeper

Related to this question