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.

• ✗

  Create an anti-spam policy to block the sender's domain.

  Why it's wrong here

  Anti-spam policies in Exchange Online Protection evaluate message characteristics such as sender reputation, content, bulk-mail settings, and sending patterns to assign a spam verdict. Blocking the sender's domain through such a policy only affects mail originating from that specific domain; it does nothing to neutralize a malicious URL embedded in the message, and attackers can simply pivot to another sending domain or a compromised legitimate domain. URL-level protection requires a policy that inspects hyperlinks at click time, which Safe Links provides.

• ✓

  Create a Safe Links policy and add the malicious domain to the blocked URLs list.

  Why this is correct

  Safe Links policies are specifically designed to protect users from malicious hyperlinks by rewriting URLs and checking them against Microsoft's threat intelligence plus your custom block list. Adding the malicious domain to the blocked URLs list causes any link containing that domain to be blocked or to trigger a warning when clicked, even if the email's sender appears benign. This directly addresses the attack vector—the embedded URL—rather than the email's origin, making it the correct control.

• ✗

  Create an anti-malware policy to block the attachment type.

  Why it's wrong here

  Anti-malware policies in Defender for Office 365 scan email attachments for file-based threats, including known malware signatures and behavior during detonation, but they cannot inspect or act on hyperlinks embedded directly in the message body. Because a malicious URL is not an attachment, the anti-malware engine never evaluates it, so this policy would leave the user fully exposed to the link. Safe Links is the feature that provides URL reputation and click-time protection.

• ✗

  Add the sender's domain to the Tenant Allow/Block List.

  Why it's wrong here

  The Tenant Allow/Block List is a transport-level allow/deny mechanism that governs mail flow based on sender, domain, or spoofed identity; adding the sender's domain there would block or suppress all mail from that domain. However, the attack is the malicious link itself, which could originate from an unlisted domain or a legitimate but compromised sender, so the block list entry would not remove the dangerous URL from messages that do arrive. Safe Links is the right control because it evaluates the URL object, not the sender identity, and can enforce protection on every link regardless of where the mail came from.

Go deeper

Related to this question