Manage identity and access →mediumMultiple Choice

AZ-500 Manage identity and access Practice Question

A security team uses Microsoft Sentinel. They want to automatically block a user's account in Microsoft Entra ID when a high-severity incident is created in Sentinel indicating the user's credentials are compromised. Which automation feature should they use?

⚠ Common exam trap

It's easy for candidates to think analytic rules can include scripts or that Sentinel has a native user-blocking toggle, but in reality, automated response requires a separate playbook triggered by an automation rule.

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 a playbook that uses the Microsoft Entra ID connector to block the user, and associate it with an automation rule for high-severity incidents.

Microsoft Sentinel automation rules can trigger a playbook (an Azure Logic Apps workflow) when a high-severity incident is created. The playbook can use the Microsoft Entra ID connector to call the Microsoft Graph API and block the user account, providing automated response to credential compromise without manual intervention.

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 a playbook that uses the Microsoft Entra ID connector to block the user, and associate it with an automation rule for high-severity incidents.
Why this is correct
Microsoft Sentinel playbooks are Logic Apps-based workflows that execute response actions. By using the Microsoft Entra ID (Entra ID) connector, a playbook can call a user-blocking action such as disabling the user account via the 'Update user' or the dedicated 'Block user' action. Automation rules evaluate incident properties (e.g., severity, entity) and can automatically trigger the playbook when a high-severity incident is created, providing a fully automated containment response.
✗
Configure the analytic rule for credential compromise to include a script that blocks the user as part of the rule.
Why it's wrong here
Analytic rules in Microsoft Sentinel are built on KQL queries and simply generate alerts or incidents when query results match; they have no execution engine for arbitrary scripts or PowerShell commands. There is no configuration field or mechanism within an analytic rule to run a 'block user' script as part of rule evaluation. Attempting to embed such actions would violate the rule's design and would not work.
✗
Use a workbook to monitor incidents and manually block users.
Why it's wrong here
Azure Workbooks in Sentinel are interactive dashboards that aggregate data from Log Analytics for monitoring, hunting, and reporting. They are read-only visualization tools and cannot invoke API calls, modify Microsoft Entra ID objects, or enforce security actions such as blocking a user. Relying on a workbook for manual blocking would also add human delay, but the core issue is that workbooks are not an automation or remediation surface at all.
✗
Enable the 'User blocking' feature directly in the Microsoft Sentinel settings for all high-severity incidents.
Why it's wrong here
Microsoft Sentinel does not expose a native setting or toggle called 'User blocking' in its configuration blade. Sentinel is a SIEM/SOAR platform that relies on playbooks and connectors for response actions; account-level blocking is not a built-in capability that can be applied to all high-severity incidents. Enabling such a feature is impossible because the setting does not exist, and any user-blocking logic must be custom-built in Logic Apps.

Go deeper

AZ-500 Manage identity and access Practice Question

Why each option matters

Option-by-option breakdown

Related to this question