Manage a security operations environment →easyMultiple Choice

SC-200 Manage a security operations environment Practice Question

A security operations center (SOC) uses Microsoft Sentinel. They want to automatically block a user's account when a high-severity incident is created. Which automation action should you use in a playbook?

⚠ Common exam trap

It's easy for candidates to confuse 'blocking a user' with temporary measures like revoking sessions or resetting passwords, but only disabling the account (via Graph API) permanently prevents authentication until the account is re-enabled.

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

✓

Run a playbook that calls the Microsoft Graph API to disable the user account.

Disabling the user account via Microsoft Graph API is the most direct and effective way to prevent further access when a high-severity incident is created. This action immediately blocks the user from authenticating across all services, which aligns with the requirement to automatically block the account. Other options either do not block the account (e.g., revoking sessions or resetting password) or are indirect and less reliable (e.g., updating Conditional Access policies).

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Run a playbook that revokes the user's current sessions using Microsoft Graph API.
Why it's wrong here
Revoking a user's sessions with the Microsoft Graph API call `revokeSignInSessions` invalidates the user's existing refresh tokens, but it does not change the state of the user account. The user remains enabled, so any attacker who has the credentials or a compromised device can simply sign in again and receive new tokens. This is a transient containment measure rather than a persistent block.
✗
Run a playbook that resets the user's password.
Why it's wrong here
Resetting the user's password in Microsoft Entra ID changes the credential, but it does not automatically revoke access tokens or refresh tokens that have already been issued to the user. It also does not disable the account or invalidate other authentication methods such as registered devices or application passwords. If the attacker has already established persistence or compromised additional factors, password reset may fail to block access.
✓
Run a playbook that calls the Microsoft Graph API to disable the user account.
Why this is correct
A Microsoft Sentinel playbook, powered by Azure Logic Apps, can directly interact with Microsoft Entra ID to manage user accounts. By calling the Microsoft Graph API within the playbook, specifically the Users endpoint to update a user's properties, the `accountEnabled` attribute can be set to `false`. This precise technical mechanism allows the playbook to automatically disable the user account in Microsoft Entra ID, directly fulfilling the requirement to block the user's account upon a high-severity incident.
✗
Run a playbook that updates a conditional access policy in Microsoft Entra ID.
Why it's wrong here
Updating a conditional access policy in Microsoft Entra ID is an indirect and delayed control because changes must propagate across the directory and are evaluated on the next sign-in, not in real time. Existing sessions are typically not terminated when a policy changes, and the policy itself is not scoped to immediately disable a specific user account. This makes it unsuitable when the SOC needs an immediate block upon a high-severity Sentinel incident.

Go deeper

SC-200 Manage a security operations environment Practice Question

Why each option matters

Option-by-option breakdown

Related to this question