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.

• ✗

  Block the user from signing in

  Why it's wrong here

  Blocking the user from signing in is a containment action that should be applied only after the sign-in has been confirmed as malicious. If the sign-in is actually legitimate—for example, a user on a new device or from a new location—a premature block will cause unnecessary operational disruption and may tip off the user to an ongoing incident investigation. Furthermore, applying an account lock without first reviewing sign-in logs could delete active session evidence or obscure the true root cause, violating the 'identify before contain' principle in incident response.

• ✗

  Force a password reset for the user

  Why it's wrong here

  Forcing a password reset without first confirming the account is genuinely compromised is dangerous because it can alert an active attacker who may still hold session tokens or a persistent backdoor, prompting them to escalate privileges or exfiltrate data quickly. Even if reset is justified, it is not a complete remediation: an attacker with a stolen refresh token may remain authenticated unless sessions and tokens are explicitly revoked. Proper triage requires examining sign-in logs, risk indicators, and authentication factors before taking credential-based remediation steps.

• ✗

  Check if the device used is managed by Intune

  Why it's wrong here

  Checking whether the device is managed by Intune provides only a single contextual attribute and does not confirm or deny account compromise. A device can be Intune-managed and compliant while the sign-in originates from an attacker who has compromised the user's credentials or stolen a session token on that very device; conversely, a user on a personal, non-managed device could trigger a false positive alert. The decisive evidence is whether the sign-in behavioral characteristics—IP geolocation, user agent, time, frequency, and risk score—match the user's established baseline, not merely the device's enrollment status.

• ✓

  Review the sign-in details and compare with the user's typical behavior

  Why this is correct

  Reviewing the sign-in details and comparing them with the user's typical behavior is the correct initial triage action because Entra ID sign-in logs contain rich data—client IP, latitude/longitude, user agent, authentication method, device ID, and risk labels (e.g., impossible travel, unfamiliar sign-in properties, anonymized IP)—that can be correlated against the user's historical baseline. This behavioral analytics approach validates whether the sign-in is truly anomalous before any containment steps are taken, which is consistent with the 'identify-scope-contain' incident response lifecycle. Without this evidence-based review, actions like resetting credentials or blocking the account would be premature and potentially misguided, either disrupting a legitimate sign-in or failing to address a real compromise.

Go deeper

Related to this question