SC-200 sample questions — 25 answered and explained

Alert tuning suppresses alerts; it doesn't allow a blocked file. Allow indicators do.

An alert tuning rule decides what happens to matching alerts (hide, resolve, set as behavior). It doesn't change protection, so the antivirus still blocks the file. When you create a tuning rule from an alert, the Successful rule creation page offers to add the alert's IOCs, such as the triggering file, to an allow list with a chosen scope. That is the least-effort fix. An antivirus path exclusion would also stop the block, but it needs a policy to be authored and deployed and trusts everything at that path. Changing the action to Set as behavior is still alert handling, and changing the automation level doesn't affect antivirus quarantine and lowers protection.

1. Separate the two problems: alert noise (solved) and blocking (not solved).
2. Recall that tuning actions act on alerts only, so changing the tuning rule can't help.
3. Compare the two ways to stop the block: an allow indicator from the alert or an antivirus exclusion policy.
4. Pick the allow indicator offered after rule creation: fewer steps and scoped to the file.

Exam tip: Tuning silences the alert; an allow indicator stops the block.

Excluding a Sentinel analytics rule from Defender XDR correlation.

In the Defender portal, alerts from analytics rules can join Defender's correlation engine, which merges them into attack stories. A rule that is excluded bypasses correlation, and its alerts are grouped into incidents only by the rule's own grouping configuration, which is the behaviour the playbook expects. Because the tenant default is on, the rule must be set to Disabled explicitly; the wizard then adds the #DONT_CORR# tag to the start of the description.

1. Note that the tenant default is on, so rules are correlated unless excluded.
2. Recall that excluded rules group alerts only by their own configuration.
3. Set the rule's Incident correlation option to Disabled.

Exam tip: Want Sentinel-style incidents from one rule? Exclude it from correlation (#DONT_CORR#).

Correlation tags #INC_CORR# and #DONT_CORR# and the tenant default setting.

The Incident correlation default setting decides what happens to rules without a tag. With it off, every analytics rule is excluded unless its description starts with #INC_CORR#; with it on, every rule is included unless it starts with #DONT_CORR#. The tag isn't case-sensitive and spacing after it is flexible, but it must be at the start of the description and include the # characters. Because the correlation state always follows the tag, editing it through the API works the same as using the wizard.

1. Read the tenant default: off, so rules are excluded unless tagged.
2. Choose the include tag, #INC_CORR#, not #DONT_CORR#.
3. Place the tag, with its # characters, at the very beginning of the description.

Exam tip: Default off: start the description with #INC_CORR# to opt a rule in. Default on: #DONT_CORR# opts out.

Behaviour of analytics rule correlation settings.

Correlation settings change how future alerts are grouped. An alert receives its correlation state at creation, so alerts that already exist stay where they are. The #INC_CORR# and #DONT_CORR# tags aren't case-sensitive, allow any spacing after them, and must start the description. Excluded alerts are still visible, and custom detections are included or excluded per rule, with no tenant default.

1. Test each statement against when the correlation state is set: at alert creation.
2. Recall the tag format rules: case-insensitive, at the start.
3. Separate analytics rules (tenant default + tags) from custom detections (per rule).

Exam tip: Correlation changes apply to new alerts only; tags are case-insensitive and must start the description.

Correlation settings for custom detections vs analytics rules.

There are two correlation mechanisms. Sentinel analytics rules follow a tenant default that #INC_CORR# or #DONT_CORR# tags override. Custom detections have no tenant-level setting: each rule is set to Include in correlation (the default) or Exclude from correlation on its details page (public preview). An excluded custom detection creates predictable single-alert incidents when no incident alert-grouping rule applies, which is what the payments routing needs. The other options use the analytics-rule mechanism or a setting that doesn't control grouping.

1. Identify the rule type: a custom detection, not a Sentinel analytics rule.
2. Recall that custom detections are configured per rule only.
3. Select Exclude from correlation on that rule; leave everything else at the default.

Exam tip: Custom detection: per-rule Exclude from correlation. Analytics rule: tenant default + #DONT_CORR#/#INC_CORR#.

Conditions that prevent Defender XDR from merging incidents.

Defender merges related incidents unless one is closed, they have different assignees, they have different classifications or determinations, the merge would exceed the maximum number of entities, or (only if this is enabled) they contain devices in different device groups. Severity and the source products don't block a merge. After you fix the cause, you can merge up to five incidents at a time manually.

1. Recall the documented blockers: closed, different assignees, different classification, entity limit, device groups if enabled.
2. Match the options against that list.
3. Reject severity and source product: neither blocks a merge.

Exam tip: Closed, different owners or different classifications keep incidents apart.

Primary vs secondary Sentinel workspaces in the Defender portal.

Each onboarded Sentinel workspace is a separate data source. Only the primary workspace's alerts are correlated with Microsoft Defender alerts and included in shared incidents; alerts from secondary workspaces aren't correlated with Defender or with other workspaces. Correlation tags and the tenant default only matter for a workspace that can be correlated at all, so the fix is to change which workspace is primary. The company has accepted that WS-Corp then becomes secondary.

1. Note the symptom: no correlation at all for one workspace.
2. Recall that secondary workspaces are never correlated with Defender alerts.
3. Reject tag and default changes: they don't lift the secondary-workspace limit.
4. Make WS-Factory the primary workspace, as the company accepted.

Exam tip: Only the primary Sentinel workspace's alerts join Defender XDR incidents.

Email remediation from automated investigations always needs approval.

Defender for Office 365 automated investigations can identify remediation actions such as soft-deleting messages, blocking URLs or turning off external forwarding. Unlike device actions, no remediation actions are taken automatically for email and content: they wait on the Pending tab of the Action center (or on the incident) until someone with the right permissions approves or rejects them. Device group automation levels don't apply to mailboxes.

1. Identify the entity type: email, not devices.
2. Recall that email remediation from automated investigations is always approval-based.
3. Expect the action on the Action center's Pending tab.

Exam tip: Email remediation from automated investigation never runs on its own; approve it in the Action center.

Permissions to approve email remediation in the Action center.

Device remediation needs the Security Administrator role (or the Defender for Endpoint Active remediation actions role, or Response (manage) in Unified RBAC). Email and content remediation needs Security Administrator and also membership in an Email & collaboration role group that has the Search and Purge role. By default only the Data Investigator and Organization Management role groups have it, or you can create a custom role group. The Security Administrator role group in Email & collaboration is a tempting choice, but it doesn't include Search and Purge.

1. Note that device approvals work, so her device permissions are fine.
2. Recall that email remediation additionally needs the Search and Purge role.
3. Assign a role group that has Search and Purge (Data Investigator, Organization Management or a custom one).

Exam tip: Email remediation approvals = Security Administrator + Search and Purge.

Undoing completed remediation actions in the Action center.

Completed actions, whether automatic or manual, are listed on the Action center History tab. Several of them can be undone: isolate device, contain device, contain user, restrict code execution, quarantine file and some registry, service, driver and scheduled-task actions. For a quarantined file there is an option to apply the undo to every other instance of the same file. Only Security Administrators or higher can undo actions such as file quarantine.

1. Note that the action is completed, so look on the History tab.
2. Recall that Quarantine file can be undone across multiple instances.
3. Use one undo applied to all instances instead of 30 manual restores.

Exam tip: Completed action? History tab > Undo; for files, apply it to every instance.

The 2026 change to automated investigation and response for Defender for Endpoint.

Microsoft changed AIR for Defender for Endpoint on September 1, 2026. Its detection and response logic now runs automatically inside the default antivirus protection stack. It is no longer a separate investigation you can start manually, and Microsoft recommends a full antivirus scan for on-demand checks. The change applies only to Defender for Endpoint: Defender for Office 365 AIR remains, and its email remediation still needs approval. Device group automation levels and the Action center are still in use.

1. Find the scope of the change: Defender for Endpoint only.
2. Recall the replacement for on-demand checks: a full antivirus scan.
3. Keep what didn't change: Defender for Office 365 AIR, approval of email actions, automation levels and the Action center.

Exam tip: Since September 2026, Defender for Endpoint AIR is built into antivirus with no manual trigger; Defender for Office 365 AIR is unchanged.

Disable user acts on Active Directory through Defender for Identity sensors on domain controllers, and on Entra ID separately.

For an AD-hosted account synced to Entra ID, the disable action is triggered through onboarded domain controllers and the account is also disabled in Microsoft Entra ID. Only sensors installed on domain controllers perform remediation; sensors on AD FS, AD CS or Entra Connect servers don't. The Entra ID disable doesn't depend on Defender for Identity, which is why it succeeded while AD didn't.

1. Split the action: Entra ID (worked) vs Active Directory (didn't).
2. Recall which sensors execute AD remediation: domain controller sensors only.
3. Add sensors to the domain controllers.

Exam tip: Remediation in Active Directory runs only from Defender for Identity sensors on domain controllers.

A built-in alert tuning rule changed how DLP signals surface in Defender XDR in October 2026.

Microsoft added a built-in alert tuning rule for DLP signals that took effect in early October 2026. It sets these signals as behaviors instead of alerts, so they don't create alerts or incidents but stay huntable in BehaviorInfo and BehaviorEntities. To keep DLP signals as alerts, disable that rule in Settings > Microsoft Defender XDR > Alert tuning.

1. Note the clue: matches appear in BehaviorInfo, not as alerts.
2. Recall the October 2026 built-in tuning rule for DLP.
3. Disable it under Alert tuning.

Exam tip: DLP signals only in BehaviorInfo since October 2026: disable the built-in DLP alert tuning rule.

Permissions for DLP alerts in Defender differ by scope (DLP only, or DLP and security) and by read versus manage.

Microsoft's table maps each permission to the alerts it opens: Manage Alerts and View-Only Manage Alerts give access to DLP and security alerts; Information Protection Analyst, DLP Compliance Management and View-Only DLP Compliance Management give access to DLP alerts only. The read-only, DLP-only combination is View-Only DLP Compliance Management.

1. Apply the scope rule: DLP alerts only.
2. Apply the access rule: read-only.
3. Pick the permission that is both.

Exam tip: DLP-only and read-only in Defender: View-Only DLP Compliance Management.

DLP alerts on SharePoint and OneDrive files support in-place remediation from the Defender portal.

For a DLP alert on a file in SharePoint Online or OneDrive, the Defender portal offers apply retention label, unshare, delete, apply sensitivity label, download and withdraw feedback. Only unshare ends the external access and keeps the file for its owner.

1. Identify the exposure: an external share.
2. Keep the constraint: the file must stay.
3. Choose the action that removes sharing only.

Exam tip: Overshared file that must stay: unshare it from the DLP alert.

Insider risk alerts in the Defender portal need both a Defender role and an insider risk management role group.

Microsoft lists Security Operator or Security Reader as the Defender roles for insider risk alerts, plus membership in Insider Risk Management, Insider Risk Management Analysts or Insider Risk Management Investigators. Security Reader with the Analysts role group meets the need without broad administrative roles.

1. Recall that two permission systems apply: Defender and Purview IRM.
2. Pick the narrowest Defender role listed.
3. Pick an IRM role group that can view and manage alerts.

Exam tip: Insider risk alerts in Defender: a Defender role (Security Operator/Reader) plus an insider risk management role group.

Insider risk alert status and classification sync between Defender and Purview through a fixed mapping.

Defender New and In progress map to Needs review in Purview. Resolved depends on the classification: True positive maps to Confirmed; Informational, expected activity and False positive map to Dismissed; with no classification the status becomes Dismissed by default. Updates appear in both portals within 30 minutes.

1. Note the target state in Purview: Confirmed.
2. Recall that Resolved alone isn't enough; the classification decides.
3. Resolve with True positive.

Exam tip: To show Confirmed in Purview, resolve the insider risk alert in Defender as True positive; no classification means Dismissed.

Insider risk data in advanced hunting is split across alert, behavior and event tables.

AlertInfo and AlertEvidence carry the insider risk alerts and their entities. DataSecurityBehaviors carries insights into potentially suspicious user behavior. DataSecurityEvents carries the enriched events about user activities that violate Purview policies, so it's the table for activity-level detail like a file upload.

1. Identify the grain: individual activities, not alerts or behaviors.
2. Match it to the event table.
3. Query DataSecurityEvents.

Exam tip: Activity-level insider risk detail = DataSecurityEvents; behavior insights = DataSecurityBehaviors.

The Defender for Cloud alert Take action tab offers mitigation, prevention, automated response and suppression.

Take action has five sections: Inspect resource context, Mitigate the threat, Prevent future attacks, Trigger automated response and Suppress similar alerts. When the detected activity isn't malicious, 'Create suppression rule' under Suppress similar alerts stops future alerts with similar characteristics. Dismissing closes only the current alert.

1. Confirm the activity is benign and recurring.
2. Separate closing one alert from stopping future ones.
3. Create a suppression rule.

Exam tip: Benign and recurring in Defender for Cloud: create a suppression rule, don't just dismiss.

Defender for Cloud can run a logic app on demand for a single alert.

The alert's Take action tab includes Trigger automated response, where 'Trigger logic app' runs a logic app with automated response steps for that alert. Workflow automation applies to future alerts that match a trigger, so it changes ongoing handling. Suppression and the mitigation steps don't run logic apps.

1. Note the scope: this one alert, now.
2. Separate on-demand triggering from workflow automation.
3. Use Trigger logic app on the alert.

Exam tip: One alert, now: Trigger logic app from Take action; future alerts: workflow automation.

KQL equality is case-sensitive unless you use the ~ forms.

== and in compare case-sensitively, so a single literal matches only one capitalisation. =~ (and in~ for lists) compares regardless of case. Operators ending in _cs are the case-sensitive variants. Microsoft recommends case-insensitive matches when file names and command lines can vary.

1. Spot that the values differ only in case.
2. Recall which operators are case-sensitive: ==, in and the _cs forms.
3. Use =~ for a single value or in~ for a list.

Exam tip: Case varies? Use =~ or in~.

The default join flavor, innerunique, deduplicates the left table by the join key.

Without a kind, join uses innerunique. It keeps one random left row for each key value, so 12 messages with the same SHA256 collapse to one, which is then matched to each of the 3 devices. kind=inner keeps every left row that matches. leftsemi drops the right-side columns, leftouter keeps unmatched rows, and swapping the sides just moves the deduplication to the device rows.

1. Recognise the symptom: duplicates on the left side are collapsing.
2. Recall that the default flavor is innerunique.
3. Use kind=inner to keep every matching left row together with the right-side columns.

Exam tip: Missing rows after a join? The default innerunique deduplicated the left table. Use kind=inner.

Anti-joins return rows with no match on the other side.

The left side is the last day of process events and the right side is the baseline of hashes seen earlier. leftanti keeps the left rows that have no match on the right, so it returns only processes with a hash new to the environment. leftsemi and inner keep matching rows, and rightanti returns right-side rows, the old hashes that weren't seen recently.

1. Identify which side holds the rows you want returned: the left, recent events.
2. Identify the condition: no match in the baseline.
3. Choose the left anti-join.

Exam tip: Rows here but not there: leftanti.

Count distinct values with dcount, and identify a process by ID plus creation time.

The requirement is different remote addresses, so the aggregation must be dcount(RemoteIP), not count(), which counts connections. The grouping must isolate one process instance: the unique process ID would normally do that, but it is empty on some devices here, so their processes would collapse into one blank group. Where unique process IDs aren't populated, Microsoft's guidance is to group by device, InitiatingProcessId and InitiatingProcessCreationTime (the creation time separates reused IDs), then filter RemoteIPs > 10.

1. Read the measure: different addresses means dcount, not count().
2. Read the grouping: one process instance.
3. Check the stated gap: unique IDs are missing on some devices, so fall back to process ID plus creation time.

Exam tip: Unique process = device + process ID + creation time (or ProcessUniqueId where available).

ProcessUniqueId identifies one process instance on Windows.

Windows recycles process IDs, so ID matching can link unrelated processes. Defender for Endpoint adds ProcessUniqueId for each process and InitiatingProcessUniqueId for its parent, and Microsoft recommends matching the child's InitiatingProcessUniqueId to the parent's ProcessUniqueId when the values are present. Matching file names is too broad, and the parent ID column points one generation further up.

1. Note the constraint: one exact instance, with process IDs reused.
2. Use the column that stays unique per instance.
3. Join the child's initiating unique ID to the parent's unique ID.

Exam tip: Parent-child links on Windows: InitiatingProcessUniqueId to ProcessUniqueId.