SC-200 - Manage a Security Operations Environment (41% of the exam) - Section 1.7

Create and manage custom detection rules in Microsoft Defender XDR using Advanced Hunting.

Build custom detection rules in Microsoft Defender XDR by promoting Advanced Hunting queries, setting detection frequency, and mapping impacted entities such as devices, users, and mailboxes. Manage the rule lifecycle by editing, disabling, and reviewing rule status to ensure detections remain accurate and do not generate excessive noise.

custom detection rules from Advanced Hunting queriesdetection frequency and response actionsmanaging custom detection rulesimpacted entities

Practice question for this objective

Free sampleManage a Security Operations Environmentmedium

Your team maintains a Microsoft Defender XDR custom detection rule whose Advanced Hunting query joins the endpoint and identity tables. You also ingest a verbose custom application log into a dedicated custom table in your Microsoft Sentinel workspace, and an engineer proposes extending the same custom detection rule's query to reference that Sentinel custom table so a single rule covers both data sets. Why will referencing that Microsoft Sentinel custom table inside a Microsoft Defender XDR custom detection rule fail to work as proposed?

AA Microsoft Defender XDR custom detection rule can query Microsoft Sentinel custom tables, but only after the workspace is upgraded to the unified data lake tier for cross-product queries.
BA Microsoft Defender XDR custom detection rule can reference any table, but a custom table breaks alert deduplication because Sentinel custom tables never contain a ReportId column.
CA Microsoft Defender XDR custom detection rule cannot use a query that joins more than two tables, so adding the Sentinel custom table exceeds the join limit the rule allows.
DA Microsoft Defender XDR custom detection rule runs only over the Microsoft Defender XDR Advanced Hunting schema, so a Microsoft Sentinel workspace custom table is not available to its query. Correct

Recognise that a Microsoft Defender XDR custom detection rule queries only the XDR Advanced Hunting schema and cannot reference arbitrary Microsoft Sentinel workspace custom tables. Custom detection rules are built and run inside Microsoft Defender XDR Advanced Hunting, so their queries resolve only against the XDR tables (the endpoint, identity, email, and cloud app schema). A custom table that exists in a Microsoft Sentinel Log Analytics workspace is not part of that schema, so the query reference cannot bind. To detect on workspace-scoped custom data you would build a Microsoft Sentinel scheduled analytics rule instead.

Why A is wrong: Tempting because the data lake does broaden query reach, but a custom detection rule still binds to the XDR schema; no tier upgrade exposes a Sentinel custom table to it.

Why B is wrong: Tempting because ReportId matters for deduplication, but the genuine reason is scope: the rule cannot see the Sentinel custom table at all, not merely that one column is absent.

Why C is wrong: Tempting because complex joins feel risky, but there is no two-table join cap on custom detection rules; the blocker is that the Sentinel custom table is outside the XDR Advanced Hunting schema.

Why D is correct: Correct: custom detection rules execute against the XDR Advanced Hunting tables, which do not include arbitrary Microsoft Sentinel workspace custom tables, so the proposed reference cannot resolve.

See more SC-200 practice questions, answers explained.

Exam traps in Manage a Security Operations Environment

Answers that look right on this material and are not. Each one is a distractor from a different question in the SC-200 bank for this domain.

A custom detection rule supports Kusto Query Language while a Microsoft Sentinel scheduled analytics rule does not, so only the custom detection rule can express the cross-table hunting logic the team has written.
Why it is wrong: This is tempting but false: both custom detection rules and Sentinel scheduled analytics rules are authored in Kusto Query Language, so query language is not the differentiator between them.
The run evaluates a fixed 30-day window of events regardless of the frequency, because that is the Advanced Hunting data retention period for the tables.
Why it is wrong: Tempting because 30 days is the Advanced Hunting retention limit, but a custom detection rule does not rescan the full retention window on every run; its lookback tracks the frequency.
The security reader permission, which grants read-only visibility into security data, alerts, and configuration across the Microsoft Defender portal experience.
Why it is wrong: Security reader is read-only, so it explains why the analyst can already view rules but cannot create or edit them; it cannot grant the management capability required here.

Examworthy is not affiliated with or endorsed by Microsoft. Original, blueprint-aligned practice material only.