SC-200 Practice Question: A security analyst is using advanced hunting in…

Answer analysis

Option-by-option breakdown

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

• ✓

  Use DeviceLogonEvents and DeviceNetworkEvents with a join on DeviceId and a time range

  Why this is correct

  DeviceLogonEvents records successful interactive and remote logons to a machine, including the target DeviceId, the authenticating account, and the source device/IP. DeviceNetworkEvents logs outbound connection attempts from that same device, with destination IP and port. By joining on DeviceId and filtering to the short time window after the logon record—especially while looking for destination port 3389 or other RDP ports—you can link the account that just logged on to an immediate outbound RDP connection from that device to another host, which is a classic lateral-movement indicator.

• ✗

  Use IdentityLogonEvents and DeviceNetworkEvents with a join on IP address

  Why it's wrong here

  IdentityLogonEvents is populated by Azure Active Directory sign-in logs for cloud apps, not by interactive or network logons to endpoint devices, so it lacks the DeviceId and LogonType fields needed to trace a user moving from one workstation to another. Additionally, joining on IP address is unreliable in enterprise networks because of NAT, DHCP, and multiple users sharing a public or internal IP. Even if a cloud sign-in and a network connection share an IP, that correlation does not prove an RDP-based lateral movement between managed devices; it only shows cloud authentication activity.

• ✗

  Use DeviceProcessEvents and DeviceNetworkEvents with a join on DeviceId

  Why it's wrong here

  DeviceProcessEvents captures process creation activities, such as mstsc.exe or cmd.exe launching, which certainly occur during many intrusion chains, but those events do not carry the authentication details—like LogonType, target account, and source device—that prove a successful interactive logon happened on the remote host. Moreover, joining process events to DeviceNetworkEvents on DeviceId only tells you that a process on that device made a connection; it doesn't tell you whether that connection led to an authenticated session on the destination. Relying on process creation can also produce excessive noise because normal administrative work routinely spawns remote-management processes, whereas DeviceLogonEvents gives you the authoritative record of the actual logon.

• ✗

  Use EmailEvents and DeviceLogonEvents with a join on RecipientEmail

  Why it's wrong here

  EmailEvents tracks email message metadata like sender, recipients, delivery status, and attachment verdicts; it contains no endpoint identifiers such as DeviceId and no network connection fields, so there is no logical schema to join it to DeviceLogonEvents for lateral movement analysis. The RecipientEmail field in EmailEvents is an SMTP address, while DeviceLogonEvents doesn't contain that address for local logons, making the join result empty or meaningless. Additionally, lateral movement is an endpoint and network phenomenon, and email events would only be relevant if you were investigating phishing as an initial-access vector, not for post-compromise movement between workstations.

Go deeper

Related to this question