mediumMultiple ChoiceObjective-mapped
SC-200 Practice Question: A SOC analyst wants to automate a response in…
A SOC analyst wants to automate a response in Microsoft Sentinel: whenever an incident is created that contains a compromised user entity (e.g., a user whose credentials were used in a breach), a playbook should run to disable that user in Microsoft Entra ID. Which condition should be configured in the automation rule to trigger this playbook?
⚠ Common exam trap
Many exam-takers confuse 'Account' with 'User' or assume 'IP' is sufficient for user compromise, but Microsoft Sentinel uses the specific entity type 'Account' for user identities, and the automation rule condition must match exactly that type to trigger the playbook correctly.
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
✓
Set the condition to 'When incident is created with entity type Account'.
The automation rule must trigger when an incident is created with an entity type of 'Account' to match the compromised user entity. In Microsoft Sentinel, a user whose credentials were used in a breach is represented as an 'Account' entity, not an 'IP' or 'Host'. The playbook to disable the user in Microsoft Entra ID requires this entity type to pass the user principal name (UPN) or object ID to the action.
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 trigger to 'When incident is created' with no additional condition.
Why it's wrong here
Setting the trigger to 'When incident is created' with no additional condition executes the playbook for every incident that Microsoft Sentinel generates, regardless of whether the incident contains an Account entity. This not only wastes compute and licensing resources but also forces the playbook to run on incidents that have no user account to disable, potentially causing errors or unnecessary API calls. Best practice for automation rules is to filter at the condition level so that only incidents with the relevant entity type reach the playbook, ensuring efficient and targeted response.
- ✗
Set the condition to 'When incident is created with entity type IP'.
Why it's wrong here
The condition 'When incident is created with entity type IP' targets network addresses, not the user account that needs to be disabled. In Sentinel's entity schema, IP represents a host or network device, whereas a compromised user alert typically contains an Account entity (with attributes like UPN or domain). If you use IP, the playbook will fail to match incidents that have a user entity but no IP entity (or a different IP), so the compromised account remains enabled and the automated response never triggers.
- ✓
Set the condition to 'When incident is created with entity type Account'.
Why this is correct
Selecting 'When incident is created with entity type Account' is the correct and precise condition because the Account entity type in Microsoft Sentinel represents user accounts, including the attributes needed to disable a user (e.g., user principal name, NT domain, or account SID). This condition ensures the playbook runs only on new incidents that actually contain a compromised user entity, directly aligning with the SOC analyst's goal of disabling that user. It avoids the extra latency and noise of an unscoped trigger while guaranteeing the playbook receives the necessary entity data to perform the account triage.
- ✗
Set the condition to 'When incident is updated with entity type Host'.
Why it's wrong here
Choosing 'When incident is updated with entity type Host' has two critical flaws: it triggers on updates rather than creation, so the playbook runs only after the incident has already been modified (potentially after the account has caused damage), and it looks for a Host entity (a device or server) instead of an Account entity (the user). Since the action is to disable a compromised user, the playbook must fire immediately on incident creation and match the Account entity; otherwise the automation is both mis-timed and mis-targeted, and it may run repeatedly on every update of unrelated incidents.
Go deeper
Related to this question
About these practice questions
Courseiva writes every SC-200 question from scratch — 209 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 →
Same concept, more angles
1 more way this is tested on SC-200
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A SOC analyst wants to automate a response in Microsoft Sentinel such that whenever an incident is created containing a specific user entity (e.g., compromised user), a playbook runs that disables the user in Microsoft Entra ID. Which condition should be configured in the automation rule?
medium- ✓ A.When incident is created, and the incident contains a user entity.
- B.When alert is generated, and the alert contains a user entity.
- C.When incident is created with severity high, then run the playbook.
- D.When playbook is triggered manually from the incident details page.
Why A: The automation rule must trigger on incident creation and evaluate whether the incident contains a specific user entity to run the playbook that disables the user in Microsoft Entra ID. This ensures the playbook only executes when the relevant entity is present, aligning with the requirement to automate a response based on a compromised user entity.
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.