Manage security and threats by using Microsoft Defender XDR →hardMultiple ChoiceObjective-mapped

MS-102 Practice Question: Manage security and threats by using Microsoft Defender XDR

A security analyst needs to create a custom detection rule in Microsoft 365 Defender that triggers when a suspicious PowerShell process (e.g., using -EncodedCommand) is detected on a device, and within 5 minutes, an outbound network connection to a known malicious IP address occurs. Which two advanced hunting tables must be joined?

⚠ Common exam trap

Candidates often confuse the purpose of DeviceEvents (which covers broader system events like driver loads or registry changes) with DeviceProcessEvents, or mistakenly think cloud or email tables are relevant to endpoint-based process and network correlation.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

DeviceProcessEvents and DeviceNetworkEvents

The custom detection rule requires correlating a suspicious PowerShell process event with a subsequent outbound network connection to a malicious IP within a 5-minute window. DeviceProcessEvents contains process creation data (e.g., command line, process name) for detecting encoded PowerShell commands, while DeviceNetworkEvents logs network connections (destination IP, port, protocol). Joining these two tables on DeviceId and a time range allows the rule to identify the sequence of a process event followed by a network event from the same device.

Answer analysis

Option-by-option breakdown

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

✓
DeviceProcessEvents and DeviceNetworkEvents
Why this is correct
DeviceProcessEvents records the creation of processes with full command-line arguments, capturing activities such as launching PowerShell or other executables. DeviceNetworkEvents logs network connections to remote endpoints, including destination IPs and ports. By joining these tables on DeviceId within a time window, an analyst can identify a specific process making an outbound connection, which is exactly the pattern needed for this custom detection.
✗
DeviceEvents and DeviceFileCertificateInfo
Why it's wrong here
DeviceEvents contains a broad set of system-level events but does not reliably expose process command lines, so it cannot capture the exact PowerShell invocation that triggered the detection. DeviceFileCertificateInfo, on the other hand, stores file authenticity and signing metadata, not network connection records. Together these tables lack both the detailed process execution context and the network connection data required to correlate the activity.
✗
IdentityLogonEvents and CloudAppEvents
Why it's wrong here
IdentityLogonEvents tracks successful and failed sign-ins to cloud identities, while CloudAppEvents captures user and admin activities across Microsoft 365 applications. Both tables are centered on identity and cloud services, not on endpoint telemetry. As a result, they contain no process creation details or device-level network connections, making them unsuitable for detecting this PowerShell-based network behavior.
✗
EmailEvents and EmailAttachmentInfo
Why it's wrong here
EmailEvents provides metadata about email messages processed by your organization, such as sender, recipient, and delivery status, and EmailAttachmentInfo describes files attached to those emails. These tables are designed for email threat hunting and investigate cases like phishing or malware delivery, not for endpoint process or network activity. They cannot reveal whether a local process established a connection or what command line was executed.

Go deeper

MS-102 Practice Question: Manage security and threats by using Microsoft Defender XDR

Why each option matters

Option-by-option breakdown

Related to this question