SC-200 Respond to security incidents Practice Question

Answer analysis

Option-by-option breakdown

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

• ✓

  Remove external sharing permissions on SharePoint sites.

  Why this is correct

  In the context of a Sentinel incident, external sharing on SharePoint sites is a common data exfiltration vector when accounts are compromised. Removing external sharing permissions—via the SharePoint admin center or PowerShell cmdlets like Set-SPOTenant -SharingCapability—immediately revokes external users' ability to access shared links, cutting off the attacker's current path to exfiltrate data. This is a direct containment action at the data plane, and it is crucial to perform before or alongside user-level blocking to stop exfiltration that has already been enabled.

• ✓

  Block the user account in Microsoft Entra ID.

  Why this is correct

  Blocking the user account in Microsoft Entra ID—using the 'Block sign-in' setting or Revoke-MgUserSignInSession—is an immediate control-plane containment that prevents the compromised principal from authenticating to any Microsoft 365 resource. This is faster and more comprehensive than a password reset because it doesn't rely on the user performing an action, and it invalidates the attacker's ability to use stolen credentials for new token requests. Existing active sessions may persist until token expiry, so combine with session revocation for full effect, but sign-in blocking remains the first and most decisive move.

• ✗

  Reset the user's password and enforce MFA.

  Why it's wrong here

  Resetting the user's password and enforcing MFA is a good post-incident recovery action, but it is not the most immediate containment step. A password reset alone does not invalidate existing refresh tokens or access sessions, and the attacker may have already registered their own MFA device or created persistence mechanisms like OAuth grants. MFA enforcement can take time to propagate across services and requires user coordination, whereas blocking the account or isolating the device stops activity instantly. In an active incident, this option is therefore correct only as a follow-up, not as the primary response.

• ✓

  Isolate the user's device using Microsoft Defender for Endpoint.

  Why this is correct

  Isolating the user's device with Microsoft Defender for Endpoint—via the 'Isolate device' action—severs all network communication from that endpoint to external hosts, except for the Defender service itself. This is a strong containment measure when the incident involves a compromised device performing data exfiltration or lateral movement. However, it only covers the endpoint; it does not affect cloud-resident data like SharePoint external sharing links, so it must be paired with cloud-level containment (e.g., blocking the user and removing shared permissions) to fully stop the leak.

• ✗

  Create a custom detection rule for similar activity.

  Why it's wrong here

  Creating a custom detection rule for similar activity is a valuable step after an incident, but it is not an immediate containment action. Writing and deploying a Sentinel analytics rule does not stop the current attacker's active access or reduce the blast radius; it only helps detect future recurrences. Immediate response should prioritize blocking the user, isolating the device, and revoking sharing permissions. This option belongs in the post-incident review phase, so it is incorrect as an immediate response.

Go deeper

Related to this question