AZ-500 Practice Question: Secure Azure using Microsoft Defender for Cloud and Microsoft Sentinel
You are a security engineer for Contoso Ltd. The company has a hybrid environment with Azure VMs and on-premises servers running Windows Server 2022. You have enabled Microsoft Defender for Cloud's multi-cloud posture management for AWS and GCP. Recently, you deployed Microsoft Sentinel in a Log Analytics workspace named 'ContosoWorkspace'. The security team needs to centralize security alerts from all sources: Azure, on-premises, AWS, and GCP. They also require automated investigation and response for common threats. Specifically, they want to automatically disable a compromised user account when a high-severity alert is generated. You have configured data connectors for Azure Activity, Microsoft Entra ID, and AWS CloudTrail. For on-premises servers, you installed the Azure Monitor Agent (AMA) and enabled Defender for Cloud's plan for servers. For GCP, you are using the GCP Security Command Center connector. The team needs to create a playbook that runs when a high-severity alert from any source is triggered. The playbook should disable the user account in Microsoft Entra ID. You have created a playbook using Azure Logic Apps and granted it the necessary permissions. Which step should you take to ensure the playbook runs automatically when alerts are generated?
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 in Microsoft Sentinel that triggers the playbook when a high-severity alert is created.
The correct option is A: create an automation rule in Microsoft Sentinel that triggers the playbook when a high-severity alert is created. Automation rules in Microsoft Sentinel are the native mechanism for automatically invoking playbooks (Logic Apps) in response to incidents or alerts, and they can filter by severity so the playbook runs only for high-severity alerts. Option B is wrong because automation rules in Microsoft Defender for Cloud govern Defender for Cloud alerts and cannot directly trigger a Sentinel playbook for alerts from all connected sources. Option C is wrong because analytics rules generate alerts/incidents from ingested data; they do not trigger playbooks. Option D is wrong because a scheduled Logic App polling Sentinel would not provide the required automatic, event-driven response when an alert is generated.
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 in Microsoft Sentinel that triggers the playbook when a high-severity alert is created.
Why this is correct
In Microsoft Sentinel, automation rules are the native mechanism for executing a playbook when an incident or alert is generated; you configure a condition such as 'Alert severity equals High' and an action of 'Run playbook' on the selected Logic App. This triggers immediately at alert creation time, without requiring polling or scheduled jobs. It is the correct and recommended approach for real-time response to high-severity Sentinel alerts.
- ✗
Create an automation rule in Microsoft Defender for Cloud that triggers the playbook when a high-severity alert is generated.
Why it's wrong here
Defender for Cloud's workflow automation feature can invoke a Logic App in response to Defender for Cloud security alerts, but it is scoped to Defender for Cloud's alert generation pipeline, not to alerts created by Microsoft Sentinel analytics rules. Sentinel alerts are separate and are not surfaced as Defender for Cloud alerts unless you explicitly stream them through a connector, which is not the standard architecture here. Therefore, this automation rule would not fire for the Sentinel-created high-severity alerts.
- ✗
Create an analytics rule in Microsoft Sentinel that triggers the playbook when a high-severity alert is created.
Why it's wrong here
An analytics rule in Microsoft Sentinel is a query-based rule that ingests data and creates an alert when the query matches, but it does not have the capability to execute a playbook or any orchestration action. Playbooks are executed by automation rules, which listen for alert or incident creation events and then run the Logic App. Confusing the two rule types is a common error; the analytics rule is only the detection mechanism, not the response mechanism.
- ✗
Configure the Logic App to run on a schedule and query Sentinel for high-severity alerts.
Why it's wrong here
Setting the Logic App to run on a scheduled trigger that queries Sentinel for high-severity alerts is not event-driven and introduces unavoidable delay between alert creation and the playbook execution, which defeats the purpose of immediate response. Additionally, this approach requires custom KQL queries and job scheduling logic, whereas an automation rule handles the trigger condition natively. For a real-time incident response requirement, a schedule-based polling pattern is an inferior and incorrect alternative.
Go deeper
Related to this question
About these practice questions
This AZ-500 question is part of Courseiva's 617-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 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.