SC-200 Manage a security operations environment Practice Question
You are configuring Microsoft Sentinel automation rules to handle incidents generated from Microsoft Defender for Cloud. You need to ensure that when a high-severity security alert is triggered, an automated response runs a playbook that creates a support ticket in ServiceNow. However, the playbook fails to execute for some alerts. Upon investigation, you find that the automation rule is triggered only when the incident is created. What is the most likely cause of the failure?
⚠ Common exam trap
Watch out — candidates often assume all playbooks can run on incident creation, but many playbooks require the incident to be updated first to access complete data, and the automation rule must be configured with the correct trigger condition.
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
✓
The automation rule is configured to trigger only on incident creation, but the playbook requires the incident to be in an updated state.
The automation rule is configured to trigger only on incident creation. However, the playbook requires the incident to be in an updated state to execute, meaning the automation rule does not fire when the incident is updated after creation. This mismatch causes the playbook to fail for alerts that require an update trigger.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
The automation rule is configured to trigger only on incident creation, but the playbook requires the incident to be in an updated state.
Why this is correct
The automation rule's trigger is the likely culprit. In Microsoft Sentinel, automation rules can be configured to run when an incident is created, when an incident is updated, or when an alert is generated. If your rule runs only at creation time, the playbook executes immediately after the incident is born, before any status changes, owner assignments, or alert grouping that would normally follow. Many playbooks—especially those using the Sentinel incident connector's 'Get incident' action—expect the incident to have these post-creation values, and without them the playbook may error out or take an incorrect action. To resolve this, you should create a second automation rule triggered on incident update, or change the trigger to match the playbook's dependency.
- ✗
The automation rule lacks permissions to the ServiceNow connector because of Microsoft Entra ID conditional access policies.
Why it's wrong here
This is not a valid cause because Microsoft Entra ID conditional access policies govern interactive user sign-in sessions, not service-to-service communications between Azure Logic Apps and connectors like ServiceNow. Automation rules invoke playbooks via the Logic Apps engine, which authenticates using a managed identity or service principal with scoped Azure RBAC permissions, not through the browser session of an individual user. Additionally, the ServiceNow connector generally relies on basic authentication or an API key rather than Microsoft Entra ID tokens, so conditional access would not be a relevant blocking mechanism. Therefore, while a permissions or connectivity issue might exist with the connector, it would stem from misconfigured credentials or network rules, not from conditional access.
- ✗
Playbooks cannot be called by automation rules in Microsoft Sentinel.
Why it's wrong here
This statement is factually incorrect. Azure Logic Apps playbooks are a first-class response action in Microsoft Sentinel automation rules. When configuring an automation rule, you can add a 'Run playbook' action, choose the Logic App from your tenant, and specify whether to pass the incident or an alert entity to the playbook workflow. Automation rules can even run multiple playbooks sequentially, and Sentinel lists playbooks that are enabled for incident triggers. Thus it is entirely possible to call a playbook from an automation rule, so this cannot explain any failure.
- ✗
Automation rules cannot be triggered on incident creation from Microsoft Defender for Cloud.
Why it's wrong here
That is a false assumption. Microsoft Sentinel ingests alerts and incidents from many sources, including Microsoft Defender for Cloud, and once ingested they are native Sentinel incidents. The automation rule trigger 'When incident is created' fires for any incident synchronously created in Sentinel, regardless of which connector produced the underlying alert. Defender for Cloud alerts that get correlated into a Sentinel incident will therefore be processed by the same automation rules as any other incident. Hence, source origination does not disable the creation trigger, and this is not a plausible reason for the automation rule not running.
Go deeper
Related to this question
About these practice questions
This SC-200 question is part of Courseiva's 1,303-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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-200 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-200 exam.