SC-200 Manage a security operations environment Practice Question
Which TWO tasks can you perform using Microsoft Sentinel automation rules?
⚠ Common exam trap
Many candidates confuse automation rule capabilities with playbook actions, assuming email notifications or deletions are possible natively, but Microsoft Sentinel restricts automation rules to incident property changes and playbook triggers only.
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
✓
Assign an incident to an analyst.
Automation rules in Microsoft Sentinel can directly assign incidents to specific analysts or groups without requiring a playbook. This is a native action within the automation rule configuration, enabling immediate ownership and accountability for incident response.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Send an email notification without a playbook.
Why it's wrong here
Automation rules cannot natively send email; their built-in actions are limited to changing incident properties, adding tags, assigning ownership, and invoking playbooks. Any email notification must be implemented as a playbook action, typically using the Office 365 Outlook connector within an Azure Logic App, because the automation rule itself has no direct messaging capability.
- ✓
Assign an incident to an analyst.
Why this is correct
Automation rules support the "Assign owner" action, which lets you set the incident's owner to a specific analyst, a group, or a user by email address. This action can be triggered when an incident is created or updated based on conditions such as severity or analytics rule, thereby enabling systematic incident triage and routing directly from the rule.
- ✗
Delete an incident.
Why it's wrong here
Microsoft Sentinel automation rules do not expose a "delete" action for incidents. Incidents are not meant to be permanently removed; they remain in the workspace for audit, investigation, and compliance. To handle unwanted or false-positive incidents, you should use the "Change status" action to set them to Closed with an appropriate classification, preserving the record instead of deleting it.
- ✓
Change the severity of an incident.
Why this is correct
One of the supported automation rule actions is "Change severity," which modifies the incident's severity property (for example, from Medium to High) either manually or through automated conditions. This allows dynamic prioritization without analyst intervention, such as escalating incidents containing a critical user or resource, and the change is reflected in the incident queue and any subsequent automation rule evaluations.
- ✗
Create a new analytics rule.
Why it's wrong here
Creating an analytics rule is not an action available in automation rules; analytics rules are defined independently in the Analytics blade or via API, ARM templates, and Microsoft Defender XDR. Automation rules operate only on incidents and alerts that already exist, orchestrating responses to them—they cannot author detection logic, schedule queries, or generate new analytics rule definitions.
Go deeper
Related to this question
About these practice questions
One of 1,303 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 →
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.