SC-200 Practice Question: A security analyst is investigating an advanced…

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 a self-join: query DeviceProcessEvents for mstsc.exe, extract the target device (e.g., from command line), and then join with another query on DeviceProcessEvents for PowerShell on the target device where the time difference between the events is less than 10 minutes.

  Why this is correct

  This approach correctly models the lateral movement sequence: the mstsc.exe process on the initiating host contains the target device's name or IP in its command line (e.g., mstsc /v:10.0.0.5), so extracting that value and self-joining DeviceProcessEvents back to the target device lets you pivot from the RDP client to the PowerShell process that ran after connection. Adding a time window of less than 10 minutes between the mstsc.exe event on the source and the PowerShell event on the target filters out unrelated script activity, producing a precise correlation that reflects the attack chain. Because both legs are process events from DeviceProcessEvents, the join uses consistent schema (DeviceName, Timestamp, CommandLine) and allows direct association regardless of network port or logon type.

• ✗

  Query DeviceNetworkEvents for RDP connections (port 3389) and then join with DeviceProcessEvents for PowerShell on the same device.

  Why it's wrong here

  Although DeviceNetworkEvents can surface connections to TCP 3389, it only shows the network flow (source IP, destination IP, port) and does not expose which process initiated the RDP session, so you cannot reliably tie the connection to mstsc.exe. Joining those network events with PowerShell on the same device is flawed because the network event exists on one device (the client) but the process creation for PowerShell occurs on the remote target, so a same-device join misses the cross-device lateral movement. This approach also ignores that RDP may be remapped to a non-standard port, and the connection event alone lacks the process lineage needed to confirm the RDP client.

• ✗

  Use the 'union' operator to combine all mstsc.exe and PowerShell events, then summarize by device and time.

  Why it's wrong here

  The union operator simply concatenates rows from multiple tables or queries, so combining all mstsc.exe and all PowerShell events into a single result set does not establish any parent-child or temporal relationship between a specific RDP session and a specific PowerShell launch. After unioning, a summarize by Device and Time collapses the events into aggregates, discarding the one-to-one pairing needed to show that the PowerShell execution on the target immediately followed an mstsc.exe connection from the source. This yields a list of devices that had both processes at some point, but not a validated sequence, leading to false positives and missed correlations.

• ✗

  Query DeviceLogonEvents for RDP logon type and then join with DeviceProcessEvents for PowerShell on the same device.

  Why it's wrong here

  DeviceLogonEvents with RDP (logon type 10) tracks the authentication that happened on the target device, not the client-side mstsc.exe process that initiated the remote session, so it misses the originating host's process activity entirely. Even if you then join to PowerShell on the same device (the target), the logon event's timestamp reflects the logon acceptance, not the RDP client process start, and the join would correlate only events on one endpoint, failing to bridge the source and target. Moreover, RDP logon events may not be generated for every mstsc.exe use (for example, if the session was established via other tools or if the logon was already cached), making this approach incomplete for the scenario.

Go deeper

Related to this question