SC 200 Sample Questions With Answers

Each question below is drawn from realistic Microsoft Defender XDR, Sentinel, and Defender for Endpoint scenarios. Work through it before checking the answer, then read the explanation even if you got it right.

Question 1 (Respond to security incidents)

A media streaming company uses 10.30.0.0/16 on both its on-premises network and its Azure VNet. A Microsoft Defender XDR incident shows malicious traffic from source IP 10.30.10.5 in that overlapping range. You open the incident and use embedded Microsoft Security Copilot. The attacker must be contained immediately, but the streaming platform cannot accept an availability break. Copilot recommends isolating the device with that IP. What should you do first?

• A. Have Copilot investigate both overlapping networks before considering any containment.
• B. Approve the isolation because the alert already confirmed the source IP is the attacker.
• C. Approve isolation for every device that has used the source IP in the past day.
• D. Ask Copilot to match the alert’s device ID and interface before approving any isolation.

Answer: D

Explanation: The IP address is not a unique asset identifier here because the same 10.30.0.0/16 range exists in two environments; 10.30.10.5 could refer to an on-premises host or an Azure VM. The alert’s device ID and the specific interface used in the network event are the stable, unambiguous anchors, so matching them first satisfies both immediate containment and availability. The strongest distractor is approving isolation because the source IP is confirmed: the IP is a confirmed observed value, but its mapping to a specific device is still ambiguous in overlapping address space. The general rule is to pivot on stable asset identifiers such as device ID and interface rather than IP addresses, which are ephemeral and can be reused across networks.

Question 2 (Respond to security incidents)

Northwind Air uses Microsoft Defender XDR with Defender for Identity sensors on both domain controllers. You are responding to a multi-domain attack: a phished helpdesk account was used in a pass-the-hash attack from a flight-ops workstation to a corporate domain-joined server. You must identify which on-premises servers the account actually authenticated to across both AD domains before the account is disabled. What should you do first?

• A. Open the account's lateral movement path in Microsoft Defender for Identity.
• B. Use Microsoft Defender for Office 365 Threat Explorer to review the phishing email.
• C. Query IdentityLogonEvents in advanced hunting for the account's network logons.
• D. Inspect Microsoft Entra ID sign-in logs for the helpdesk account's sessions.

Answer: C

Explanation: This is correct because the question asks for actual on-premises authentication, and IdentityLogonEvents is the Defender XDR advanced hunting table populated by Defender for Identity from on-premises AD authentication events such as Kerberos and NTLM. The strongest distractor is the lateral movement path option: it is a Defender for Identity feature that seems directly related, but it models possible exposure paths rather than proving which servers the account really reached. The Entra ID sign-in log option would only cover cloud sessions and misses pass-the-hash traffic against on-premises servers. The rule that generalises is: when the question is about actual AD logon evidence, query the identity event tables; use lateral movement path when the question is about exposure or risk.

Question 3 (Perform threat hunting)

Your healthcare organization has merged with another hospital, and both sites use the same 10.10.0.0/16 address space, so the same internal IP can identify different hosts at each site. You are reading a Microsoft Defender XDR threat analytics report for an active ransomware campaign. The report’s hunting query detects devices that contacted an internal SMB scanning host at 10.10.10.5. You need to return affected devices without mixing results from the two sites. In DeviceNetworkEvents, which field should be the primary device identifier in your query?

• A. Use the RemoteIP field from DeviceNetworkEvents to identify the shared scanner.
• B. Use the LocalIP field from DeviceNetworkEvents to identify local endpoints.
• C. Use the DeviceName field from DeviceNetworkEvents and correlate it by facility.
• D. Use the DeviceId field from DeviceNetworkEvents and join it to DeviceInfo.

Answer: D

Explanation: The overlap in the 10.10.0.0/16 range is the controlling detail: both sites have hosts that legitimately use 10.10.10.5, so RemoteIP and LocalIP cannot distinguish one facility’s endpoints from the other’s. DeviceId is the stable, unique identifier assigned by Microsoft Defender for Endpoint to each managed endpoint, so joining DeviceNetworkEvents to DeviceInfo on DeviceId keeps the hunt scoped to individual devices even when their IP addresses collide. The strongest distractor is the LocalIP option; it looks correct because the query is about an internal scanner, but in a merged environment with overlapping address space the same local address maps to more than one device. The general rule is to use DeviceId rather than IP or device-name fields for identity and joins in Defender XDR advanced hunting whenever network addressing is unreliable.

Question 4 (Perform threat hunting)

Your organization is a fleet operator and reuses the 10.40.0.0/16 address range at each depot. In a Defender for Endpoint incident, the evidence contains a device entity and the network address 10.40.7.93. The network address maps to nine devices because of the overlapping address space. You need to examine endpoint activity for the machine that generated the alert. What should you do first?

• A. Open the network address entity for 10.40.7.93 and review associated devices.
• B. Use device discovery network inventory to locate 10.40.7.93 by switch port.
• C. Query DeviceNetworkEvents using the device ID and timestamp from the alert.
• D. Query DeviceNetworkInfo for those nine devices and compare their network interfaces.

Answer: C

Explanation: This is correct because, when overlapping or conflicting address space is used, a private IP address is not a unique entity pivot; multiple legitimate endpoints can report the same address. The device ID in the incident evidence is the stable endpoint identity, and DeviceNetworkEvents records a device ID for every connection event, so correlating on device ID and timestamp isolates the alerted endpoint without pulling in traffic from other depots. The strongest distractor is the option that opens the network address entity for the IP; it would return every device using that address and cannot identify which one is responsible. General rule: in network environments with overlapping address space, pivot on device identity rather than IP address, and use the IP only as supplementary evidence.

Question 5 (Manage a security operations environment)

Contoso Financial Services uses isolated non-routable networks for its retail and investment banking units; both units reuse the 10.10.0.0/16 address space. Retail workstations have names beginning RTR-, investment workstations begin INV-. All endpoints are in the same contoso.com domain and run identical Windows 11 builds. You must keep the Microsoft Defender for Endpoint automation levels for the two units separate. How should you configure the device groups?

• A. Create two device groups using the IP address condition to match each unit's endpoint addresses, and assign each unit its required automation level.
• B. Create two device groups using OS platform conditions for Windows 11 and Windows 10, and assign each unit its required automation level.
• C. Create two device groups using device-name contains conditions for the RTR- and INV- prefixes, and assign each unit its required automation level.
• D. Create a single device group containing all endpoints and set its automation level to the most restrictive of the two compliance requirements.

Answer: C

Explanation: The device-name prefix option is correct because Defender for Endpoint device groups can be built on device name, domain, OS, or IP address, and only the name prefix is unique to each unit. Both units share the same 10.10.0.0/16 space, so an IP-address rule would match endpoints from either unit and the automation levels could not be scoped cleanly. The IP-address option is the strongest distractor: it is a normal way to build device groups, but it fails when network address space overlaps. General rule: choose a stable, unique condition for device group membership; when IP ranges overlap or are reused, rely on hostname patterns or other non-IP metadata instead of IP addresses.

Question 6 (Manage a security operations environment)

Contoso, a regulated financial services firm, must collect an application security log from servers in two isolated data-center zones that reuse the same 10.0.0.0/24 address space. The logs must be stored in a single custom log table in Microsoft Sentinel, and every row must identify the zone the server belongs to. Azure Monitor Agent is selected. What should you configure?

• A. A separate Log Analytics workspace for each zone, and then use cross-workspace queries to combine the custom log data when needed.
• B. A separate DCR for each zone, with a KQL transformation that adds a constant Zone value to every record it sends.
• C. A separate custom log table in the same workspace for each zone, and then combine them with a union query when needed.
• D. One DCR for both zones, with a KQL transformation that parses the source IP address from RawData to label the zone.

Answer: B

Explanation: This is correct because the two zones reuse the same 10.0.0.0/24 range, so a source IP address alone cannot identify the zone. Creating a separate DCR per zone and using a KQL transformation to stamp a constant Zone value on every record gives unambiguous attribution before the data reaches the custom table. The strongest distractor is the option that uses one DCR and parses the source IP address from RawData to label the zone; it fails because the same raw IP can exist in both zones, so the derived label is not unique. The separate-custom-table and separate-workspace options are also wrong because the requirement explicitly states a single custom log table. The general rule is: when network identities are not globally unique, do not derive the source from the log payload; instead, use a DCR transformation to stamp an environmental constant during ingestion.

Question 7 (Perform threat hunting)

Your SaaS startup has grown to 30,000 managed devices. While hunting for a phishing payload, you need every execution of mshta.exe in the last 24 hours to build a complete list. The Advanced Hunting query returns exactly 10,000 rows and stops. A teammate says the tenant’s daily Advanced Hunting export quota is exhausted. What should you do instead?

• A. Partition by time or device and merge the outputs outside the portal.
• B. Rerun the same query during off-peak hours after the daily quota resets.
• C. Project only the affected file names so the result set contains fewer rows.
• D. Ask Microsoft Support to raise the tenant’s daily Advanced Hunting result quota.

Answer: A

Explanation: The query stopping at 10,000 rows is the per-query result-set ceiling in Advanced Hunting, not a tenant-level daily export quota. The correct approach partitions the hunt by time or by device so each individual query stays below that 10,000-row ceiling, then merges the outputs externally to rebuild the full list. The strongest distractor, the support-ticket answer, treats this per-query boundary as a daily aggregate limit that can be raised, but a single Advanced Hunting query still will not return more than 10,000 rows. Projecting fewer columns also fails because the cap is on result rows, not on columns. The general rule is: when a required result set exceeds the Advanced Hunting row ceiling, break the hunt into smaller partitions and combine them outside the query service.

Question 8 (Perform threat hunting)

Your SaaS startup has grown to 40,000 identities, so Defender XDR ingests millions of app activities daily. You need to hunt for Azure AD interactive sign-ins that came from non-corporate IP addresses in the last 24 hours, with success/failure, client app, and conditional-access status. Your first KQL query against CloudAppEvents returns exactly the 10,000-row advanced hunting result cap, and ingestion metrics show it is incomplete. Which table should the query use?

• A. Query the CloudAppEvents activity table.
• B. Query the AADSignInEventsBeta table.
• C. Query the IdentityLogonEvents table.
• D. Query the DeviceLogonEvents table.

Answer: B

Explanation: This is correct because the hunt is for Azure AD interactive sign-ins with client-app and conditional-access details, and those fields are exposed by the AADSignInEventsBeta table in Defender XDR. CloudAppEvents is the high-volume cloud-app activity table; it is the reason the first query hit the 10,000-row result cap, so continuing there will still return a truncated set. IdentityLogonEvents is the strongest distractor: its name sounds like identity sign-ins, but it is aligned with authentication event data and lacks the client-app and conditional-access columns this hunt explicitly requires. DeviceLogonEvents covers endpoint logons, not cloud identity sign-ins. General rule: choose the narrowest table whose schema matches the exact event and required fields; when a broad table hits the service result ceiling, move to the specialized table rather than trying to use the broad one.

Question 9 (Perform threat hunting)

Your airline uses Microsoft Defender XDR. A phishing alert is grouped into an incident; the incident links a check-in kiosk service account to lateral movement into accounting systems. You need to create a hunting graph that shows the full blast radius. Because boarding is active, you cannot run scripts on the kiosk and no code or queries may be created or changed during the response. What should you do?

• A. Open the incident and use its Attack story graph.
• B. Run a new Advanced Hunting KQL query for related logons.
• C. Build a custom alert graph via Microsoft Graph API.
• D. Run Live Response on the kiosk to collect artifacts.

Answer: A

Explanation: Opening the incident and using the Attack story graph is correct because Defender XDR's Attack story graph is the built-in hunting graph: it renders related users, devices, mailboxes, and apps and shows the path between them. That visual relationship map is the blast radius, and it is read-only, so it does not run scripts on the kiosk, change configuration, or require creating a query. The strongest distractor is the option that runs a new Advanced Hunting KQL query. It is a legitimate hunting technique for correlating logons, but the scenario forbids creating or changing queries during the active boarding window. The rule to generalize: use the built-in incident graph when you need a fast blast-radius view and are constrained from active endpoint actions or code/query changes; use custom KQL only when you are allowed to iterate on new queries.

How to use these sample questions

Notice how often the wrong answer is not obviously wrong. The explanations spell out the detail that rules out the strongest distractor. Talking through the reasoning is normal for this exam style.

For the full domain breakdown these questions are drawn from, see exam objectives. To practice a complete timed set, move to the practice test, or start with the study plan if you have not built a schedule yet.

Exam facts on this page come from Microsoft’s own pages (official exam page). Prices, versions and policies change — confirm there before you book.