SC-200 Manage a security operations environment Practice Question
Your SOC uses Microsoft Sentinel and Microsoft Defender XDR. An incident is generated from a Microsoft Defender for Identity alert about a suspicious Kerberos ticket request. The incident is assigned the 'Medium' severity. You want to automatically increase the severity to 'High' if the user is in a privileged role, based on data from Microsoft Entra ID. What is the most efficient way to achieve this?
⚠ Common exam trap
Candidates often think modifying the analytics rule (Option B) is simpler, but they overlook that analytics rules cannot natively query external identity stores like Microsoft Entra ID during query execution without complex KQL cross-workspace joins or enrichment, making the automation rule with a playbook the most efficient and maintainable solution.
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
✓
Create an automation rule in Microsoft Sentinel triggered on incident creation, which runs a playbook that checks Microsoft Entra ID roles and updates the severity accordingly.
Automation rules in Microsoft Sentinel can trigger a playbook on incident creation, and that playbook can use the Microsoft Graph API to query Microsoft Entra ID for the user's role assignments. If the user holds a privileged role (e.g., Global Administrator), the playbook can programmatically update the incident's severity to 'High'. This approach is event-driven, efficient, and does not require modifying existing analytics rules or creating additional scheduled queries.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Enable automatic attack disruption in Microsoft Defender XDR to handle the incident.
Why it's wrong here
Automatic attack disruption in Microsoft Defender XDR is an active containment capability that, upon detecting an ongoing attack, automatically disables compromised accounts, isolates devices, or contains endpoints. It does not assess Microsoft Entra ID role assignments or adjust the severity property of an already-created Microsoft Sentinel incident. Severity modification requires an automation rule or manual action after incident creation; attack disruption operates at the Defender XDR layer, not on Sentinel's incident metadata.
- ✗
Modify the analytics rule that generates the incident to check user roles during query execution.
Why it's wrong here
Analytics rules execute KQL queries against specified log sources on a schedule, and their configured severity is applied only to new alerts/incidents generated by each query run. Even if the rule's query were modified to join Microsoft Entra ID role information, it cannot retroactively change the severity of an incident that already exists in Sentinel. Additionally, role data often resides in a different data source than the security logs the rule queries, making this approach impractical and not designed for post-creation incident adjustments.
- ✓
Create an automation rule in Microsoft Sentinel triggered on incident creation, which runs a playbook that checks Microsoft Entra ID roles and updates the severity accordingly.
Why this is correct
An automation rule with an incident creation trigger can invoke a playbook that uses Logic Apps and the Microsoft Entra ID connector or Graph API to read the incident's user entity and retrieve their directory role assignments. The playbook can then call the 'Update incident' action to set the severity to a higher value if the user holds a privileged role, such as Global Administrator. This approach is purpose-built for incident lifecycle management and provides real-time, agentless enrichment without altering detection logic.
- ✗
Create a scheduled analytics rule that queries Microsoft Entra ID audit logs and updates incident severity via a watchlist.
Why it's wrong here
A scheduled analytics rule that queries Microsoft Entra ID audit logs would generate new alerts or incidents from that log source; it has no native mechanism to directly update the severity of an existing, unrelated incident. Using a watchlist to map roles would require constant manual or scripted maintenance and would still need an additional playbook or logic app to apply the update, adding delay and complexity. In contrast, an automation rule triggered on incident creation can perform the same role check and severity update more cleanly and immediately.
Go deeper
Related to this question
About these practice questions
Courseiva writes every SC-200 question from scratch — 1,303 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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.