SC-200 Manage a security operations environment Practice Question
Exhibit
{
"properties": {
"displayName": "SOC Automation Rules",
"rules": [
{
"name": "High Severity Incidents",
"description": "Assign incidents with severity High to tier1 group and run a playbook.",
"actions": [
{ "order": 1, "actionType": "AddIncidentTask", "taskName": "Notify SOC Lead" },
{ "order": 2, "actionType": "RunPlaybook", "logicAppResourceId": "/subscriptions/.../resourceGroups/.../providers/Microsoft.Logic/workflows/NotifySOC" },
{ "order": 3, "actionType": "ModifyIncident", "status": "Active", "owner": "SOC-Tier1@contoso.com" }
]
}
]
}
}Refer to the exhibit. An automation rule in Microsoft Sentinel is configured as shown. When a high-severity incident is created, what is the expected behavior?
⚠ Common exam trap
Candidates often assume all actions in an automation rule execute independently and ignore the specific formatting requirements for the incident owner field, leading them to select Option A or D.
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 task is created, then the playbook runs, but the incident modification fails because the owner is incorrectly formatted.
The automation rule in Microsoft Sentinel executes actions sequentially. The task creation and playbook run succeed, but the incident modification fails because the owner field is incorrectly formatted. Sentinel expects the incident owner to be specified as a user principal name (UPN) or object ID, not a plain text string like 'SOC-Tier1'.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
All actions execute successfully: task created, playbook runs, incident owner set to SOC-Tier1.
Why it's wrong here
The action sequence in Microsoft Sentinel executes top to bottom, so the task creation and playbook trigger do complete, but the incident-owner modification cannot succeed because 'SOC-Tier1' is neither a user principal name nor an object ID in Microsoft Entra ID. Sentinel's owner property only accepts valid Entra ID identities, and arbitrary strings such as a team name or display name are rejected. Therefore, the claim that all three actions succeed is false.
- ✗
The rule fails to run because the actions are not in valid JSON format.
Why it's wrong here
The rule is not invalid JSON; the payload parses correctly and the automation engine accepts it before runtime execution. The 'owner' value is a semantic error, not a syntax error — valid JSON with an invalid owner string causes a runtime failure only when the modify action attempts to resolve the identity. Thus the rule does run, but this option mischaracterizes the failure mode as a JSON formatting issue.
- ✓
The task is created, then the playbook runs, but the incident modification fails because the owner is incorrectly formatted.
Why this is correct
The automation rule successfully creates the task and triggers the playbook as configured. However, Microsoft Sentinel requires incident owners to be valid Microsoft Entra ID user principal names or object IDs. If the automation rule's configuration for setting the incident owner specifies an incorrectly formatted value, such as an arbitrary string that does not correspond to a recognised identity, the attempt to modify the incident's owner property will fail. This specific constraint on owner format causes the modification failure, even if other actions succeed.
- ✗
The playbook runs first, then the task is created, then the incident is modified.
Why it's wrong here
Automation rule actions execute in the explicit order of the actions array — here the shown configuration lists task creation first, then playbook, then incident modification — so the playbook does not run first. The stated order would occur only if the actions were rearranged in the rule, which is not the case in the exhibit. Because the sequence is enforced by the rule's action list, this option contradicts the actual execution flow.
Go deeper
Related to this question
About these practice questions
One of 673 original SC-200 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
Same concept, more angles
4 more ways 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. You are configuring Microsoft Sentinel automation rules to handle incidents from multiple analytics rules. You need to ensure that incidents from a specific rule are automatically assigned to the 'SOC Tier 2' group and have a severity of 'High' regardless of the original severity. What should you do?
hard- A.Use a logic app trigger to change severity
- B.Create a playbook to modify the incident properties
- C.Create a separate analytics rule to override the incident
- ✓ D.Configure an automation rule with 'Add tag' and 'Set severity' actions, plus 'Assign owner'
Why D: Automation rules in Microsoft Sentinel can directly modify incident properties such as severity and owner without requiring external logic apps or playbooks. Option D correctly uses the 'Set severity' action to override the original severity to 'High' and the 'Assign owner' action to assign the incident to the 'SOC Tier 2' group, fulfilling both requirements in a single, efficient rule.
Variation 2. Refer to the exhibit. You are creating an automation rule in Microsoft Sentinel. The rule is enabled but does not assign incidents. What is the most likely issue?
hard- ✓ A.The action 'AssignIncident' is not a supported automation rule action.
- B.The condition 'Owner' property does not support 'Equals' operator.
- C.The trigger type 'Microsoft.SecurityInsights/Incident' is incorrect.
- D.The 'assignedTo' value should be a user principal name instead of an email alias.
Why A: The 'AssignIncident' action is not a supported action type in Microsoft Sentinel automation rules. Automation rules support only 'Run Playbook' and 'Change Status' actions; incident assignment must be done via playbooks or manually, not directly within an automation rule.
Variation 3. Refer to the exhibit. You are reviewing an automation rule in Microsoft Sentinel. What will happen when a new incident is created?
medium- A.The incident severity will be changed
- B.A new analytics rule will be created
- ✓ C.The playbook 'BlockIPPlaybook' will be executed
- D.The incident will be automatically closed
Why C: The automation rule is configured to trigger a playbook when an incident is created. The rule's action specifies 'Run playbook' with 'BlockIPPlaybook' selected, and the trigger condition is set to 'When incident is created'. This means that upon incident creation, Sentinel will execute the playbook as an automated response.
Variation 4. Refer to the exhibit. You are reviewing an automation rule in Microsoft Sentinel. What is the effect of this rule?
easy- A.It assigns the incident to the SOC team.
- ✓ B.It changes the status of newly created incidents from 'New' to 'Active'.
- C.It suppresses the incident if it is a false positive.
- D.It creates a task in the incident for investigation.
Why B: The automation rule is configured to run when an incident is created, and the action taken is to change the incident status from 'New' to 'Active'. This is a common initial triage step to indicate that the incident is being worked on, rather than leaving it in the default 'New' state. The rule does not assign ownership, suppress incidents, or create tasks.
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.