SC-200 Microsoft Security Operations Analyst Study Guide¶

Independent AI-assisted resource — HUMAN REVIEW PENDING. The October 28, 2026 team refresh reconciles the complete guide and detailed objectives with current public exam, product and learning evidence. See the current group report and sources-and-objectives record. Source conflicts and unexecuted exercises remain explicit. This is not human review or live product validation. The official blueprint is authoritative.

Study guide at a glance

Start here

Report an issue with SC-200

Blueprint checked2026-10-28

Review stateReview required

Guide-only active reading1 hr 45 min–2 hr 30 min

Prerequisites: Practical security operations across Microsoft Defender XDR, Microsoft Sentinel, Entra ID, Purview and Defender for Cloud, plus KQL, Windows/Linux, Microsoft 365, Azure, incident response, threat hunting, automation, and current AI-agent/Copilot concepts.

Exam essentialsRead the objective map, key distinctions, and readiness checklist.

Deep understandingWork through every domain, including decisions, failure modes, and related items.

Hands-on labsBegin with Lab 1 — Automation and action boundaries, then use the remaining labs to produce evidence you can inspect and explain.

Official objective domains

Manage a security operations environment40–45%
Respond to security incidents35–40%
Perform threat hunting20–25%

The active-reading range uses 90–130 words per minute for technical material. Labs, troubleshooting, note-taking, spaced review, and prerequisite gaps add time; it is not a total preparation promise.

Current baseline: Skills measured as of October 21, 2026.
Exam state: Active; the official credential page lists no retirement date.
Blueprint reconciliation (October 28, 2026): The October 21, 2026 English outline is the accepted current scope. The collection objective now explicitly names Azure activity logs. Keep control-plane activity, resource logs and their collection mechanisms distinct. Domain weights are unchanged. Historical objective bytes and dated reviews are preserved. Recheck localized appointment timing separately.
Localized exams: Microsoft says localized versions normally follow the English update by approximately eight weeks; verify your language version before scheduling.
Platform transition: Microsoft says Sentinel in the Azure portal stops being supported after March 31, 2027. Learn the unified Microsoft Defender portal experience and understand where current Azure-portal workflows still differ. VERIFY CURRENT before planning a migration.
Official source: SC-200 study guide

How to use this guide¶

SC-200 is an operator's exam. Product recognition is not enough: practice moving from signal to decision to safe action while preserving evidence. For each objective, be able to answer this chain:

security question
  -> required data and permissions
  -> query, correlation, or investigation surface
  -> confidence, scope, and business impact
  -> containment or remediation action
  -> validation, evidence, tuning, and closure

Read Sections 1–3, work all three scenarios, complete or tabletop the ten labs, and answer all 44 checks. Keep a current test tenant or Microsoft-provided lab nearby. The current October outline retains July’s fast-moving Sentinel platform, graph, data-lake, MCP, Security Copilot, and agentic capabilities, so compare dated Microsoft sources and record unresolved contradictions. This review found conflicting Sentinel NRT and lake-access statements; the relevant sections explain the limits instead of assuming universal tenant support.

About related items: A Related item: callout adds prerequisite, operational, architectural, or adjacent context that makes the current topic easier to understand. It is useful supporting knowledge, not a claim that the item appears verbatim in the published exam objectives.

Exam profile and complete objective map¶

The certification is intermediate and renews every 12 months. The current exam page gives 100 minutes for the proctored assessment and provides a free Practice Assessment and exam sandbox. Microsoft expects familiarity with its security, compliance, and identity solutions; Microsoft 365; Azure; AI agents and Copilots; and Windows, Linux, and mobile operating systems. Confirm administrative details on the Security Operations Analyst Associate credential page.

Official domain	Weight	Operational question
Manage a security operations environment	40–45%	How should automation, Sentinel, ingestion, and detections be configured for useful, governed signal?
Respond to security incidents	35–40%	How do you establish scope and confidence, contain the attack, remediate safely, and preserve a defensible case record?
Perform threat hunting	20–25%	How do you turn a hypothesis into KQL, graph, data-lake, notebook, or MCP-assisted investigation and then operationalize the result?

Published objective-to-guide map¶

Published objective area	Primary coverage	Practice evidence
Defender XDR email/alert notifications, tuning/suppression/correlation, Endpoint advanced features/rules/custom collection/ASR	Section 1	Scenario 1; Labs 1 and 4
Automated investigation and response, automatic attack disruption, Endpoint device groups/permissions/automation levels	Section 1	Scenarios 1 and 3; Labs 1 and 6
Sentinel automation rules and playbooks	Section 1	All scenarios; Labs 1 and 5
Sentinel roles; Analytics, Data lake, and XDR retention tiers; workbooks; SOC optimization	Section 1	Scenarios 2–3; Labs 2–3
Connector selection; Windows events with AMA/DCR and WEF; Syslog/CEF with AMA; Azure Policy/diagnostics; threat indicators; custom tables	Section 1	Scenarios 2–3; Labs 2–3
Defender XDR custom detections; Sentinel scheduled/NRT/TI/ML analytics; ATT&CK coverage; anomalies	Section 1	All scenarios; Labs 3–4
Incidents across Office 365, Purview, Defender for Cloud, Cloud Apps, Entra ID, Defender for Identity, and Sentinel	Section 2	All scenarios; Labs 5–7
Agentic AI/Security Copilot, complex multi-stage/multi-domain/lateral-movement attacks, and case management	Section 2	Scenarios 1 and 3; Labs 5–6
Endpoint timelines, device actions/live response/packages, evidence/entities, and attack-disruption incidents	Section 2	Scenario 1; Labs 5–6
Purview Audit, eDiscovery Content search, and Microsoft Graph activity logs	Section 2	Scenario 2; Lab 7
Defender XDR tables, KQL, Advanced Hunting, threat analytics, hunting graphs/blast radius, and Sentinel Graph	Section 3	All scenarios; Labs 4 and 8
Sentinel hunting queries, data-lake KQL jobs, summary-rule tables, notebooks, and Sentinel MCP Server	Section 3	Scenario 3; Labs 3 and 8

1. Manage a security operations environment¶

Design operations before configuring tools¶

A useful SOC design starts with outcomes, not alert volume. Inventory critical services, identities, data, cloud subscriptions/accounts, endpoints, and external dependencies. For each priority threat, define:

the question the SOC must answer and the response-time target;
the authoritative signal sources, required fields, expected latency, retention, and owner;
detection logic, severity, entity mappings, correlation, and known blind spots;
analyst decision points and which actions may be automated;
escalation, legal/privacy, service-owner, and recovery boundaries;
test method, success criteria, tuning cadence, and evidence retained.

Use a lifecycle such as prepare, detect, analyze, contain, eradicate, recover, and learn. A closed incident is not the same as removed risk: verify containment, credential rotation, persistence removal, restored control health, and follow-up detection improvements.

Related item: Track mean time to detect/respond, false-positive rate, recurrence, telemetry health, and percentage of tested use cases together. Any single metric can be gamed or conceal a blind spot.

Configure Defender XDR and Endpoint automation deliberately¶

Notifications, alert tuning, suppression, and correlation¶

Email notifications help reach the right responders when incidents, threat analytics, or Endpoint actions require attention. Scope recipient rules by severity, device group, or source where supported, use monitored distribution paths, and test delivery. Notifications do not replace queue ownership or an on-call process.

Treat alert tuning as detection engineering:

Confirm the alert is understood and the benign pattern is stable.
Prefer the narrowest condition that removes the known pattern.
Preserve visibility for variants and high-value assets.
Record the owner, rationale, expiry/review date, and before/after volume.
Replay or simulate malicious and benign examples.

Suppression prevents selected matches from becoming alerts; tuning can adjust rule conditions or thresholds; correlation joins signals into incidents. Do not suppress evidence just because an incident is noisy. Microsoft's Defender XDR alert-investigation and tuning guidance emphasizes using conditions carefully and monitoring rule performance.

Endpoint advanced features, rule settings, custom collection, and ASR¶

Endpoint advanced features enable integrations and behaviors such as live response, Microsoft Intune connection, authenticated telemetry, and sharing signals across Defender services. Enable only what the design and licenses require, validate roles and privacy implications, and recheck after tenant changes. Use the current Defender for Endpoint advanced-features reference rather than memorizing a portal screenshot.

Endpoint rule settings include alert notifications, suppression, indicators, web-content controls, automation, and related tenant/device behavior. Separate these concepts:

an indicator allows, audits, warns, or blocks a file, certificate, IP, URL, or domain within product constraints;
a custom detection runs an Advanced Hunting query and can create an alert and take response actions;
custom data collection extends endpoint telemetry for a defined investigation/detection need and carries performance, privacy, schema, and retention responsibilities;
attack surface reduction (ASR) rules reduce exploit and abuse opportunities on devices before an alert is needed.

Roll out ASR in audit or warn mode where appropriate, review exclusions, pilot representative devices, then enforce. An exclusion is a security decision, not simply an application-compatibility fix. Read ASR rule deployment guidance and validate effective device policy rather than relying only on the management console.

Custom data collection is a current Endpoint-to-Sentinel telemetry path, not the older support-package/client-analyzer workflow. In Defender, a rule selects a supported custom event table and action/field conditions, targets all eligible devices or devices with dynamic tags, and sends matching events to the selected connected Sentinel workspace. Current tables cover custom process, image-load, file, network, and script events. Build a rule from the question backward: select only the event/action/fields needed, pilot on a small dynamic-tag scope, wait for deployment, query the corresponding DeviceCustom*Events table by RuleName and device, then measure volume and field quality before expanding.

The current Endpoint custom-data-collection guide documents Defender for Endpoint Plan 2, a connected/selected Sentinel workspace, dynamic tags, supported Windows versions, deployment timing, per-rule event limits, Sentinel ingestion charges, monitoring queries, and enable/edit/delete behavior. Broad collection can hit a device's rolling limit and create material cost; overly narrow filters create blind spots. VERIFY CURRENT: this recently changed capability has had preview/GA and limit changes, so recheck licensing, operating systems, tables, one-workspace constraint, event limit, and portal path before implementation or exam day.

Worked example — collection budget: one device generates 5,000 matching custom events per hour under one rule. The documented 75,000 events per device, per rule, per rolling 24 hours is reached after 15 hours; 18 hours would generate 90,000 candidates. The remaining 15,000 are a potential collection gap, not a promise of later replay. The cap pauses that custom rule's collection, not default EDR telemetry; it is not a midnight reset. Narrow the hypothesis/filters and test volume before wider deployment.

The selected destination is one Sentinel workspace per tenant; connecting a workspace alone does not select it for this feature. Dynamic tags must already be effective; static tags are unsupported. Allow the documented 20–60 minute rule deployment and tag propagation, verify supported endpoint/client versions, and distinguish disabling collection from deleting already ingested evidence. The source carries prerelease qualifications; do not assume every listed capability is generally available.

Related item: Prevention, detection, and response overlap but are not interchangeable. ASR may block a behavior; a custom detection may identify it; live response may investigate or remediate it. Strong designs connect all three.

AIR, automatic attack disruption, and device automation scope¶

Automated investigation and response (AIR) investigates alerts, assembles evidence, determines verdicts, and recommends or performs remediation according to product and automation settings. Analysts review the investigation graph and pending/completed actions in Action center rather than assuming that “automated” means “resolved.”

Automatic attack disruption is different: Defender XDR correlates high-confidence, cross-domain attack evidence and takes containment actions against compromised entities to stop attack progress. Verify licensing, Defender product coverage, identity auditing/action accounts, device versions, and automation settings. Microsoft's attack-disruption configuration guide notes that Endpoint device-group remediation levels affect behavior.

Device groups provide operational scope and RBAC boundaries. Plan grouping attributes, rank/precedence, user-group access, and automation level together. Overlapping rules or an overly broad group can send a critical server into a workstation automation policy. Test group membership and permissions with representative analysts.

Use this decision model:

Mechanism	Trigger/logic	Typical scope	Analyst responsibility
Endpoint AIR	Product investigation from alerts/evidence	Device and related evidence	Review verdicts/actions and automation level
Automatic attack disruption	High-confidence correlated XDR attack	Compromised users/devices and connected attack	Validate containment, business impact, and full remediation
Defender custom detection	Scheduled/continuous Advanced Hunting logic	Returned devices/files/users/emails	Validate query, frequency, entity/action columns, scope, and noise
Sentinel automation rule	Incident/alert create or update plus conditions	Incident workflow	Control ordering, expiry, owner/status/tag/action, and playbook call
Sentinel playbook	Logic Apps workflow invoked manually or by automation	Cross-service orchestration	Secure identity/connections; handle retries, idempotency, approval, and failure

Engineer Sentinel automation safely¶

An automation rule evaluates incident/alert events and performs built-in actions or invokes a playbook. A playbook is an Azure Logic Apps workflow that can enrich, notify, ticket, contain, or remediate. Microsoft's current playbook automation guidance directs new automatic playbook invocation through automation rules; direct calls from analytics rules were a legacy path.

For every automation:

define the trigger, provider, analytics-rule and severity conditions precisely;
order rules intentionally and use expiration for temporary event handling;
give the playbook's managed identity only the needed Sentinel/resource permissions;
protect connector credentials and understand tenant/subscription context;
make repeat execution safe (idempotent), catch partial failures, and log outcomes;
require approval for destructive, ambiguous, high-impact, or legally sensitive actions;
define timeout, retry, rollback, manual alternative, and owner;
test with synthetic incidents and monitor failed runs.

A useful low-risk first automation enriches an incident, assigns an owner, adds a tag, and opens a ticket. Auto-isolating a business-critical host without confidence, approval, and recovery design is not a good first automation.

Worked example — identity-safe automation: July's mapping change makes AccountName the UPN prefix. For alex@contoso.example, comparing AccountName with the full UPN now fails. A broad StartsWith("alex") also matches alex-admin, and a suffix substring could match contoso.example.attacker.example. Microsoft describes compatibility filters in its account-entity migration post. For an identity-specific response, our stricter design is to validate the canonical full UPN where supplied, or normalize and compare the complete prefix/suffix pair, then resolve the tenant and immutable object ID before action. Test old/new payloads, missing fields, guests and duplicate delivery; never treat substring matching as authorization.

Keep the two runtime identities separate: Sentinel needs permission to invoke the playbook; its connection/managed identity needs permission to perform the downstream task. Authoring or manually running the Logic App does not prove that an automation rule can invoke it. Match the incident/alert trigger type and test failure/retry behavior.

Related item: Automation reduces handling time only if its inputs are trustworthy. Schema drift, missing entity mappings, expired connectors, and duplicate incidents can turn a correct playbook into an unsafe action.

Configure the Sentinel SIEM and platform¶

Choose portal and workspace boundaries¶

Sentinel is integrated into the Microsoft Defender portal for unified operations with Defender XDR. Know the current capability boundary and migration prerequisites. Microsoft has announced that Sentinel support in the Azure portal ends after March 31, 2027, so prefer current Defender-portal workflows while recognizing that some configuration or edit experiences may still link to Azure.

You can connect Sentinel to the Defender portal without an E5 license or Defender XDR deployment. Combining XDR capabilities still requires their licenses and permissions. A unified screen does not automatically ingest all raw Defender events into Sentinel; validate connector, primary/secondary workspace and analyst scope separately.

Workspace topology affects access, residency, retention, cost, cross-workspace queries, incident ownership, and delegated operations. Centralization improves correlation and consistency; separate workspaces can satisfy tenant, region, billing, sovereignty, or organizational isolation. Do not create a workspace per team without examining cross-boundary response and data duplication.

Apply least-privilege roles¶

Sentinel Reader views data/incidents, Responder adds incident management, Contributor adds broader Sentinel configuration, and Playbook Operator can run playbooks. Logic Apps permissions and resource-group/workspace permissions also matter. Data-lake features can use tenant-wide Entra roles or workspace-level Azure RBAC. Use Sentinel roles and permissions to reason from task and scope to role; avoid solving an access failure by assigning Owner.

Test four planes independently:

Can the analyst see the workspace/data?
Can they manage the incident or detection?
Can Sentinel invoke the playbook?
Can the playbook identity perform its downstream action?

Understand Analytics, Data lake, XDR, Basic/Auxiliary, and long-term data¶

The current October blueprint explicitly names Analytics, Data lake, and XDR tiers. Think in terms of purpose rather than memorizing one price table:

Analytics tier supports low-latency, full analytics used by detections, investigations, dashboards, and response.
Sentinel data lake tier provides economical long-term, high-volume security data for historical investigation, jobs, notebooks, graph, and AI-connected scenarios. It is not a drop-in substitute for every real-time analytic.
XDR data is held according to the Defender service and unified-portal retention model; understand when data is queried in Advanced Hunting and when Sentinel ingestion/retention is needed.
Basic/Auxiliary plans and long-term retention/archive trade query features, latency, and access cost for lower ingestion/storage cost in eligible Log Analytics tables.

Start with use case, maximum acceptable detection latency, query operators, investigation horizon, regulatory hold, deletion/residency, and expected volume. Then choose table plan and retention. A cheaper table that cannot support the required rule or timely investigation is false economy. Conversely, expensive real-time ingestion of unused verbose data is not coverage.

VERIFY CURRENT: table eligibility, tier names, retention limits, query/operator support, ingestion/query pricing, and XDR/Sentinel integration behavior can change. Recheck the source table and region before making a design or cost decision.

September 23 onboarding boundary: Sentinel release notes direct new customers to integrated Sentinel/Defender onboarding and table-level lake retention, without a separate lake onboarding/billing setup. Earlier lake customers can continue their existing experience or adopt the Fabric paths. Record which cohort and experience your lab uses; older VS Code lake-job instructions are not a universal new-tenant setup recipe.

Use table settings and Table insights to inspect tier, retention, last received data and volume changes. Some security tables cannot move out of Analytics. A successful tier change can disable dependent detections, so test consumers before cost optimization.

Worked example — retained does not mean interactively searchable: a new tenant keeps SigninLogs for 90 days in Analytics and two years overall. Under the September 23 Advanced Hunting known issues, an event from 120 days ago is 30 days beyond the interactive Analytics window. Use the documented search-job route for that extended-retention data; an empty recent query does not prove absence. Lake-only tables have a different access path. The table-settings page still broadly lists Advanced Hunting among capabilities lost on a lake move, while the newer hunting/release pages describe lake queries. Unresolved documentation boundary: verify the actual table type, cohort, time range and supported query surface before asserting access.

Azure Monitor metadata mirroring in Fabric is preview. It exposes selected tables without replicating their storage, but the tutorial says only new data is mirrored; existing history is not backfilled. A newly created mirror therefore cannot recover the missing 120-day history. Fabric capacity, connection permissions and workspace/OneLake access still matter. A shared connection uses its configured identity; prove the consumer's permitted access rather than assuming Sentinel analyst scopes carry over. Mirror creation without an extra mirroring fee is not a claim that all Fabric analytics are free.

Related item: Retention is only part of forensic readiness. Validate time synchronization, parsing, stable identity/device/resource keys, integrity, access logging, case export, and legal-hold procedure.

Build decision-oriented workbooks¶

Sentinel workbooks use Azure Monitor Workbooks to present queries, parameters, charts, and drill-down links. A good workbook answers an operational question: connector health, incident aging, use-case performance, identity-risk trend, data-cost value, or response SLA. It declares time range and scope and permits drill-down to raw evidence.

Avoid impressive dashboards with ambiguous denominators. Test queries against empty, delayed, duplicated, and high-volume data; apply least-privilege sharing and source control/templates where practical. Use the workbooks documentation for current creation and portal behavior.

Use SOC optimization as a recommendation system¶

SOC optimization identifies data-value and detection-coverage opportunities. It can recommend enabling relevant analytics, connecting missing sources, changing a table plan, or stopping low-value ingestion. Coverage views may compare enabled detections/data with threat or business-risk scenarios; data-value views consider recent usage.

Do not accept a recommendation blindly. Check compliance retention, investigation use, seasonal threats, dormant-but-critical systems, custom queries, and downstream consumers. Document accept/dismiss decisions. Microsoft's SOC optimization reference explains that unused-table analysis is time-bounded and that some recommendations remain preview.

Ingest data for a defined use case¶

Select connectors by evidence requirements¶

For each connector, document supported deployment model, authentication, tenant/workspace scope, tables/fields, latency, volume, cost, normalization, health monitoring, throttling, and failure recovery. Confirm whether the connector creates incidents, alerts, raw logs, or all three. The Sentinel connector catalog is the starting point, not proof that the expected events have arrived.

Validate end to end:

// Replace the table and expected source with your connector's schema.
CommonSecurityLog
| where TimeGenerated > ago(30m)
| summarize Events=count(), LastEvent=max(TimeGenerated) by DeviceVendor, DeviceProduct
| extend MinutesSinceLast = datetime_diff("minute", now(), LastEvent)
| order by MinutesSinceLast desc

The query only returns producers with an event in its 30-minute window. A completely silent producer disappears from these results. Compare with an expected-source inventory or Table insights and test a deliberately silent source; do not interpret an empty result as healthy ingestion. Add field-quality checks needed by detections.

Windows Security Events via AMA and WEF¶

The Windows Security Events via AMA connector uses Azure Monitor Agent and data collection rules (DCRs) to select and route events. Design DCR association/scope, event-set filtering, destination, agent health, and duplication. “All events” can produce noise/cost; “Common” may omit an event a custom detection needs. Express the necessary Windows event IDs from the use-case inventory.

Windows Event Forwarding (WEF) centralizes events from source computers on a Windows Event Collector. Sentinel then collects from the collector. Plan source-initiated/collector-initiated subscriptions, WinRM/firewall/GPO, collector capacity, bookmarks, channel permissions, event latency, and high availability. WEF is transport/aggregation; the AMA/DCR still determines onward collection.

Related item: An installed agent is not healthy telemetry. Test a known event on a source endpoint and trace source channel -> WEF subscription/collector -> AMA/DCR -> Sentinel table -> analytic.

Syslog and CEF via AMA¶

Syslog via AMA generally lands in Syslog; CEF via AMA normalizes security-appliance events into CommonSecurityLog. A Linux forwarder may receive device messages and the DCR filters facilities/severities before ingestion. Follow current Syslog/CEF via AMA guidance and verify the proper stream (Microsoft-Syslog or Microsoft-CommonSecurityLog).

Test transport, TLS/network controls where applicable, facility/severity, CEF header/extension parsing, timestamps/time zone, hostname/device identity, duplicate forwarding, queue/disk behavior, and recovery after outage. A malformed CEF field can silently destroy entity mapping even while event counts look normal.

Azure Activity and resource logs¶

Azure Activity Log records subscription control-plane events; resource logs expose service-specific data/control-plane activity and require diagnostic settings. Azure Policy can deploy diagnostic settings at scale and remediate existing noncompliance, but policy assignment does not prove data arrival. Handle regional destinations, category groups, destination limits, policy identity permissions, exemptions, and duplicate settings.

Use Azure Monitor diagnostic settings to distinguish metrics/log categories and destination behavior. Confirm a known resource operation appears with caller, target, action, result, and correlation fields.

The diagnostic-settings connector guidance distinguishes subscription Activity Log export from each resource's diagnostic categories. Apply the correct policy scope/destination and remediate existing resources where required. Its green connector indicator can reflect ingestion within the preceding 14 days, which is far weaker than a five-minute operational freshness target. Confirm a known control-plane operation in AzureActivity and the separate resource-log event needed by the use case.

Threat intelligence and custom tables¶

Ingest threat indicators from supported platforms/connectors using standardized STIX/TAXII or APIs where possible. Preserve type, value, confidence, source, valid-from/until, labels, and revocation. Expire indicators and measure matches; more indicators can increase noise and query cost. Use ThreatIntelIndicators/ThreatIntelObjects; Microsoft documents that ingestion to the legacy table stopped July 31, 2025. This is an ingestion cutoff, not proof that all retained historical rows vanished. New-table data is republished every 7–10 days (LastUpdateMethod == "LogARepublisher"). Deduplicate versions by identifier, choose the latest version before testing deletion/revocation/validity, and distinguish republishing from a newly observed threat. Filtering deleted rows first can resurrect an older active version. Check schema fields explicitly; some long Data values are truncated, so the log row is not guaranteed to preserve the full original STIX object.

Create a custom Log Analytics table only after defining schema, transformations, DCR/data collection endpoint, retention/table plan, access, volume, and queries. Use a stable time column and meaningful identifiers. Test type coercion, malformed/missing fields, schema evolution, and ingestion latency. A custom table name normally ends in _CL; design it as an owned contract, not a dumping ground.

Configure detections that analysts can operate¶

Defender XDR custom detection rules¶

A Defender custom detection begins with an Advanced Hunting KQL query. The query must meet its data-source, frequency/lookback, entity-mapping and action requirements. It can create alerts and optionally act on returned device, file, user, or email entities. Microsoft's custom detection guide recommends validating the query before creating the rule.

For each rule, specify hypothesis, ATT&CK mapping, data/tables, frequency/lookback, entity and alert enrichment, action scope, exclusions, expected volume, owner, test cases, and rollback. A query that returns useful hunt context may still be unsuitable for automated action.

The current custom-detection documentation recommends projecting event time and source identifiers; it no longer supports teaching a single universal mandatory-column formula. Retain DeviceId and ReportId for Endpoint event scoping/process context, and preserve same-event Timestamp/ReportId for other Defender tables. If event time is omitted, alert timing can fall back to the detection window. With Sentinel row-level scoping configured, project SentinelScope_CF as documented; otherwise scoped analysts can lose visibility of the resulting alerts. Never fabricate a scope or combine events across access scopes merely to make a query pass.

Worked example — preserve one actual event: device D has events (10:00, ReportId 900) and (10:05, ReportId 100). Independent max(Timestamp) and max(ReportId) produce (10:05, 900), which never happened. arg_max(Timestamp, ReportId) retains (10:05, 100). Carry the correct device and any scope grouping through the aggregation; an alert needs traceable evidence, not just the highest values.

DeviceEvents
| where ActionType == "AntivirusDetection"
| summarize (Timestamp, ReportId)=arg_max(Timestamp, ReportId),
            Detections=count() by DeviceId
| where Detections > 5

This is an illustrative query for the rule's configured lookback, not a tested tenant detection. Do not add a contradictory event-time filter without understanding service prefiltering. Tune expected volume: the documented cap is 150 alerts per run. Permissions must cover every queried workload and device scope, not just access to the hunting page.

Continuous eligibility needs a tenant check: Defender's custom-detection page lists supported Sentinel tables and requires one supported table, supported operators, no joins/unions/externaldata, and no query comments for Continuous (NRT). The unified-hunting known-issues page still says NRT custom detections with Sentinel data are unavailable. These Microsoft pages conflict. Do not promise Sentinel Continuous support; validate the exact table/rule wizard and current documentation or use a supported scheduled route. This remains an open review finding.

VERIFY CURRENT: A table appearing in the Continuous eligibility list is insufficient: only generally available columns support Continuous. Record every projected/filtered column as well as table and operators. This extra check does not resolve the separate Sentinel-NRT documentation conflict.

Proposed practice extension — not executed: Lab 9: add column GA/preview status to Continuous eligibility matrix; do not treat wizard acceptance as proof a scheduled or Continuous rule emitted an alert.

Answer checkpoint: Can a supported Continuous table use every preview column? No; current documentation restricts Continuous to GA columns.

Sentinel analytics rule types¶

Scheduled rules run KQL on a configurable schedule/lookback; handle ingestion delay, thresholds, grouping, suppression, and event-to-alert logic.
Near-real-time (NRT) rules run every minute with a short ingestion-time delay for eligible scenarios. Use them only when the lower latency matters and the query meets constraints. See NRT rule behavior.
Threat-intelligence matching compares indicators with relevant event fields; tune indicator quality, expiry, field mapping, and source trust.
Machine-learning/anomaly detections use Microsoft or configurable anomaly logic depending on feature. Treat anomaly as investigation input: unusual is not necessarily malicious.

Worked example — two clocks: a source event occurs at 10:00 and arrives at 10:08. Sentinel NRT evaluates the ingestion-time window with a documented two-minute built-in delay and one-minute cadence, so 10:10 is a useful illustrative earliest point before additional scheduling/processing delay. That is already ten minutes after the event; a five-minute end-to-end target has been missed upstream. NRT cannot undo collection latency. Validate measured arrival and alert times rather than promising that exact alert time.

Sentinel NRT currently permits multiple tables and workspaces; do not import Defender Continuous's single-table restriction. The Sentinel page lists 50 rules per customer, source ingestion delay below 12 hours, and up to 30 single-event alerts. Above that grouping threshold, the first 29 alerts are individual and the 30th summarizes applicable events; this is not necessarily one independent alert per result.

Entity mappings connect alerts to accounts, hosts, IPs, URLs, cloud resources, and other investigation objects. Custom details and dynamic alert properties put decision context in the incident. Alert grouping affects case scope: grouping unrelated events hides parallel attacks; fragmenting one campaign raises workload.

Map each analytic to ATT&CK tactics/techniques and verify it with safe tests. ATT&CK shows coverage intent, not effectiveness. Measure data health, test pass rate, false-positive/false-negative observations, analyst disposition, and detection-to-containment time.

Related item: Detection-as-code can source-control templates, queries, workbooks, playbooks, and tests. Deployment automation does not remove the need for environment-specific baselines and response ownership.

Worked anomaly tuning — compare before promotion¶

Original example — proposed; service/tenant execution not performed.

Choose an available anomaly template whose required source data is actually present. Inspect its parameters, threshold, cadence and version. Duplicate the built-in rule to customize it; the original cannot be edited or deleted. Enable the duplicate in Flighting, change one supported parameter, and compare a representative sample with the original before promoting it to Production.

For a synthetic tuning review, the original generates 40 records, of which an analyst judges 30 benign; the duplicate generates 18, including 12 benign and six worth investigation. Lower volume alone does not prove improvement: check which previously useful cases disappeared and retain a missed-case set. Query Anomalies for the selected rule ID and compare source coverage and time windows. VERIFY CURRENT: templates, parameters, training periods and supported sources vary. An anomaly is a deviation requiring investigation, rather than proof of malicious activity.

Question: Can the original built-in anomaly be edited to reduce noise?

Answer: Create and tune a duplicate in Flighting; compare useful and missed cases before production promotion.

Work with anomaly detection analytics rules in Microsoft Sentinel

2. Respond to security incidents¶

Use a disciplined investigation loop¶

For every incident:

Validate source, time, severity, analytic, and data health.
Establish the earliest known activity and current attack state.
Identify affected identities, devices, mailboxes, apps, cloud resources, and data.
Build a timeline and relationship graph; separate fact, hypothesis, and unknown.
Look for persistence, privilege escalation, lateral movement, command/control, and exfiltration.
Choose containment that balances confidence, blast radius, service impact, reversibility, and approval.
Eradicate root cause and persistence; recover controls and services.
Validate no continuing activity, preserve evidence, document decisions, and improve detections/playbooks.

Incidents correlate alerts and entities; alerts describe detected activity; evidence/entities are the artifacts you investigate. Changing status or resolving an alert does not perform remediation.

Investigate through Microsoft Defender XDR¶

The unified Defender incident queue combines eligible signals from Defender XDR and onboarded Sentinel workspaces. Start with incident story, alerts, entities/assets, evidence and response, investigation graph, timeline, and similar incidents. Confirm product-specific context before taking action.

Defender for Office 365¶

For phishing/business-email-compromise scenarios, inspect sender/recipient, message trace, headers, authentication results, URLs, attachments, campaigns, mailbox activity, sign-ins, forwarding/inbox rules, OAuth grants, and impacted recipients. Use Explorer/email entity pages, Automated Investigation and Response, and threat hunting as licensed. Remediation may include soft/hard deletion or move, URL/file blocking, account/session action, rule/app removal, and user notification. Automatic attack disruption can contain high-confidence business email compromise, but analysts must validate all affected entities.

Microsoft Purview¶

Purview alerts may expose DLP, insider-risk, communication/compliance, data-security, or audit context. Respect role separation and privacy: an investigator may see pseudonymized or limited data until explicitly authorized. Correlate sensitive-data actions with identity, device, app, and network evidence. Preserve the case trail and escalate through HR/legal/privacy workflows when required; do not make an insider judgment from one anomalous action.

Defender for Cloud workload protections¶

Investigate the protected resource, alert evidence, attack path, timeline, subscription/account, recent control-plane changes, identity, network flow, vulnerability/posture context, and connected logs. Containment differs by workload: revoke an identity, isolate a VM, block a network route, disable a public endpoint, rotate a secret, quarantine an image, or stop a workload. Before acting, understand availability and forensic impact. The Defender for Cloud alert response guidance explains alert states and response workflow.

Defender for Cloud Apps¶

Use activity, app, file, OAuth-app, and user/entity context to investigate impossible travel, anomalous download, risky OAuth consent, session-policy signals, or shadow IT. Determine whether the activity is sanctioned, whether Conditional Access App Control/session policy applies, and whether identity risk is present. Actions can suspend a user, revoke an app, quarantine/govern a file, or change an app's sanction status, subject to permissions and business impact.

Microsoft Entra ID and Defender for Identity¶

Entra investigation combines risky users/sign-ins, sign-in logs, audit logs, Conditional Access result, authentication method, device, IP/location, token/session context, and workload identities. Remediation can confirm compromise, dismiss safe risk, reset credentials, revoke sessions/tokens, require secure authentication, disable an identity, remove malicious app consent, and close persistence.

Defender for Identity adds on-premises identity signals from sensors, including reconnaissance, credential access, lateral movement, directory changes, and entity profiles. Check domain-controller sensor health, account/device relationships, lateral movement paths, honeytoken/sensitive entity context, and the Entra hybrid link. Resetting a cloud password alone may not remove on-premises persistence.

Microsoft Sentinel incidents¶

Review incident provider, analytic, entities, alerts, tasks, comments, owner/status/classification, bookmarks, investigation graph/timeline, automation history, and related raw events. Run pivots across authoritative tables, add findings as bookmarks/evidence, and use incident tasks/checklists for repeatability. For multitenant or multiworkspace cases, document where the authoritative case lives and how evidence is synchronized.

Use agentic AI and Security Copilot with verification¶

Embedded Security Copilot and agents can summarize incidents, generate/interpret queries, analyze scripts, enrich entities, create briefings, recommend actions, or automate bounded workflows. Agentic AI may plan and invoke tools with less step-by-step prompting. This changes the control problem: verify identity, delegated permission, tool scope, grounding sources, action boundaries, approval, logs, and rollback.

Use AI output as a hypothesis and acceleration layer:

supply clear scope, time range, objective, and desired evidence;
inspect citations/query/results rather than trusting prose;
distinguish observed facts from inferred narrative;
remove unnecessary sensitive data from prompts and outputs;
require human approval for disruptive/irreversible actions;
record prompt/tool/action provenance where case policy requires;
test prompt injection, malicious evidence, hallucinated entities, stale context, and partial failure.

Related item: A confident narrative can create anchoring bias. Ask for disconfirming evidence and independently query the highest-impact claims.

Investigate complex, multi-stage, multi-domain attacks¶

Build a single temporal and entity model across email, identity, endpoint, SaaS, cloud control plane/workload, and data. Normalize time to UTC; identify the initial access, first compromised identity/device, credential/token acquisition, privilege changes, remote execution, persistence, discovery, collection, and exfiltration. Graph views help expose paths but still require raw-event validation.

Contain in an order that prevents the attacker from adapting:

protect evidence and emergency administration;
block command/control or malicious infrastructure;
isolate compromised endpoints/workloads when service impact permits;
revoke sessions/tokens and rotate credentials/secrets from a clean control plane;
remove persistence and excessive privilege;
close original weakness and validate monitoring;
restore from known-good state and watch for recurrence.

Coordinate owners. Endpoint isolation can break a live identity investigation; password reset can alert an attacker; shutting down a cloud workload can destroy volatile evidence. Record who authorized each tradeoff.

Manage the incident as a case¶

A defensible case record includes unique identifier, scope, severity/priority and changes, assigned owner, chronology, evidence links, hypotheses, decisions/actions with actor/time/result, communications, business impact, containment/eradication/recovery verification, classification, root cause, and follow-ups. Use tasks, tags, comments, bookmarks, activity/audit history, and ticket integration consistently.

Separate classification from status. A true positive can be active, contained, or resolved; a false positive may indicate tuning work. Do not put secrets or unnecessary personal data in comments. Define retention/export and chain-of-custody needs before a major incident.

Respond through Defender for Endpoint¶

Device timeline and entity evidence¶

The device timeline orders processes, files, registry, network, logon, and detections for one endpoint. Filter around the suspected time, identify parent/child chains and user context, then pivot to file, IP, URL, user, and alert pages. A timeline event is telemetry, not automatically malicious.

Evidence/entity pages aggregate prevalence, signer/hash, observed devices, alerts, reputation, and relationships. Compare tenant prevalence and global reputation carefully: a rare file may be legitimate; a common signed binary may be abused. Preserve hash, path, command line, user, timestamps, and source record.

Device actions and live response¶

Common actions include isolate device, contain device, run antivirus scan, collect investigation package, restrict app execution, initiate automated investigation, and live response. Know supported operating systems, role requirements, action state, and undo path. Isolation generally preserves Defender service communication but can disrupt business services.

Live response opens a remote shell for approved investigation/remediation commands. Use role separation, signed-script/library controls, session auditing, a written objective, and minimal commands. Avoid modifying evidence before collecting it. The Endpoint response-action reference lists capabilities and platform constraints.

The live-response command reference distinguishes basic/advanced permissions and operating-system command support. A device supports one live session at a time; a user can start up to five, with 50 concurrent sessions overall. Inactivity expires after 30 minutes; most commands time out after ten minutes, while getfile, findfile and run have 30 minutes. A file within the 3 GB getfile limit can still exceed its transfer timeout. Preserve the command log and collected evidence; do not assume an arbitrary local shell command or an unsigned script is permitted.

For an incident touched by attack disruption, review contained entities and Action center history. Automated containment buys time; it does not replace persistence search, scope validation, credential recovery, or root-cause remediation.

Investigate Microsoft 365 activities¶

Purview Audit¶

Audit searches activity across Microsoft 365 services and, depending on licensing, retention and premium capabilities. Define date/time, workload, users, operations, and record types; export the exact result set; preserve query criteria and UTC interpretation. Audit records can lag and schemas vary by workload. Use Purview Audit search guidance and validate fields against the activity's service.

eDiscovery Content search¶

Content search finds mailbox and supported site content by location, custodians, keywords, dates, participants, properties, and conditions. Use it for authorized evidence discovery, not telemetry hunting. Estimate/test the query, minimize scope, preserve search/export metadata, and apply appropriate eDiscovery roles and legal controls. Search results show content matching the query; absence is not proof an event never happened.

Microsoft Graph activity logs¶

Microsoft Graph activity logs expose HTTP requests handled by Graph for the tenant and can be sent through Azure Monitor diagnostic settings to supported destinations. They help investigate app/user API access, response status, client/request IDs, IP/user agent, tenant/app identity, permission/scopes, and requested resource paths. Protect sensitive fields and manage volume. Use the Graph activity-log overview to understand availability and schema.

Graph logs require Entra P1/P2 and appropriate diagnostic-setting/destination access. Use RequestId for a request and OperationId for batch correlation; the latter can be shared by several requests. A successful HTTP response alone is not proof of exfiltration or the full returned content. Protect request URIs as potentially sensitive evidence; never place secrets in directory attributes or query inputs expecting the audit trail to conceal them.

Related item: Entra audit/sign-in logs, Microsoft 365 unified audit, service-specific logs, and Graph activity logs answer different questions. Correlate rather than treating one as a universal audit trail.

3. Perform threat hunting¶

Turn a hypothesis into repeatable evidence¶

A hunt is not browsing alerts. State a falsifiable hypothesis derived from threat intelligence, an incident, ATT&CK, an exposure, or a baseline deviation. Define entities, time range, required tables/fields, expected benign behavior, known gaps, and stop/escalation conditions. Run broad discovery, narrow with evidence, save high-value findings as bookmarks, document null results, and promote repeatable/high-confidence logic to detections.

Example hypothesis: “A compromised user used a newly consented OAuth application to enumerate files and download an unusual volume outside the normal client pattern.” Required evidence may span Entra audit/sign-ins, Graph activity logs, Defender for Cloud Apps, Purview audit, and endpoint/network context.

Select the right KQL schema and operators¶

Defender Advanced Hunting and Sentinel Log Analytics both use KQL, but table availability, retention, functions, and schema differ. Start by choosing the table that owns the event:

DeviceProcessEvents, DeviceNetworkEvents, DeviceFileEvents, DeviceLogonEvents for Endpoint behavior;
EmailEvents, EmailUrlInfo, UrlClickEvents for mail/URL activity;
IdentityLogonEvents, IdentityDirectoryEvents, and identity-related Entra tables for identity behavior;
AlertInfo, AlertEvidence, IncidentInfo, and relevant graph/entity tables for correlated security records;
Sentinel tables such as SecurityEvent, WindowsEvent, Syslog, CommonSecurityLog, SigninLogs, AzureActivity, and custom tables for collected data.

Use schema reference and getschema/field inspection rather than guessing columns. Query narrowly by time and projection, filter early, normalize casing, parse dynamic data intentionally, and avoid expensive unconstrained joins.

let lookback = 24h;
let threshold = 20;
SigninLogs
| where TimeGenerated > ago(lookback)
| where ResultType != "0"
| summarize Failures=count(), IPs=make_set(IPAddress, 20),
            FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated)
            by UserPrincipalName
| where Failures >= threshold
| order by Failures desc

This is a learning pattern, not a production detection. The SigninLogs schema defines ResultType as a string and "0" as success. A nonzero result deserves interpretation; it is not always proof of a bad password or an attack. The capped IP set is context, not a count of every distinct IP. A real rule must handle service accounts, delay, baselines, entity mapping and validation.

Core operator reasoning:

where reduces rows; project controls columns; extend derives fields;
summarize ... by aggregates and creates a new schema;
join correlates matching keys but can multiply rows; choose kind and time relationship deliberately;
union combines compatible streams; search is broad discovery and often inefficient for production;
parse, parse_json, extract, and dynamic access turn raw fields into queryable values;
let, functions, and watchlists make logic reusable;
bin, make-series, series_decompose_anomalies, and render support time-series investigation;
arg_max, dcount, make_set, mv-expand, and lookup solve common entity/history problems.

Test query boundaries: empty results, duplicate events, missing fields, late arrival, UTC window, high-cardinality keys, and known benign/malicious samples.

Hunt and detect with Defender XDR¶

Advanced Hunting supports proactive querying across Defender data. Use the schema pane, sample queries, query resources, and results-to-entity pivots. Confirm retention and whether Sentinel integration extends access to additional tables. The Advanced Hunting overview is the current feature reference.

A custom detection operationalizes a query; it is not simply a saved hunt. Preserve recommended event identifiers and required action/scope fields, match frequency/lookback constraints, and include actionable context. Test result rate and permissions, then monitor alert/action results.

Threat analytics reports provide Microsoft research, affected-asset status, related incidents, and detection/mitigation guidance. Use them to form hypotheses and prioritize validation against your environment; “no affected assets” depends on telemetry and product coverage.

Hunting graph visually connects entities and relationships. Blast-radius views show potential impact paths, while Sentinel Graph can connect activity, assets, and threat intelligence. Microsoft's Sentinel Graph overview distinguishes pre-breach exposure paths, incident blast radius, and interactive graph hunting. A graph edge expresses a modeled relationship; validate critical edges and timestamps in source data.

Custom Sentinel graphs are separately marked preview. An on-demand graph job retains its graph for 30 days; scheduled jobs rebuild on their configured refresh schedule. Record build/source time: a current potential path does not establish that the attacker actually used that path during an older incident.

Hunt on the Sentinel platform¶

Hunting queries, hunts, bookmarks, and livestream¶

Built-in and custom hunting queries provide hypotheses mapped to tactics/techniques. Review each query's required tables and logic before running it. A hunt groups a hypothesis, queries, bookmarks, and findings as a trackable investigation. Bookmarks preserve selected query results and notes and can be promoted to incidents. Livestream can repeatedly run a query for short-term monitoring, subject to feature constraints.

Convert proven, repeatable, time-sensitive logic to an analytic rule with owner, entity mapping, severity, test, and response. Leave exploratory or expensive multi-step reasoning as a hunt/notebook.

Choose KQL jobs, summary rules, or search jobs¶

For the established Sentinel data-lake experience, the July comparison describes these choices. New customers should first apply the September 23 onboarding/access boundary in Section 1 and use the currently documented Fabric paths where applicable:

KQL jobs run one-time or scheduled asynchronous, fuller-KQL queries over data-lake and federated tables and write results to Analytics. They suit historical multi-table investigation or enrichment.
Summary rules periodically aggregate high-volume data into custom Analytics tables, supporting faster repeated detection/reporting with controlled loss of granularity.
Search jobs hydrate results from a single large/historical table into an Analytics custom table for investigation; their operators and scope differ.

The current KQL jobs, summary rules, and search jobs comparison is essential because supported source tiers, joins, scheduling, lookback, timeouts, and cost differ. Choose based on the investigation question, not the newest feature.

In the established job experience, KQL jobs support on-demand/daily/weekly/monthly work; summary rules can run from every 20 minutes to daily; search jobs hydrate a single table. A requirement to aggregate every 20 minutes therefore needs a supported summary workflow or separately designed Fabric schedule, not an assumed 20-minute Sentinel KQL-job setting. Data archived before lake onboarding may still require search jobs. These choices do not recover data that was never collected or has expired.

For a KQL job, define time range, source tables/tier, result table, schedule, cost guardrail, permissions, idempotency/deduplication, and lifecycle. For a summary table, document grain, dimensions, aggregation window, source latency, retained detail, update behavior, and consumer detections. Always retain a path back to raw evidence when required.

Use notebooks for advanced, documented analysis¶

The established Sentinel data-lake notebook experience uses Visual Studio Code with Jupyter, Python, Spark and the Microsoft Sentinel extension/provider. September guidance directs new customers toward Fabric notebooks; record the actual runtime and connection model before following code from either experience. They suit multi-step transformations, visualization, statistical/ML work, reusable investigation narrative, and scheduled jobs. Select runtime size consciously and treat notebook output/custom tables as governed data.

Use a clean environment, pin/document logic, protect credentials, separate exploratory from production notebooks, parameterize tenant/time/entity inputs, avoid unnecessary data export, and validate results with KQL/source records. Review current Sentinel data-lake notebook guidance for permissions, runtime, library, concurrency, and timeout limits.

Connect to the Sentinel MCP Server safely¶

The hosted Sentinel MCP Server exposes scenario-focused tool collections to compatible AI clients for data exploration, entity analysis, incident triage, hunting, and agent building. Most data-exploration capabilities require Sentinel data-lake onboarding, and the user/client retains permission requirements. The MCP getting-started guide lists prerequisites and current clients.

The triage collection specifically accepts Defender XDR, Endpoint or Sentinel onboarded to Defender; do not assume every MCP collection needs the same lake prerequisites. The getting-started page calls for Security Reader to list/invoke tools and preserves existing permissions for triage. Start with table discovery, retrieve the selected schema, then run a bounded query. Even file pivots differ: some triage tools accept SHA-256 while file-alert/device tools document SHA-1 only. Do not claim that a natural-language request grants an unavailable permission or hash conversion.

Treat MCP as a governed tool boundary:

authenticate with Entra and least privilege; do not expose a broad shared identity;
approve only needed collections/tools and limit client/workspace scope;
treat alert text, logs, files, and external intelligence as untrusted prompt content;
inspect tool inputs/results, source tables, time range, and evidence behind conclusions;
prevent an exploratory agent from taking destructive response actions;
audit sessions and test data leakage, prompt injection, overbroad retrieval, and failure handling.

Natural language lowers the query barrier but does not eliminate schema, evidence, or critical-thinking requirements. Reproduce high-impact findings with deterministic queries or records.

VERIFY CURRENT: Sentinel Graph, data-lake jobs/notebooks, MCP tool collections, compatible clients, licensing, region availability, roles, and preview/GA boundaries are fast-moving July 2026-era capabilities.

Related item: Security Copilot, an embedded agent, a notebook, a playbook, and an MCP-connected client can all participate in one workflow. Document which identity executes each step and where human approval and audit evidence live.

4. Integrated scenarios¶

Scenario 1 — Business email compromise becomes ransomware¶

A finance user opens a malicious attachment. The attacker steals a session, registers persistence, consents an OAuth app, uses remote administration on a workstation, compromises an on-premises admin, and begins encrypting a file server.

Reasoning path:

Validate and correlate Office 365, Entra, Endpoint, Defender for Identity, and Sentinel evidence into one UTC timeline.
Determine the initial message/recipients, clicked URL/file, token/app activity, process tree, credential/lateral-movement path, affected devices, and encryption scope.
Review automatic attack disruption and AIR actions; confirm which users/devices were contained and what remains active.
Preserve volatile and message evidence, isolate affected endpoints where safe, revoke sessions/consent, disable or reset compromised identities from a clean admin path, block indicators, and protect recovery systems.
Find persistence in mailbox rules, OAuth grants, scheduled tasks/services, directory privilege, remote tools, and backup access.
Recover in business-priority order, validate clean identity/device state, monitor recurrence, and update detection/automation.

Evidence: incident graph and timeline, mail/header/campaign records, OAuth/audit changes, device process/network events and package, identity lateral-movement evidence, action history, containment authorization, recovery validation, root cause, and tuned detections.

Scenario 2 — Cost-aware multicloud ingestion and a suspicious workload¶

A SOC ingests Azure, AWS, firewall CEF, Windows WEF, and Linux Syslog data into one workspace. Cost rises 70%, a critical Azure workload alert fires, and analysts discover a missing identity field in firewall events.

Reasoning path:

Define the critical workload attack questions and required fields/latency/retention before changing data plans.
Validate each source end to end: policy/diagnostic settings, WEF-to-AMA/DCR, Linux forwarder/DCR/CEF parsing, multicloud connector, and Defender for Cloud integration.
Investigate the workload alert across control-plane changes, identity, endpoint/workload, network, and posture/attack-path evidence.
Use SOC optimization and usage queries to identify unused/verbose tables and columns, but preserve regulatory and forensic requirements.
Keep detection-critical data in Analytics; consider data lake/basic/auxiliary/long-term options for appropriate sources and use summaries/jobs for repeatable historical questions.
Fix the CEF mapping and replay a synthetic event before relying on entity correlation.

Evidence: source/use-case matrix, connector health/freshness tests, parsed sample fields, table plan/retention decision, before/after volume/cost, incident case, containment record, and rule regression tests.

Scenario 3 — Long-horizon identity hunt with AI assistance¶

Threat intelligence suggests an adversary quietly abuses dormant accounts over nine months. The recent Analytics window is clean; data exists in the Sentinel data lake. An analyst chooses supported jobs/search, a notebook, a graph and an MCP-connected assistant after checking the tenant onboarding cohort and retention path.

Reasoning path:

State the hypothesis and define dormant-account baseline, time window, authoritative identity/sign-in/activity tables, and exclusions.
Choose a supported retrieval route: an established lake KQL job, a search job for extended Analytics history, or a Fabric workflow whose mirror actually covers the required dates. Record query, cost, schedule, result location and missing history.
Use a notebook for sequence/baseline analysis and Sentinel Graph to inspect privilege and asset relationships; validate high-impact edges against raw records.
Ask the MCP tool to find supporting and disconfirming evidence, then inspect actual tool results and reproduce important findings deterministically.
Open a hunt/case with bookmarks, scope identities/devices/apps, contain only after confidence and business-owner checks, and preserve evidence.
Create a summary/detection only if the pattern is stable and response-actionable; document data-lake and field dependencies.

Evidence: hypothesis, permissions and tool audit, KQL job definition/history, notebook/version/output, graph pivots, MCP prompts/tool results, raw-source confirmation, bookmarks, case actions, and operationalized rule test.

5. Study and readiness plan¶

Four-week applied plan¶

Week 1 — Platform and ingestion: Map every objective. Configure or tabletop workspace/portal, roles, data tiers/retention, workbooks, SOC optimization, connectors, AMA/DCR, WEF, Syslog/CEF, diagnostics, indicators, and custom tables. Produce a source/use-case matrix and three freshness/field-quality queries.

Week 2 — Detection and automation: Build one Defender custom detection and one Sentinel scheduled or NRT analytic. Add ATT&CK/entity mappings, validate benign/malicious tests, configure a safe automation rule/playbook, and inspect AIR/attack-disruption/device-group settings.

Week 3 — Incident response: Work the cross-domain and cloud-workload scenarios. Practice Defender incident/entity/timeline pivots, Endpoint actions, Purview/Entra/Identity/Cloud Apps evidence, Sentinel case management, Audit/eDiscovery/Graph logs, and agentic-investigation verification.

Week 4 — Hunting and consolidation: Write KQL from scratch, then practice data-lake jobs, summaries, notebooks, graphs, and MCP as available or tabletop them from documentation. Take the free Practice Assessment, research every weak answer, repeat labs, and do a timed original-question review.

Readiness rubric¶

You are approaching readiness when you can, without step-by-step instructions:

map every blueprint bullet to a feature, decision, implementation surface, and validation artifact;
explain AIR versus attack disruption versus Defender custom detections versus Sentinel automation/playbooks;
choose a Sentinel data/retention tier from latency, query, history, cost, and compliance requirements;
trace Windows, Syslog/CEF, Azure, threat-intelligence, and custom ingestion from source to usable fields;
build/tune a KQL detection with entity mapping, ATT&CK, grouping, test, and response;
investigate a multi-domain incident and justify containment order;
select Advanced Hunting, a Sentinel hunt, KQL job, summary rule, search job, graph, notebook, or MCP tool for a given question;
identify limitations, permissions, evidence, and verification for AI-assisted analysis.

6. Hands-on labs¶

Use a disposable tenant/subscription and synthetic data. Defender, Purview, Sentinel data-lake, graph, Security Copilot, and agentic features may require licenses, preview enrollment, or provider-hosted labs. Tabletop unavailable features using current documentation. The public MicrosoftLearning SC-200 lab repository is designed around a training environment; read its setup instructions before use.

Lab 1 — Automation and action boundaries¶

Inventory Defender notifications, Endpoint advanced features, device groups, permissions, automation levels, AIR, and attack-disruption prerequisites.
Create a synthetic low-severity incident and a Sentinel automation rule that tags, assigns, and invokes a non-destructive notification/enrichment playbook.
Test ordering, condition mismatch, duplicate execution, connector failure, retry, and expiry.
Tabletop a high-confidence ransomware incident and define which actions remain manual.

Evidence: configuration matrix, least-privilege identities, rule/playbook export or diagram, run history, failure/rollback notes, and approval boundary.

Lab 2 — Workspace, roles, tiers, workbook, and optimization¶

Define workspace boundaries for a two-region, two-team SOC.
Map Reader/Responder/Contributor/Playbook Operator and data-lake access to five job tasks.
Classify six tables among Analytics/data lake/basic/auxiliary/long-term options from use cases.
Build a connector-health or incident-aging workbook with scope/time/drill-down.
Evaluate three SOC optimization recommendations and document accept/dismiss reasoning.

Evidence: topology, role matrix, table/retention/cost decision, workbook export/screenshot plus queries, and optimization decisions.

Lab 3 — Multisource ingestion validation¶

Define security questions and fields for Windows logon, firewall connection, Linux authentication, Azure resource change, and threat-indicator sources.
Configure or diagram Windows Events via AMA/DCR and a WEF collector path.
Configure or diagram a Linux Syslog/CEF forwarder and DCR.
Create an Azure Policy/diagnostic-settings plan and custom-table schema.
Generate/tabletop one event per source and trace arrival, latency, parsing, entity fields, and failure alert.

Evidence: data-flow diagrams, DCR/policy/schema artifacts, sample queries/results, latency/field test table, and troubleshooting runbook.

Lab 4 — Detection engineering with KQL¶

Choose a safe hypothesis such as repeated failures followed by success or suspicious process/network behavior.
Write a time-bounded query, inspect schema, filter/project early, aggregate, and enrich entities.
Adapt it to a Defender custom detection or Sentinel scheduled/NRT analytic as appropriate.
Configure grouping, ATT&CK mapping, severity, custom details, and response action without destructive automation.
Replay benign/malicious synthetic cases and tune without hiding variants.

Evidence: hypothesis, query versions, rule configuration, test data/results, false-positive notes, and owner/tuning cadence.

Lab 5 — Cross-domain incident investigation¶

Use a simulated phishing-to-endpoint incident or the Microsoft lab scenario.
Build a UTC timeline across mail, user/sign-in, endpoint process/network, OAuth, and identity evidence.
Identify initial access, persistence, lateral movement, scope, and potential data impact.
Use bookmarks/comments/tasks and record confidence versus unknowns.
Propose ordered containment, eradication, recovery, and validation steps.

Evidence: incident/case record, entity/timeline graph, evidence references, hypotheses, actions/approvals, and closure criteria.

Lab 6 — Endpoint response and attack disruption¶

Investigate a synthetic device alert and review timeline, process tree, file/user/IP entities, prevalence, and related alerts.
Collect or tabletop an investigation package before altering the endpoint.
Test a safe action such as antivirus scan in an authorized lab; document isolation/live-response prerequisites and undo paths.
Review Action center/AIR evidence and tabletop automatic attack-disruption containment.
Verify persistence removal and restored telemetry.

Evidence: device/action timeline, hashes/commands, package record, action authorization/result, disruption review, and recovery validation.

Lab 7 — Microsoft 365 evidence search¶

Generate or use synthetic mailbox/file/app activity.
Define and run/tabletop a Purview Audit search with exact operations, users, and UTC range.
Design a least-scope eDiscovery Content search and record authorization/export controls.
Query or inspect Graph activity-log records and correlate request/client/app/user identifiers.
Compare which evidence each log/search can and cannot establish.

Evidence: search definitions, result samples, role/privacy decisions, correlation table, export/hash procedure, and identified blind spots.

Lab 8 — Long-term hunt, graph, notebook, and MCP¶

State a long-horizon hypothesis and map tables/fields/time/expected benign behavior.
Record the onboarding cohort and compare a supported KQL job, summary rule, search job and Fabric workflow; verify the historical data is actually reachable.
Create a small parameterized notebook or pseudocode analysis and specify runtime/output governance.
Inspect a hunting/blast-radius graph and validate two edges from source evidence.
Use or tabletop Sentinel MCP prompts that seek both supporting and disconfirming evidence; constrain permissions and tools.
Decide whether the result becomes a bookmark, case, analytic, summary, or documented null hunt.

Evidence: hypothesis/query/job, summary grain if used, notebook, graph validation, MCP tool trace, cost/permission record, and operationalization decision.

Lab 9 — Detection evidence and automation identity¶

Use the synthetic event pair in Section 1 to compare independent maxima with a same-event aggregation. Preserve device and scope boundaries.
Tabletop converting a hunt into a rule: entity fields, workload permissions, configured lookback, alert cap and Continuous eligibility.
Test old/new account payloads, alex, alex-admin, an attacker-controlled lookalike suffix, and a missing tenant/object ID.
Route ambiguous identity or scope to analyst review; prove duplicate input does not repeat a containment action.

Evidence: expected/actual synthetic results, rule design, unresolved availability check, input/output identity contract and replay decision. No live response action is required.

Lab 10 — Retention, fresh ingestion and cloud-incident evidence¶

Record whether the tenant predates September 23 lake onboarding changes. Map Analytics, lake-only, extended retention and Fabric mirror coverage.
Tabletop the 120-day event with 90-day Analytics retention. Identify the supported historical query route and why a new mirror cannot backfill it.
Compare one active producer with a deliberately silent inventory entry; explain why the 30-minute query alone misses the silent source.
Estimate the custom-collection cap and distinguish source time, ingestion time and NRT alert delay.
Build a benign Storm-3168-inspired evidence matrix: workload sign-ins, AzureActivity, service data-plane logs, role assignments and recovery state. Separate attempted, successful and unconfirmed activity.

Evidence: cohort/access matrix, missing-history result, source-health test, arithmetic, incident timeline and credential-recovery checklist. Use synthetic records; no destructive cloud operations.

7. Knowledge checks¶

These are original study questions, not recalled exam content.

Why is an email notification not incident ownership? Delivery can fail or be ignored; an operational queue, on-call process, escalation, and acknowledgment establish ownership.
How should you suppress a recurring benign alert? Confirm the pattern, create the narrowest condition, preserve malicious variants/high-value scope, record owner/expiry, and regression-test it.
How do an indicator, ASR rule, and custom detection differ? An indicator allows/audits/warns/blocks known artifacts; ASR reduces classes of endpoint behavior; a custom detection queries telemetry to alert or act.
What does AIR provide? Automated evidence investigation and verdict/remediation workflow governed by product and device-group automation settings.
How is automatic attack disruption different from an ordinary playbook? It uses high-confidence, correlated cross-domain Defender signals and built-in containment logic; a playbook executes explicitly designed Logic Apps workflow.
Why do device-group rank and automation level belong together? Overlap resolution determines which permissions and remediation behavior apply to the device.
When should a playbook require approval? Before ambiguous, destructive, irreversible, legally sensitive, or high-business-impact actions.
What four permission planes should you test for a playbook? Analyst/workspace visibility, incident management, Sentinel invocation, and the playbook identity's downstream action.
Why is one centralized Sentinel workspace not automatically best? Residency, tenant, billing, access isolation, ownership, volume, and delegated operations may justify boundaries despite correlation benefits.
What belongs in Analytics rather than only the data lake? Data requiring supported low-latency detection/investigation queries and actions; exact eligibility and features must be verified per table.
Why can low-cost storage increase total risk or cost? Unsupported/slow queries can miss detection SLAs or require expensive scans/hydration during incidents.
What makes a workbook operationally useful? A defined question, correct denominator/scope/time, validated queries, and drill-down to actionable evidence.
Why review rather than automatically apply SOC optimization? Recent usage cannot fully capture compliance, rare-but-critical investigations, seasonal threats, or custom/downstream dependencies.
What proves a connector works? A known source action appears in the intended table on time with required parsed/entity fields and downstream detection behavior.
How do AMA/DCR and WEF relate? WEF aggregates Windows events to a collector; AMA/DCR selects and routes the collector/source events into Azure Monitor/Sentinel.
Where do Syslog and CEF via AMA normally land? Syslog and CommonSecurityLog, respectively, subject to correct streams and parsing.
What does Azure Policy add to diagnostic settings? At-scale deployment/compliance/remediation; it does not prove that expected resource logs arrive.
Why must threat indicators expire? Infrastructure changes; stale indicators create noise, misleading matches, and unnecessary cost.
When is a custom table justified? When a defined security use case needs data not represented appropriately elsewhere and schema, collection, access, plan, retention, and ownership are designed.
Scheduled versus NRT analytic? Scheduled rules offer configurable cadence/lookback; NRT rules run every minute with constrained low-latency behavior for eligible queries.
Why map entities in an analytic? Correct mappings enable correlation, graphs, investigation pivots, automation context, and case scope.
What does an ATT&CK mapping prove? Intended technique coverage—not that telemetry, query, alert, and response work in the environment.
What is the first response step after an alert? Validate the signal, data/source health, time, scope, and current attack state before choosing action.
Why can isolating a device be harmful? It may interrupt critical service, remote evidence access, or coordinated identity investigation; authorization and undo paths matter.
What should you verify after attack disruption? Exact contained entities/actions, remaining scope/persistence, business impact, credential recovery, telemetry, and recurrence.
Why are Purview insider-risk findings handled differently? Privacy, pseudonymization, role separation, legal/HR authorization, and incomplete behavioral context demand controlled review.
What is the danger of an AI-generated incident summary? It can confidently merge inference with fact; verify citations, queries, entities, time, and disconfirming evidence.
What distinguishes status from classification? Status tracks workflow state; classification records whether/why the detection represented malicious or benign activity.
What does a device timeline establish? Ordered endpoint telemetry for that device; it does not alone establish attacker intent or full cross-domain scope.
How do Audit, eDiscovery Content search, and Graph activity logs differ? Audit records activities, Content search finds authorized stored content, and Graph logs record API requests; each has different schema, scope, latency, and retention.
Why choose the table before writing KQL? The event owner, schema, retention, and semantics determine whether the query can answer the hypothesis correctly.
When should a hunt become a detection? When logic is repeatable, timely, sufficiently precise, tested, owned, and connected to an actionable response.
KQL job versus summary rule versus search job? KQL jobs run fuller multi-table lake queries; summaries repeatedly aggregate into Analytics; search jobs hydrate results from a large single table under different constraints.
Why validate a graph edge? It is a modeled relationship that may be stale, indirect, or incomplete; source evidence establishes the relevant fact and time.
When is a notebook better than one KQL query? For documented multi-step analysis, Spark/Python transformations, statistics/ML, visualization, or scheduled data-lake processing.
What is the core MCP safety boundary? The connected identity, allowed tools/workspaces, untrusted retrieved content, action authority, audit, and deterministic verification of important results.
Why can two independent maxima make bad detection evidence? The selected time and report ID can come from different rows. Preserve a single event with arg_max and its device/scope context.
Does Defender Continuous's one-table rule govern Sentinel NRT? No. Sentinel NRT supports multiple tables/workspaces under its own limits; Sentinel data in Defender Continuous has conflicting current documentation and needs verification.
What happens when one device/rule reaches 75,000 custom events in rolling 24 hours? That custom rule stops collecting until its rolling budget permits collection; default EDR continues. Do not assume midnight reset or replay.
Why can StartsWith("alex") be unsafe for automatic containment? It can identify several principals. Validate the full normalized identity and tenant/object ID; prefix matching is not authorization.
Can two years of retention guarantee a 120-day Advanced Hunting result? No. The documented new-tenant extended-Analytics path with 90-day interactive retention needs search jobs for older data; a new Fabric mirror does not backfill history.
Does a green connector prove five-minute freshness? No. Some connector indicators reflect ingestion within 14 days; measure known producer arrival, missing sources and required fields.
Why deduplicate threat-intelligence versions before filtering deleted rows? Otherwise an earlier active version can survive after its later deletion; republishing also does not mean a newly observed threat.
Does a successful Graph request or key-read operation prove data exfiltration? No. Preserve request identity, result and workload evidence, and explicitly label what was accessed, attempted or unconfirmed.

Places to learn¶

This is a curated starting point, not a complete list. Do not try to consume every resource. Pick a primary path that fits how you learn, use documentation and labs for weak areas, and use assessments to decide what to revisit. Verify every course against the October 21, 2026 blueprint—especially data-lake tiers/jobs, Sentinel Graph, agentic investigation, embedded Security Copilot, and Sentinel MCP Server.

October 28 learning route and evidence task¶

The current four-day Microsoft course and ten selected path outlines still provide 59 module placements. Begin with KQL, then workspace/ingestion, product investigations, detections and hunting; use Security Copilot after you can inspect its underlying evidence. This is a suggested learning order, not a replacement blueprint. The course lab README is a written companion, with separate training materials and preparation requirements; no hosted environment or full fresh runtime was established. Existing resources are sufficient for this route.

Original worksheet (about 30–45 minutes, editorial estimate): Inventory twelve expected log producers. Supply synthetic timely records for nine and none for three. Build a freshness worksheet with producer ID, source time, arrival time, expected cadence, last-seen age and triage owner; include the three absent producers in the denominator.

Answer checkpoint: Nine timely arrivals out of nine returned records do not establish twelve healthy producers. Mark the three silent sources unresolved and distinguish missing telemetry from a negative security finding. No connector, KQL job or response action was executed for this exercise.

Time-planning summary¶

Resource	Access	Estimated time
Official blueprint, credential/exam page, and change log	Free	45–75 minutes
Ten official Microsoft Learn paths in the current course syllabus	Free	Earlier 43h12 total is historical; allow 55–75 hours as a study estimate and inspect current modules
SC-200T00-A instructor-led course	Provider/schedule dependent	4 days
Microsoft Learn free Practice Assessment	Free; launch from credential page	45–75 minutes per attempt plus 1–3 hours source review
MicrosoftLearning public SC-200 labs	Free; many expect a prepared tenant	10–20 hours selected labs; full use depends on environment
Microsoft Exam Readiness Zone SC-200 videos	Free	About 1–2 hours; reconcile the recording date with July 2026
Pluralsight SC-200 path	Paid/trial	6h09 summed course durations (path rounds to six hours); 2022–2024 recordings
O'Reilly/Packt SC-200 video	Paid/trial	Earlier 12h50/June 2022 metadata; current page access blocked
O'Reilly live SC-200 crash course by Tim Warner	Paid/subscription; schedule dependent	2 sessions of 3 hours (6 hours listed) plus review; older domain wording
Microsoft Press Exam Ref SC-200, 2nd Edition	Paid; preview/sample availability varies	320 pages; allow about 12–20 hours plus labs
Udemy 2026 SC-200 practice tests by Dean Ellerby	Paid	Earlier six tests/360 questions; current page access blocked
MeasureUp SC-200 practice test	Paid; demo available	170 questions; allow about 7–12 hours for diagnostic, review, and timed retest
Partner Skilling Hub SC-200 offering	Microsoft partner login required	Schedule-dependent; allow about 4–5 days for a certification-week format, verify listing

Official Microsoft resources¶

SC-200 study guide — current accepted October 21 outline and change log; July bytes archived.
Security Operations Analyst Associate credential — status, renewal, 100-minute exam, free Practice Assessment, sandbox, and prep-video entry point.
SC-200T00-A course — four instructor-led days and the current self-directed syllabus.
Mitigate threats using Defender XDR — earlier 6 hours 6 minutes duration is historical; inspect current modules.
Mitigate threats using Security Copilot — earlier 4 hours 54 minutes duration is historical; inspect current modules.
Mitigate threats using Microsoft Purview — earlier 4 hours 19 minutes duration is historical; inspect current modules.
Mitigate threats using Defender for Endpoint — earlier 5 hours 49 minutes duration is historical; inspect current modules.
Mitigate threats using Defender for Cloud — earlier 4 hours 17 minutes duration is historical; inspect current modules.
Create Sentinel queries with KQL — earlier 2 hours 10 minutes duration is historical; inspect current modules.
Configure your Sentinel environment — earlier 3 hours 45 minutes duration is historical; inspect current modules.
Connect logs to Sentinel — earlier 3 hours 4 minutes duration is historical; inspect current modules.
Create detections and investigate with Sentinel — earlier 6 hours 34 minutes duration is historical; inspect current modules.
Perform threat hunting in Sentinel — earlier 2 hours 14 minutes duration is historical; inspect current modules.
MicrosoftLearning SC-200 lab repository — public course lab instructions and setup notes.
Use the prep-video link on the credential page for Microsoft's Exam Readiness Zone material; verify the episode date and its objective weights before relying on it.

Video, books, and structured courses¶

Pluralsight Microsoft Security Operations Analyst (SC-200) — three courses totaling 6h09 (1h53 + 2h26 + 1h50), rounded to six path hours, and a practice exam. The listed courses date from 2022–2024 and still use older product/domain language, so use them for foundations and build a July 2026 gap list.
O'Reilly/Packt SC-200 Microsoft Security Operations Analyst — earlier catalog metadata: 12h50 with Anand Rao Nednur, June 2022. Current access was blocked; content was not reverified. That historical edition predates Defender-portal unification and the current data-lake, graph, MCP, Copilot, and agentic objectives.
O'Reilly live SC-200 crash course with Tim Warner — two three-hour sessions in the listed agenda. Verify the next event date and treat its older Microsoft 365 Defender/domain terminology as supplemental.
Microsoft Press Exam Ref SC-200, 2nd Edition by Yuri Diogenes and Sarah Young — 320 pages, published May 11, 2026. Its contents list four older domains plus an exam-updates chapter; the public listing alone does not establish complete July/October coverage. No purchased book content was reviewed.
Udemy SC-200 practice tests (2026) by Dean Ellerby — earlier catalog metadata: six tests/360 questions and August 2026 update. Current access was blocked, so availability, explanations and objective coverage remain unverified.
Cloud 360 Training SC-200 course — earlier February 2025 series metadata; current retrieval returned a shell. Video content, runtime and current-objective completeness were not reverified.
John Savill's Technical Training channel is excellent for Microsoft security foundations, and his public Azure Master Class repository includes monitoring/security material and downloadable whiteboards. No current SC-200-specific course was confirmed in this review, so use individual KQL, Sentinel, Defender, and security videos only as product background and verify every topic against current documentation.

Assessment and partner resources¶

Use the free Microsoft Practice Assessment on the SC-200 credential page as a diagnostic, not a question bank. Research every weak or ambiguous answer in current product documentation.
MeasureUp SC-200 practice test — 170 questions and an August 2026 update in the current public catalog; listed domain counts are 77 + 62 + 31. The catalog also has generic question-count/duration claims; use Microsoft for exam administration. No paid questions or demo were reviewed, and this count is not a completeness guarantee.
Microsoft Partner Skilling Hub security playbook lists Security Operations Analyst (SC-200) among security credential offerings. Partner sign-in is required for underlying event content; dates and duration are schedule-specific.

Useful blog reading with an operator task¶

sagiyagen365 (Microsoft), February 10, 2026 — Account Name entity mapping update. Read the payload change and test the identity examples in Section 1. The July 1 change is already effective. Separate broad compatibility filtering from authorization for a specific principal. Allow 20–30 minutes for reading and synthetic tests.
Microsoft Security Research, Yossi Weizman and Tushar Mudi, September 25, 2026 — Storm-3168 cloud investigation. Build an evidence timeline across workload identities, resource operations and service logs. Distinguish failed deletion attempts from successful operations and rotate exposed credentials in the tabletop. The report does not confirm that the publicly exposed secret caused initial access or that exfiltration/ransom occurred. A compromised ordinary service principal is not automatically an Agent ID object. Allow 45–60 minutes; do not reproduce destructive operations.

Public article text was read; gated threat intelligence, videos and customer outcomes were not tested. The ten Learn path landing pages list 59 modules; individual modules were not completed or timed. The lab repository README was reviewed, not every lab instruction. O'Reilly's public live agenda shows two three-hour sessions, but no next-event availability was verified. Partner PDF retrieval did not establish current underlying event dates. YouTube pages returned shells. No paid lessons, question banks or signed-in Practice Assessment were completed.

The deep-review record maps 54 October objectives and records the open Microsoft documentation conflicts, source observations, follow-up dates and execution limits. Human review remains pending.

Avoid sites selling “real questions,” dumps, guarantees based on recalled exam content, or unauthorized copies. Use original practice questions, the free official assessment, current documentation, and authorized labs to build transferable security-operations skill.