AZ-500 Manage identity and access Practice Question
A security team uses Microsoft Sentinel. They create a scheduled analytics rule that queries Azure Activity Logs to detect virtual machines deployed in non-approved regions. The rule generates an incident. The team wants the incident to be automatically assigned to the 'Infrastructure' team and its severity set to 'High' when it is created. Which automation feature should they use?
⚠ Common exam trap
Watch out — candidates often confuse playbooks (which are triggered by alerts and require Logic Apps) with automation rules (which are triggered by incident lifecycle events and are simpler to configure), leading them to select Option B instead of the correct automation rule approach.
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 with trigger 'When incident is created' and actions to assign the incident to an owner and set severity
Automation rules in Microsoft Sentinel allow you to define triggers such as 'When incident is created' and then perform actions like assigning the incident to an owner and setting its severity. This is the native, no-code way to automate incident management without requiring a playbook or modifying the analytics rule itself.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Create an automation rule with trigger 'When incident is created' and actions to assign the incident to an owner and set severity
Why this is correct
Automation rules in Microsoft Sentinel are the native, low-latency mechanism for incident lifecycle operations, and the 'When incident is created' trigger fires within seconds of an incident being generated by an analytics rule. By specifying actions that assign an owner and set severity, the rule applies these changes deterministically and immediately, without requiring a playbook to be invoked. This is the recommended and simplest way to ensure the incident appears in the SOC queue with the correct owner and severity from the very first moment.
- ✗
Create a playbook triggered by alert creation that performs the assignment and severity change
Why it's wrong here
While playbooks are excellent for automating response actions like updating incident properties, they are triggered *after* an incident has already been created. This scenario requires the assignment and severity to be set *at the moment of incident creation*, which is a function of the analytics rule's built-in settings, not a post-creation automation. Playbooks are tempting because they are the go-to for complex, multi-step incident enrichment and response workflows, and would be the correct choice if the requirement was to modify an incident *after* it had already been generated by the rule.
- ✗
Use an automation rule with trigger 'When incident is updated' and condition on alert type
Why it's wrong here
The 'When incident is updated' trigger in an automation rule is designed to react to changes to an already-existing incident, such as a status change or comment addition; it does not fire on the initial creation event. Because a scheduled analytics rule creates an incident with its default severity and no owner, waiting for an update means the incident will be visible to analysts in an incomplete state, potentially triggering other workflows or triage actions based on that missing metadata. To set owner and severity at the exact moment of creation, a 'When incident is created' trigger is required, not an update trigger.
- ✗
Configure the analytics rule directly to set severity and owner
Why it's wrong here
While a scheduled analytics rule does include a static Severity field that determines the initial severity for all incidents it creates, it has no capability to assign an incident owner — ownership is an operational property applied only after incident generation. Moreover, the rule's severity is a fixed value set at configuration time; it cannot apply conditional logic or update severity based on alert details or entity context at runtime. Thus, configuring the analytics rule directly cannot satisfy the requirement to both assign an owner and conditionally set severity, making automation rules the necessary solution.
Go deeper
Related to this question
About these practice questions
One of 617 original AZ-500 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 AZ-500 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 AZ-500 exam.