SC-200 Manage a security operations environment Practice Question
Exhibit
{
"type": "Microsoft.SecurityInsights/automationRules",
"apiVersion": "2023-02-01-preview",
"name": "Auto-Close Low Severity",
"properties": {
"displayName": "Auto-Close Low Severity Incidents",
"order": 1,
"triggeringLogic": {
"conditions": [
{
"conditionProperties": {
"propertyName": "Severity",
"operator": "Equals",
"propertyValues": ["Low"]
},
"conditionType": "Property"
}
],
"triggersOn": "Incidents",
"triggersWhen": "Created"
},
"actions": [
{
"actionType": "ModifyProperties",
"actionConfiguration": {
"status": "Closed",
"classification": "TruePositive",
"classificationComment": "Auto-closed due to low severity."
}
}
]
}
}Refer to the exhibit. You have an automation rule in Microsoft Sentinel configured as shown. An analyst reports that low-severity incidents are not being closed automatically. The rule is enabled and has the highest order. What is the most likely reason?
⚠ Common exam trap
The SC-200 exam often tests the misconception that a rule's order or enabled state is the primary factor, when in fact missing permissions for the automation account cause silent failures in incident modification actions.
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 does not have the required permissions to modify incidents.
The automation rule requires an automation account with Microsoft Sentinel contributor permissions to run playbooks or modify incidents. Without these permissions, the rule cannot close incidents regardless of its order or enabled status. The rule being enabled and having the highest order does not override the missing permissions.
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 rule is triggered by alerts, not incidents.
Why it's wrong here
The exhibit explicitly shows the automation rule's trigger condition as 'When incident created' rather than 'When alert created.' Automation rules in Microsoft Sentinel are independently configurable for incident-trigger and alert-trigger scenarios; this rule was created as an incident-triggered rule, so the alert source is irrelevant. Because the action 'Close incident' is being applied to the incident record, the trigger being incident-based is correct and does not explain the failure.
- ✓
The automation rule does not have the required permissions to modify incidents.
Why this is correct
To close incidents, the automation rule's service identity must hold Microsoft Sentinel Contributor (or a custom role with equivalent write permissions) on the workspace. When the identity lacks those permissions, the automation rule stays enabled and the trigger fires, but the 'Close incident' action fails in the activity log due to Azure RBAC denial. Granting the rule's identity proper Sentinel permissions and retrying the incident will allow the closure to complete.
- ✗
The rule is set to close incidents with classification 'TruePositive' but low-severity incidents are not true positives.
Why it's wrong here
'TruePositive' is simply a closure classification label used by SOC analysts to indicate that the incident was investigated and confirmed as a legitimate security event or threat. Severity is determined by a separate set of criteria, and a low-severity incident can absolutely be a true positive. Selecting that classification does not prevent the incident from being closed; it only documents the investigation outcome.
- ✗
The rule is disabled due to a conflict with another rule.
Why it's wrong here
Automation rules do not get disabled by conflicts with other rules; they are evaluated in priority order based on the 'Order' field, and this rule's order is the highest (lowest numeric value). The rule's status is also explicitly shown as 'Enabled' in the exhibit, so it is still active. If a higher-priority rule performs an action that stops further processing, lower-priority rules may not run, but the higher-priority rule itself remains enabled.
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.