SC-200 Practice Question: A security analyst is investigating a phishing…

Answer analysis

Option-by-option breakdown

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

• ✓

  EmailEvents

  Why this is correct

  EmailEvents is the correct table because it is the primary Microsoft 365 Defender email metadata store, containing the sender address (SenderFromAddress/SenderDisplayName), recipient (RecipientEmailAddress), subject, and delivery status/actions such as Phish or Junk. In a phishing campaign investigation, you start here to identify which mailboxes received the malicious message and to correlate the sender and delivery outcome. It also fields like ThreatTypes and DetectionMethods, making it the authoritative source for the core message flow. Without querying EmailEvents, you cannot establish the baseline scope of the campaign.

• ✗

  EmailAttachmentInfo

  Why it's wrong here

  EmailAttachmentInfo is wrong because it stores attachment-specific details—SHA256 hash, file name, file size, and detection verdict for the attached file—but it does not contain the sender's email address or recipient information. In a phishing investigation, you would join EmailAttachmentInfo to EmailEvents via NetworkMessageId to get context, but the attachment table alone cannot tell you who sent the email or to whom. It is useful for hunting malicious files, not for identifying the sender. Therefore, while it supports the investigation, it is not the correct answer for finding sender and recipient info.

• ✗

  EmailUrlInfo

  Why it's wrong here

  EmailUrlInfo is wrong because it contains the URLs extracted from the email body or links, including the URL domain, full URL, and detection state, but it has no sender or recipient fields. This table is critical for analyzing phishing links and determining whether a user clicked a malicious URL (via matching with UrlClickEvents), but it does not answer the question of who sent the email. It is a secondary enrichment table that requires EmailEvents for context. Thus, it is irrelevant to identifying the source sender of a phishing campaign unlike EmailEvents.

• ✗

  DeviceEvents

  Why it's wrong here

  DeviceEvents is wrong because it captures endpoint behavior such as process creation, file creation, registry modifications, and network connections on individual devices, not email transport metadata. It is the core table for endpoint detection and response (EDR) investigations, used to identify post-compromise activity—for example, when a user opens a malicious attachment and the payload executes. It has no email sender, recipient, or subject fields, so it cannot help determine who sent the phishing email. In a phishing campaign, DeviceEvents becomes relevant only after the user has interacted with the email, not for the initial email metadata.

Go deeper

Related to this question