Official exam objectives

SC-200 Exam Blueprint

Skills measured by Microsoft, organized into three weighted domains and nine functional groups.

Open official blueprint ↗
Effective July 28, 202654 objectives3 weighted domains

Open a functional group to explore its objectives. Related learning-path notes are linked directly, and supplemental study packs appear inside the objectives that need additional material.

01

Manage a security operations environment

Automation, Sentinel configuration, ingestion, and detection engineering

40–45% · 27 objectives
Configure automation for Microsoft Defender XDR and Microsoft Sentinel11 objectives

Configure email notifications in Microsoft Defender XDR, including incidents, actions, and threat analytics.

Study notes & practiceBrief · concepts · checklist · exercise

Study brief

Microsoft Defender XDR can send separate email notifications for new incidents, completed or failed response actions, and new or updated threat analytics reports. Each notification type has its own rule, scope, recipients, and test workflow under Settings > Microsoft Defender XDR > Email notifications.

Key concepts

  • Incident rules can filter by alert severity, detection source, and device group. Defender sends one email for each new incident that matches the rule rather than one email for every alert in the incident.
  • Response-action rules can filter manual or automated actions by action type, device group, and completion status. Custom detections that contain response actions are not supported by these notifications.
  • Threat analytics rules can notify recipients about all new or updated reports or only reports that match selected threat types and tags.
  • Recipients receive tenant-specific links, so access still depends on portal permissions and role scope. Creating notification rules requires permission to manage security settings.

Exam checklist

  • Choose the correct notification category for an incident, response action, or threat intelligence report.
  • Configure a rule name, scope or filters, recipient addresses, and notification frequency where available.
  • Recognize the effect of severity, detection-source, device-group, action-status, threat-type, and tag filters.
  • Send a test notification and verify both delivery and the recipient's authorization to open the linked portal record.

Hands-on exercise

Build and validate three Defender XDR notification rules

  1. Open Settings > Microsoft Defender XDR > Email notifications and review the Incidents, Actions, and Threat analytics tabs.
  2. Create a narrowly scoped incident rule for high-severity incidents from selected detection sources and add a test recipient.
  3. Draft equivalent rules for failed response actions and selected threat analytics report types or tags.
  4. Use the test function, confirm delivery, and document which events do and do not trigger each rule.

Official Microsoft resources

Get email notifications on incidents ↗Get email notifications for response actions ↗Get email notifications for threat analytics ↗

Related learning-path notes

Configure alert notifications in Microsoft Defender XDR, including tuning, suppression, and correlation.

Study notes & practiceBrief · concepts · checklist · exercise

Study brief

Alert behavior in Microsoft Defender XDR is controlled through alert policies, alert tuning, custom detection settings, and correlation settings. The goal is to reduce known benign noise without hiding meaningful evidence or preventing related alerts from becoming a coherent incident.

Key concepts

  • An alert policy defines the triggering activity and conditions, thresholds or unusual behavior, severity, category, aggregation, and optional recipient notifications.
  • Alert tuning rules suppress known benign scenarios for supported built-in alerts. Suppression should use precise evidence and be reviewed because broad conditions can conceal true positives.
  • Tuning a built-in alert does not disable automated investigation and response or its email notifications; malicious or suspicious investigation results can reactivate the alert.
  • Microsoft Sentinel analytics rules can be included in or excluded from the Defender XDR correlation engine. Excluded rules bypass XDR correlation and use their own incident-grouping behavior.
  • Custom detection rules can be enabled, disabled, edited, run, and explicitly included in or excluded from incident correlation.

Exam checklist

  • Distinguish alert generation, email notification, suppression or tuning, and incident correlation.
  • Create narrowly scoped tuning conditions from a reviewed false-positive alert and predict which future alerts will be hidden.
  • Explain how automated investigation can override suppression when it finds suspicious or malicious evidence.
  • Choose whether a Sentinel analytics rule or custom detection should participate in XDR correlation and understand the effect of exclusion.

Hands-on exercise

Tune a benign alert and verify incident correlation

  1. Choose a recurring benign alert and record the stable attributes that distinguish it from malicious activity.
  2. Create or draft an alert tuning rule with the narrowest practical conditions, then document its owner and review date.
  3. Inspect the relevant custom detection or Sentinel analytics rule and verify whether it is included in XDR correlation.
  4. Generate or replay matching and nonmatching test activity, then verify alert visibility, notification behavior, and incident grouping.

Official Microsoft resources

Alert policies in Microsoft Defender XDR ↗Alert tuning for built-in alert policies ↗Include or exclude Sentinel rules from XDR correlation ↗Manage custom detection rules ↗

Related learning-path notes

Configure Microsoft Defender for Endpoint advanced features.

Related learning-path notes

Configure rules settings in Microsoft Defender for Endpoint.

Study notes & practiceBrief · concepts · checklist · exercise

Study brief

Microsoft Defender for Endpoint security settings can be managed from the Defender portal with endpoint security policies. A policy combines a platform and template, configuration settings, and device assignments; effective configuration also depends on policy precedence, enrollment state, licensing, permissions, and device connectivity.

Key concepts

  • In Endpoints > Configuration management > Endpoint security policies, an administrator selects a platform and template, configures settings, assigns device groups, and reviews the policy before creation.
  • Managing policies requires access to all devices and the Core security settings (manage) permission. Role and device-group scope affect what an administrator can view or change.
  • Existing policies can be edited by section, including Basics, Settings, and Assignments. Changes must be validated on targeted devices rather than assumed from portal state alone.
  • Conflicting settings can come from multiple management authorities or policies. Troubleshooting requires identifying the winning source and supported precedence behavior.

Exam checklist

  • Identify the prerequisites and permissions for Defender security settings management.
  • Create an endpoint security policy with the correct platform, template, configuration, and assignment scope.
  • Edit policy settings or assignments and verify deployment and effective state on representative devices.
  • Troubleshoot a conflict by checking policy sources, precedence, device onboarding or enrollment, and connectivity.

Hands-on exercise

Configure and troubleshoot an endpoint security policy

  1. Create a small test device group and confirm that the required Defender for Endpoint permissions and licenses are available.
  2. Create an endpoint security policy from an appropriate platform and template, change one auditable setting, and assign it only to the test group.
  3. Review policy deployment status and confirm the effective value on a test device using supported management or Defender diagnostics.
  4. Introduce or inspect a conflicting policy, identify the effective source, and document the safe resolution.

Official Microsoft resources

Manage endpoint security policies in Microsoft Defender ↗Troubleshoot Microsoft Defender for Endpoint settings ↗Configure and manage Defender for Endpoint automation ↗

Related learning-path notes

Configure custom data collection in Microsoft Defender for Endpoint.

Study notes & practiceBrief · concepts · checklist · exercise

Study brief

Custom data collection in Microsoft Defender for Endpoint uses rule-based filters to collect selected process, image-load, file, network, or script events and send them to a connected Microsoft Sentinel workspace. It supplements the default endpoint telemetry and is intended for focused use cases rather than indiscriminate collection.

Key concepts

  • Rules can filter data by attributes such as folder path, process name, or network connection and write events to the corresponding DeviceCustom*Events table.
  • Supported destinations include DeviceCustomProcessEvents, DeviceCustomImageLoadEvents, DeviceCustomFileEvents, DeviceCustomNetworkEvents, and DeviceCustomScriptEvents.
  • The feature requires Microsoft Defender for Endpoint Plan 2 and a connected Sentinel workspace; current preview constraints include one connected workspace per tenant.
  • Assignments use dynamic device tags rather than manual or static tags. A dynamic tag must have evaluated at least once before it can be selected.
  • A rule can take approximately 20 minutes to one hour to reach endpoints. Collection volume, table cost, supported operating systems, and preview limitations must be considered before broad deployment.

Exam checklist

  • Match an event type to the correct DeviceCustom*Events destination table.
  • Verify licensing, Sentinel workspace connection, supported endpoints, and dynamic-tag readiness before creating a rule.
  • Build narrow collection filters and assignment scope that capture the required evidence without unnecessary volume.
  • Allow for propagation delay, query the destination table, and distinguish custom events from standard Defender telemetry.

Hands-on exercise

Collect a focused endpoint event set in Sentinel

  1. Define a test scenario, such as process execution from a controlled folder, and choose the matching custom event table.
  2. Verify the Sentinel connection and create or confirm a dynamic device tag for a small endpoint scope.
  3. Create a narrowly filtered custom data collection rule, assign the dynamic tag, and wait for policy propagation.
  4. Generate the test event, query the destination DeviceCustom*Events table, and record latency, volume, and any filter adjustments.

Official Microsoft resources

Custom data collection in Defender for Endpoint ↗Create custom data collection rules ↗

Related learning-path notes

Configure security policies for Microsoft Defender for Endpoint, including attack surface reduction rules.

Related learning-path notes

Manage automated investigation and response capabilities in Microsoft Defender XDR.

Related learning-path notes

Configure automatic attack disruption in Microsoft Defender XDR.

Related learning-path notes

Configure and manage device groups, permissions, and automation levels in Microsoft Defender for Endpoint.

Related learning-path notes

Create and configure automation rules in Microsoft Sentinel.

Related learning-path notes

Create and configure Microsoft Sentinel playbooks.

Related learning-path notes

Configure the Microsoft Sentinel SIEM and platform4 objectives

Specify Microsoft Sentinel roles.

Related learning-path notes

Manage data retention for XDR and Microsoft Sentinel tables, including Analytics, Data Lake, and XDR tiers.

Study notes & practiceBrief · concepts · checklist · exercise

Study brief

Retention in the unified security operations platform separates fast, interactive Analytics-tier access from long-term Data Lake storage and the Defender XDR advanced-hunting window. Table plans, analytics retention, and total retention must be configured according to investigation speed, detection dependencies, compliance, and cost.

Key concepts

  • The Analytics tier supports real-time analytics rules, hunting, workbooks, and interactive queries. Sentinel and XDR tables commonly begin with 30 days of analytics retention, while eligible Sentinel solution tables receive up to 90 days at no retention charge.
  • Analytics retention can be extended up to two years. Total retention preserves older data in the data lake and can be extended up to 12 years.
  • Data Lake-only data is designed for lower-cost historical storage and asynchronous analysis with KQL jobs, notebooks, or summary rules; it is not available to real-time analytics and advanced hunting.
  • Defender XDR advanced hunting has a default 30-day window. Eligible XDR tables can extend Analytics-tier access to 90 days and use longer total retention for the data lake.
  • Reducing total retention has a 30-day waiting period before affected data is deleted, while Analytics-tier retention changes take effect immediately. Moving a table out of Analytics can break detections and hunting that depend on it.

Exam checklist

  • Differentiate Analytics retention, total retention, Data Lake-only storage, and the Defender XDR advanced-hunting window.
  • Choose a tier and retention period based on real-time detection, interactive investigation, historical analysis, compliance, and cost requirements.
  • Predict the impact of changing a table from Analytics to Data Lake on rules, hunting, custom detections, and workbooks.
  • Configure table-level retention and account for immediate versus delayed effects when increasing or reducing retention.

Hands-on exercise

Design and validate a tiered retention policy

  1. Select three representative tables: one required for real-time detection, one for frequent investigation, and one for compliance-only history.
  2. Document each table's Analytics retention, total retention, table plan, query use, detection dependencies, and estimated data volume.
  3. Propose tier and retention changes, then verify that no dependent analytics rule, custom detection, workbook, or hunting query loses required access.
  4. Apply the plan in a test workspace if available and confirm both recent interactive queries and the intended historical-access method.

Official Microsoft resources

Microsoft Sentinel data tiers and retention overview ↗Manage table tiers and retention ↗Advanced hunting overview ↗

Related learning-path notes

Create and configure Microsoft Sentinel workbooks.

Related learning-path notes

Optimize the Microsoft Sentinel platform, including SOC optimization recommendations.

Study notes & practiceBrief · concepts · checklist · exercise

Study brief

SOC optimization turns workspace telemetry into recommendations that improve threat coverage, data value, and operational efficiency. Recommendations compare ingested data and enabled detections with the controls needed for relevant threats and business risks.

Key concepts

  • Data value recommendations identify billable tables that are unused or underused and suggest enabling detections, changing the table plan, stopping ingestion, or adjusting retention.
  • Coverage recommendations identify missing detections or data sources. Threat-based recommendations can propose analytics rule templates, connectors, or complete Sentinel solutions.
  • Coverage recommendations can also include AI-assisted MITRE ATT&CK tagging and risk-based recommendations; preview availability can vary.
  • A recommendation is evidence for a decision, not an automatic instruction. Validate detection value, compliance requirements, retention needs, and cost before applying it.

Exam checklist

  • Distinguish data value optimization from coverage optimization.
  • Recognize the response to each condition: data without detections, detections without data, or neither data nor detections.
  • Know that SOC optimization evaluates recent ingestion and enabled analytics to surface actionable recommendations.
  • Review a recommendation, validate its impact, implement the change, and verify that the coverage or cost issue is resolved.

Hands-on exercise

Review and disposition a SOC optimization recommendation

  1. In the Defender portal, open Microsoft Sentinel and locate SOC optimization.
  2. Choose one data value or threat-coverage recommendation and record its evidence, affected tables or detections, and proposed action.
  3. Classify the recommendation as implement, defer, or dismiss and document the security, cost, and compliance rationale.
  4. If a test workspace is available, apply the recommendation and confirm the resulting connector, rule, table plan, or retention state.

Official Microsoft resources

SOC optimization recommendations reference ↗Access SOC optimization ↗
Ingest data into the Microsoft Sentinel SIEM and platform7 objectives

Select data connectors based on data source requirements, including Windows logs and security events.

Related learning-path notes

Configure Windows Security Events via AMA, including data collection rules.

Related learning-path notes

Plan and configure Windows Security events by using Windows Event Forwarding.

Related learning-path notes

Plan and configure Syslog via AMA and Common Event Format via AMA connectors.

Related learning-path notes

Configure collection of Azure activities by using Azure Policy and resource diagnostic settings.

Related learning-path notes

Ingest threat indicators into Microsoft Sentinel.

Related learning-path notes

Create custom log tables in the workspace to store ingested data.

Study notes & practiceBrief · concepts · checklist · exercise

Study brief

A custom Log Analytics table stores data that does not fit a built-in schema. Its schema, destination, and transformation are defined through a data collection rule (DCR), and the ingestion method—such as the Logs Ingestion API or a supported connector—must send records that conform to that contract.

Key concepts

  • Custom table names use the _CL suffix and every table requires a TimeGenerated column. Add only fields that support a clear detection, investigation, reporting, or retention requirement.
  • A DCR defines the input stream, transformation, destination workspace, and destination table. A portal workflow can infer an initial schema and transformation from sample data.
  • If the table schema changes, the associated DCR must also be updated; Azure Monitor does not synchronize that change automatically.
  • The Logs Ingestion API authenticates an application and sends data through a DCR endpoint to supported or custom tables. Transformations can parse, filter, enrich, and normalize records before storage.
  • Creating and managing tables typically requires Log Analytics Contributor or equivalent Microsoft.OperationalInsights/workspaces permissions. Validate schema, access, ingestion health, volume, and cost before production rollout.

Exam checklist

  • Design a custom schema with _CL naming, TimeGenerated, correct data types, and only useful security fields.
  • Explain the relationship among the source payload, data collection endpoint, DCR stream declaration, transformation, workspace, and destination table.
  • Choose an ingestion method and configure the required identity and permissions.
  • Test sample records, query the table, troubleshoot DCR or schema mismatches, and update both the table and DCR when the schema evolves.

Hands-on exercise

Create and populate a custom security log table

  1. Prepare a small JSON sample containing an event timestamp, source, action, result, and investigation identifier with consistent data types.
  2. Create a custom table in the workspace, review the inferred schema, and confirm its _CL name and TimeGenerated mapping.
  3. Review or create the DCR and transformation, then send sample records through the selected connector or Logs Ingestion API.
  4. Query the table, validate parsed values and timestamps, inspect ingestion failures, and document the change process for adding a new column.

Official Microsoft resources

Create a custom table in Azure Monitor Logs ↗Logs Ingestion API overview ↗Transform or customize ingested data in Sentinel ↗Manage tables in a Log Analytics workspace ↗

Related learning-path notes

Configure detections5 objectives

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

Related learning-path notes

Manage custom detection rules in Microsoft Defender XDR.

Related learning-path notes

Configure and manage Sentinel analytics rules, including scheduled, NRT, threat intelligence, and machine learning.

Related learning-path notes

Analyze attack vector coverage by using the MITRE ATT&CK matrix.

Related learning-path notes

Configure anomalies in Microsoft Sentinel.

Related learning-path notes

02

Respond to security incidents

Cross-domain investigation, endpoint response, Purview, and Microsoft 365 activity

35–40% · 17 objectives
Respond to alerts and incidents in Microsoft Defender XDR10 objectives

Investigate and remediate threats by using Microsoft Defender for Office 365, including automatic attack disruption.

Related learning-path notes

Investigate and remediate threats or compromised entities identified by Microsoft Purview.

Related learning-path notes

Investigate and remediate alerts and incidents identified by Microsoft Defender for Cloud workload protections.

Related learning-path notes

Investigate and remediate security risks identified by Microsoft Defender for Cloud Apps.

Related learning-path notes

Investigate and remediate compromised identities identified by Microsoft Entra ID.

Related learning-path notes

Investigate and remediate security alerts from Microsoft Defender for Identity.

Related learning-path notes

Investigate and remediate alerts and incidents identified by Microsoft Sentinel.

Related learning-path notes

Investigate incidents by using agentic AI, including embedded Microsoft Security Copilot.

Study notes & practiceBrief · concepts · checklist · exercise

Study brief

Agentic AI and embedded Microsoft Security Copilot accelerate incident investigation in the Defender portal by summarizing correlated evidence, recommending next steps, and automating selected triage workflows. Analysts remain accountable for validating AI conclusions against the underlying alerts, entities, timelines, and organizational response procedures.

Key concepts

  • Embedded Copilot can summarize an incident's attack timeline, affected assets, indicators, and related threats, then provide guided responses grouped into triage, containment, investigation, and remediation.
  • Copilot can also summarize identities and devices, analyze suspicious scripts and files, generate advanced hunting queries from natural language, and create an incident report from the recorded investigation activity.
  • Agentic capabilities such as Security Alert Triage apply autonomous reasoning to supported alerts and return verdicts with an evidence trail. An agent operates within its configured identity, permissions, triggers, and scope; it does not replace analyst judgment.
  • Access requires provisioned Security Copilot capacity and appropriate Defender permissions. Apply least privilege to both users and agents and treat preview capabilities as subject to change.
  • AI output can be incomplete or incorrect. Verify important claims against source records, investigate conflicting evidence, and require human approval before consequential containment or remediation actions.

Exam checklist

  • Distinguish embedded Copilot assistance from autonomous agentic workflows and identify when each supports an investigation.
  • Use incident summaries, guided responses, entity or artifact analysis, and generated queries as investigation accelerators rather than final determinations.
  • Validate AI-generated timelines, verdicts, indicators, and recommendations against alerts, evidence, entity pages, and advanced hunting results.
  • Account for provisioning, RBAC, data scope, preview status, and human oversight before enabling or acting on AI capabilities.

Hands-on exercise

Validate an AI-assisted incident investigation

  1. Open a multi-alert incident in the Defender portal and record your own initial assessment of its timeline, affected assets, and likely attack path.
  2. Review the embedded Copilot summary and guided responses, then trace every material claim to an alert, entity, event, or other source record.
  3. Use one supported analysis capability or generated hunting query to investigate an identity, device, file, or script and document any unsupported or conflicting conclusion.
  4. Choose which recommended actions to accept, modify, or reject, explain the human-approval boundary, and produce a short evidence-backed incident handoff.

Official Microsoft resources

Microsoft Security Copilot in Microsoft Defender ↗Microsoft Copilot in Defender application card ↗Security Alert Triage Agent in Microsoft Defender ↗

Related learning-path notes

Investigate complex attacks, including multi-stage, multi-domain, and lateral movement.

Study notes & practiceBrief · concepts · checklist · exercise

Study brief

A complex attack spans multiple stages, security domains, or entities and often produces alerts that appear unrelated in isolation. Defender XDR correlates these signals into an incident, while the attack story, entity pivots, advanced hunting, and blast radius analysis help analysts reconstruct chronology, identify lateral movement, and determine current and potential impact.

Key concepts

  • Start with the incident priority, correlated alerts, affected assets, and attack story. Establish the entry point, sequence of techniques, compromised entities, persistence, lateral movement, and observed response actions.
  • Pivot across users, devices, mailboxes, applications, IP addresses, files, URLs, and cloud resources. Use entity pages and Go hunt to test relationships, find activity outside the original incident, and link relevant results back to the investigation.
  • The incident graph visualizes observed evidence over time. Blast radius analysis adds possible propagation paths from a selected node to critical targets so analysts can prioritize containment by business impact.
  • Graph paths are investigative leads, not proof of attacker activity. Results depend on permissions, data freshness, modeled attack vectors, and bounded path length, so corroborate paths with event evidence and hunting queries.
  • Contain the attack without losing the evidence needed to determine root cause. Sequence actions across domains, verify their results, and reassess scope when new alerts or entities appear.

Exam checklist

  • Reconstruct a multi-stage attack by correlating alert times, tactics, entities, and security domains into one evidence-backed narrative.
  • Use the incident graph, entity pages, timelines, Go hunt, and advanced hunting to investigate lateral movement and activity beyond the original alerts.
  • Differentiate observed attack-story relationships from possible blast-radius paths and explain the limitations of graph-based analysis.
  • Prioritize containment and remediation by compromise confidence, attack stage, critical-asset exposure, and the risk of continued propagation.

Hands-on exercise

Reconstruct and contain a multi-domain attack

  1. Choose a simulated incident with alerts from at least two domains and build a timeline containing the entry point, affected entities, tactics, and observed response actions.
  2. Traverse the incident graph and entity pages, then use Go hunt or advanced hunting to test one suspected lateral-movement relationship and add relevant evidence to the incident.
  3. Review blast radius from a compromised node, separate observed compromise from possible paths, and identify the highest-impact reachable asset or choke point.
  4. Write a sequenced containment and remediation plan, verify the expected result of each action, and list the evidence required before closing the incident.

Official Microsoft resources

Investigate incidents in the Microsoft Defender portal ↗Investigate and respond using Microsoft Defender XDR ↗Link advanced hunting results to an incident ↗

Related learning-path notes

Manage security incidents by using case management.

Study notes & practiceBrief · concepts · checklist · exercise

Study brief

Native case management in the Microsoft Defender portal tracks security work that can span multiple incidents, hunting findings, indicators, and teams. A case provides its own priority, workflow status, owner, due date, tasks, comments, attachments, linked objects, and audit history while preserving each linked incident as a separate investigation record.

Key concepts

  • A Defender incident correlates alerts and evidence for an attack; a case coordinates broader SecOps work. Use a case when work spans incidents, requires escalation or collaboration, tracks a hunt or threat actor, or needs a durable operational workflow.
  • Case management requires a Microsoft Sentinel workspace connected to the Defender portal. Cases are managed in the Defender portal and are not visible in the Azure portal.
  • The case queue supports filtering, sorting, and search. Case details include priority, customizable status, assignee, description, due date, linked incidents, tasks with individual owners and deadlines, comments, attachments, and an activity log with audit events.
  • Linking an incident to a case adds coordination context without merging or replacing the incident. Multiple incidents can be linked when an investigation, campaign, or escalation crosses their boundaries.
  • Access can be granted through Defender XDR unified RBAC or Sentinel roles: Reader supports viewing, Responder supports creating and managing cases, and Contributor supports status customization under the documented permission mapping.

Exam checklist

  • Choose correctly between managing an incident and creating a case for cross-incident or cross-team security work.
  • Create and maintain case priority, status, assignment, due date, tasks, comments, attachments, linked objects, and audit history.
  • Link or unlink incidents while preserving the distinct purpose and lifecycle of the case and each incident.
  • Recognize the connected-workspace requirement and map view, manage, and customize capabilities to the appropriate RBAC permissions or Sentinel roles.

Hands-on exercise

Coordinate a cross-incident SecOps case

  1. In a Defender portal connected to a Sentinel workspace, create a case for a simulated campaign that involves two related incidents and define its priority, owner, status, description, and due date.
  2. Link both incidents, add one investigation task and one containment task with separate owners and deadlines, and record the relationship between the incidents in a comment.
  3. Attach or reference a non-sensitive evidence artifact, update a task and the case status, and review the activity log to confirm the changes are auditable.
  4. Close the case with a concise outcome and explain why the linked incidents retained their own evidence, classifications, and lifecycles.

Official Microsoft resources

Manage security operations cases in the Defender portal ↗Manage incidents in Microsoft Defender ↗Streamline incident response using tasks ↗

Related learning-path notes

Respond to alerts and incidents in Microsoft Defender for Endpoint4 objectives

Investigate device timelines.

Related learning-path notes

Perform device actions, including live response and collecting investigation packages.

Related learning-path notes

Perform evidence and entity investigation.

Related learning-path notes

Investigate and remediate incidents identified by automatic attack disruption.

Related learning-path notes

Investigate Microsoft 365 activities to identify threats3 objectives

Investigate threats by using Microsoft Purview Audit.

Related learning-path notes

Investigate threats by using Content Search in Microsoft Purview eDiscovery.

Related learning-path notes

Investigate threats by using Microsoft Graph activity logs.

Study notes & practiceBrief · concepts · checklist · exercise

Study brief

Microsoft Graph activity logs record HTTP requests made to Microsoft Graph for resources in the tenant. In Sentinel, the MicrosoftGraphActivityLogs table can expose unusual application, service-principal, and user access patterns that conventional sign-in logs do not fully explain.

Key concepts

  • The Microsoft Entra ID connector can ingest Microsoft Graph activity logs into Microsoft Sentinel.
  • Useful investigation fields include AppId, ServicePrincipalId, UserId, RequestUri, RequestMethod, ResponseStatusCode, IPAddress, UserAgent, and RequestId.
  • Investigations should establish who or what called Graph, which endpoint was accessed, whether the request succeeded, where it originated, and whether the volume or timing is anomalous.
  • Correlate Graph requests with sign-in, audit, identity-risk, and Defender XDR evidence; a Graph request alone does not prove malicious activity.

Exam checklist

  • Know the purpose of MicrosoftGraphActivityLogs and how the data reaches Sentinel.
  • Pivot between an AppId, service principal, user, IP address, request URI, and response code.
  • Identify suspicious patterns such as enumeration, repeated authorization failures, unusual endpoints, or a new caller accessing sensitive resources.
  • Use RequestId and time windows to correlate activity with other Entra and Microsoft 365 telemetry.

Hands-on exercise

Investigate an unusual Microsoft Graph caller

  1. Confirm that Microsoft Graph activity logs are enabled through the Microsoft Entra ID data connector.
  2. Summarize requests by AppId, ServicePrincipalId, UserId, RequestUri, and ResponseStatusCode for a defined time window.
  3. Select an unusual caller and build a timeline of endpoints, source IP addresses, user agents, failures, and successful requests.
  4. Correlate the caller with Entra sign-in and audit data, then document whether the activity is expected, suspicious, or malicious.

Official Microsoft resources

Send Microsoft Entra ID data to Sentinel ↗MicrosoftGraphActivityLogs table reference ↗MicrosoftGraphActivityLogs query examples ↗
03

Perform threat hunting

KQL, Advanced Hunting, graphs, Data Lake, summary tables, and notebooks

20–25% · 10 objectives
Detect threats by using Microsoft Defender XDR6 objectives

Identify the appropriate table to use in a KQL query.

Related learning-path notes

Identify threats by using Kusto Query Language.

Related learning-path notes

Create Advanced Hunting queries.

Related learning-path notes

Interpret threat analytics in Microsoft Defender XDR.

Related learning-path notes

Create hunting graphs, including blast radius.

Study notes & practiceBrief · concepts · checklist · exercise

Study brief

The hunting graph in Microsoft Defender advanced hunting renders security entities and their relationships as an interactive graph. Analysts create a graph by choosing a predefined threat scenario, supplying its required entities, applying node or edge filters, and then exploring possible paths, choke points, exposure, and connections to critical assets.

Key concepts

  • Open a new hunting graph from Investigation & response > Hunting > Advanced hunting. Access requires the appropriate Microsoft Entra role, onboarding to the Microsoft Sentinel data lake, and at least read-only access in Microsoft Security Exposure Management.
  • Predefined scenarios use prebuilt advanced hunting queries for questions such as attack paths to a critical asset, an entity relationship map, paths between two entities, access to sensitive resources, or choke points to data stores. Supply the scenario's required source or target entities before rendering it.
  • Nodes represent entities such as users, devices, IP addresses, applications, or cloud resources. Directed edges describe relationships such as membership, permissions, authentication, network routes, ownership, or execution; selecting an element reveals its properties and context.
  • Refine a scenario with source-node, target-node, edge-type, edge-direction, risk, vulnerability, exposure, or shortest-path filters. After rendering, inspect nodes and edges, expand connected assets, focus on relevant entities, and use layers to control the visualization.
  • Use hunting graphs proactively to explore possible routes and choke points. Incident blast radius starts from an incident entity to estimate current and potential reach toward critical targets; it complements the observed attack story but does not prove that every displayed path was used.
  • Graph results depend on available workload data, critical-asset classification, data freshness, modeled relationships, permissions, and path limits. Corroborate important relationships with entity records, alerts, timelines, and advanced hunting event data before containment or remediation.

Exam checklist

  • Create a new hunting graph, choose the scenario that matches the hypothesis, provide required entity inputs, apply relevant filters, and render the graph.
  • Interpret node types, edge direction and relationship, grouped entities, shortest paths, critical-asset markers, vulnerabilities, and possible choke points.
  • Differentiate proactive hunting graphs, incident attack stories, incident blast radius, and custom Sentinel Graph analysis with GQL.
  • Validate graph-derived paths against underlying security evidence and account for prerequisites, RBAC scope, incomplete data, modeled-vector, freshness, and path-length limitations.

Hands-on exercise

Create and validate a hunting graph to a critical asset

  1. Define a hypothesis involving a potentially compromised identity or device and a critical target, then record the required permissions, source entity, target entity, and evidence that would confirm the path.
  2. In Advanced hunting, create a hunting graph and run either Paths between two entities or Attack paths to critical asset with the appropriate inputs.
  3. Filter to the shortest relevant paths and required edge direction or relationship types, then inspect each node and edge to identify exposure, vulnerabilities, and a possible choke point.
  4. Use entity pages or an advanced hunting query to corroborate the important relationships, separate possible reach from observed attacker activity, and document one justified containment or hardening action.

Official Microsoft resources

Hunt for threats using the hunting graph ↗Understand graph icons and visualizations ↗Investigate incidents and blast radius ↗Work with advanced hunting query results ↗

Related learning-path notes

Analyze relationships between entities by using Sentinel Graph.

Study notes & practiceBrief · concepts · checklist · exercise

Study brief

Microsoft Sentinel graph models security data as nodes and directed relationships instead of isolated rows. Analysts use graph experiences and Graph Query Language (GQL) to trace access paths, lateral movement, blast radius, and connections to critical assets.

Key concepts

  • Nodes represent entities such as identities, devices, files, and cloud resources; edges represent relationships such as access, membership, ownership, or activity.
  • Predefined graphs support scenarios such as identity attack paths, hunting, exposure, and blast-radius analysis.
  • Custom graphs can model Sentinel data lake and non-Microsoft data for organization-specific investigations.
  • Graph visualization supports schema inspection, node details, connected-asset traversal, filtering, table validation, and export.

Exam checklist

  • Explain why graph analysis reveals relationships that are difficult to find in tabular queries.
  • Identify nodes, edges, direction, properties, paths, and blast radius in an investigation.
  • Use the schema before writing GQL and validate visual results in the table view.
  • Distinguish proactive attack-path analysis from post-compromise blast-radius investigation.

Hands-on exercise

Trace an identity path to a critical asset

  1. Open Microsoft Sentinel > Graphs and choose an available predefined or custom graph.
  2. Inspect the schema to identify the relevant identity, resource, and relationship types.
  3. Start with a predefined query or a one-hop GQL pattern, then filter to a selected identity or critical asset.
  4. Traverse connected assets, validate the path in table view, and record the shortest risky path and a remediation action.

Official Microsoft resources

Microsoft Sentinel graph overview ↗Identity attack graph ↗Visualize graphs in Microsoft Sentinel ↗
Detect threats by using the Microsoft Sentinel platform4 objectives

Create and monitor hunting queries.

Related learning-path notes

Create and manage KQL jobs in Data Lake.

Study notes & practiceBrief · concepts · checklist · exercise

Study brief

KQL jobs are one-time or scheduled asynchronous queries that run against Microsoft Sentinel data lake data and federated tables. They support long-running investigations, cross-table joins and unions, historical analysis, enrichment, and selective promotion of results to another tier.

Key concepts

  • The workspace must be onboarded to the Sentinel data lake before KQL jobs can run.
  • A job defines a query, source workspaces, destination workspace and table, and either a one-time or recurring schedule.
  • Results can be written to a new table or appended to a schema-compatible existing table in the analytics or data lake tier.
  • Account for data lake ingestion latency, query timeout, destination cost, schema compatibility, and unsupported fields or operators.

Exam checklist

  • Choose a KQL job for historical, multi-table, join/union, scheduled, or enrichment workloads.
  • Know the prerequisites: data lake onboarding, required roles, and managed-identity access when creating analytics custom tables.
  • Configure the destination, query scope, schedule, and delay or overlapping lookback needed for late-arriving data.
  • Differentiate KQL jobs from summary rules and search jobs by source tier, query capability, scheduling, and result destination.

Hands-on exercise

Design a scheduled historical enrichment job

  1. Choose a historical investigation that needs a join or union across two Sentinel tables.
  2. Write and test a query that projects only required columns and preserves the original event time in a separate field.
  3. Create a scheduled KQL job with a destination table and a delay that accounts for data readiness.
  4. Review job status and output, verify the destination schema, and document how promoted results support hunting or analytics.

Official Microsoft resources

Create KQL jobs in the Sentinel data lake ↗Compare KQL jobs, summary rules, and search jobs ↗

Create and manage summary rule tables for querying.

Study notes & practiceBrief · concepts · checklist · exercise

Study brief

Summary rules run scheduled KQL aggregations in the background and store compact results in custom Analytics-tier tables. They improve performance and control cost when analysts repeatedly query high-volume or lower-cost source data.

Key concepts

  • A summary rule consists of a KQL aggregation, destination custom table, bin size or execution frequency, delay, and start time.
  • Results use an existing or new custom table, normally with the _CL suffix, and can feed hunting, workbooks, reports, or analytics rules.
  • Test the query and expected schema before creating the rule; reduce bin size, returned rows, or high-volume fields if limits are approached.
  • Monitor rule health and run history. Enable SummaryLogs diagnostics to investigate historical executions and failures.

Exam checklist

  • Choose summary rules for frequent aggregation of high-volume data and fast repeated analysis.
  • Configure the query, destination table, frequency, delay, and start time.
  • Explain how summarized Analytics-tier data can reduce repeated scans of verbose Basic, Auxiliary, or Data Lake data.
  • Manage a rule by viewing results and run history, then enabling, disabling, editing, or deleting it.

Hands-on exercise

Create and validate a summary rule

  1. Select a verbose source table and define an hourly security metric that analysts repeatedly need.
  2. Test a KQL summarize query in Logs and verify its output schema and time binning.
  3. Create a summary rule that writes to a new custom table and configure frequency and ingestion delay.
  4. Query the destination table, inspect run history or SummaryLogs, and describe one hunting or analytics use for the summarized data.

Official Microsoft resources

Aggregate Sentinel data with summary rules ↗Compare KQL jobs, summary rules, and search jobs ↗

Hunt for threats by using notebooks, including connection to the Sentinel MCP Server.

Study notes & practiceBrief · concepts · checklist · exercise

Study brief

Microsoft Sentinel supports both code-first and natural-language hunting workflows. Jupyter notebooks provide a reproducible environment for multi-step data acquisition, enrichment, visualization, statistics, and machine learning, while the hosted Sentinel MCP server exposes scenario-focused security tools to compatible AI clients through Microsoft Entra-authenticated connections.

Key concepts

  • Choose a notebook when the hunt requires custom Python, repeatable transformations, external enrichment, complex visualization, statistical analysis, machine learning, or a durable record that combines code, results, and analyst reasoning.
  • MSTICPy adds security-focused query providers, predefined queries, entity enrichment, threat intelligence and geolocation lookups, timelines, process trees, and other analysis tools. Protect provider secrets in Azure Key Vault, review imported code, and stop Azure Machine Learning compute when it is not in use.
  • The Sentinel MCP server is a fully hosted interface that uses Microsoft Entra identity and does not require the analyst to deploy MCP infrastructure. A compatible MCP host and client connect to scenario-focused collections for data exploration, triage, threat hunting, or agent creation.
  • MCP tools operate within the signed-in identity's permissions and data scope. Select the intended Sentinel workspace, use least privilege, keep the client compatible with current MCP authorization, and never assume that natural-language access bypasses table, product, or RBAC requirements.
  • Treat notebook output and model-generated MCP responses as evidence candidates. Validate tables, time ranges, query logic, entities, citations, and data freshness; preserve the final queries and findings in the investigation record before taking consequential action.
  • MCP capabilities, limits, client support, and preview status can change. Use English prompts for the currently documented language support, test workflows in a controlled environment, and consult current availability and billing guidance before production adoption.

Exam checklist

  • Select notebooks for programmable, multi-step, reproducible analysis and MCP tools for governed natural-language access from a compatible client.
  • Configure a notebook environment, authenticate to Sentinel, query data with Kqlmagic or MSTICPy, enrich and visualize results, protect secrets, and manage compute cost.
  • Explain the MCP host-client-server relationship, choose an appropriate Sentinel tool collection, authenticate with Microsoft Entra, and specify the correct workspace and investigation scope.
  • Validate notebook and MCP results against source data, account for permissions, freshness, service limits, and preview behavior, and retain reproducible evidence for analyst review.

Hands-on exercise

Run and validate a hybrid notebook and MCP hunt

  1. Define a time-bounded identity or endpoint hunting hypothesis and record the target workspace, required tables, entities, permissions, and expected evidence before querying data.
  2. In a Sentinel notebook, retrieve the relevant events with Kqlmagic or MSTICPy, normalize them in a data frame, enrich one entity, and create a timeline or other visualization that tests the hypothesis.
  3. From a compatible client connected to the appropriate Sentinel MCP collection, submit a specific English prompt for the same scope and record which tools, workspace, tables, and time range produced the response.
  4. Compare both result sets, investigate discrepancies against the underlying records, save the final query and notebook narrative, remove secrets or sensitive output, and document an evidence-backed conclusion.

Official Microsoft resources

Jupyter notebooks with Sentinel hunting capabilities ↗Get started with Jupyter notebooks and MSTICPy ↗Microsoft Sentinel support for MCP ↗Get started with Microsoft Sentinel MCP server ↗Sentinel MCP tool collections ↗Sentinel MCP best practices and troubleshooting ↗

Related learning-path notes

↑