SC-200 Perform threat hunting 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.

• ✗

  CloudAppEvents

  Why it's wrong here

  CloudAppEvents in Microsoft 365 Defender records activities that users perform in cloud applications after successful authentication, such as file access, permission changes, and admin operations. While it may include some sign-in-related entries, it is not the authoritative source for raw authentication attempts against a cloud app because its schema is optimized for post-logon behaviors. For a hunt specifically looking for authentication events, querying IdentityLogonEvents would return the complete, normalized logon data.

• ✗

  DeviceLogonEvents

  Why it's wrong here

  DeviceLogonEvents is part of the Microsoft Defender for Endpoint advanced hunting schema and captures logon sessions to Windows endpoints, including interactive, remote, and network logons. These events are tied to the local machine or on-premises Active Directory domain, not to authentication requests sent to a cloud identity provider such as Microsoft Entra ID. Since the threat hunt targets cloud application authentications, this table would completely overlook the relevant events and is therefore unsuitable.

• ✓

  IdentityLogonEvents

  Why this is correct

  IdentityLogonEvents is the correct table because it is specifically designed to capture authentication events to applications using Microsoft Entra ID (Azure AD). Each row represents a user authentication attempt to a cloud app, with details such as the target application, logon type, protocol, and whether the attempt succeeded or failed. This directly matches the requirement to find instances of authentication to a cloud application, making it the authoritative source for this hunt.

• ✗

  AlertInfo

  Why it's wrong here

  AlertInfo contains metadata about security alerts generated by detection rules, including alert titles, severity, and MITRE ATT&CK tactics, but it does not store raw authentication events themselves. While an alert might indicate suspicious authentication activity, querying AlertInfo would only return the alert records themselves, not the underlying sign-in attempts or their full context. To identify all authentication instances—both benign and malicious—you must query IdentityLogonEvents directly, as AlertInfo only surfaces a subset that triggered detections.

Go deeper

Related to this question