0.1 What This Course Engineers

Introduction

An incident in a Microsoft estate rarely stays in one product.

A phishing message reaches a mailbox, captures a session, reads files in SharePoint and adds a rule to the mailbox; an implant on a laptop dumps credentials and moves to a second machine. Each step is recorded by a different service, and the investigation works only if every one of those services was deployed, connected and configured so that its evidence arrives in one place, intact.

This course is about building that: the Microsoft security platform engineered so that cross-service investigation works. This lesson covers what the course is for, the services and what each contributes, which service raised what on the SecOps Range, how they join, how each lesson runs, where the course stops, what each module builds, and how to work through it.

Most Microsoft security training teaches one product per module and leaves each one configured on its own. That works until an incident crosses products, which most do, and then the gaps between the products are where the investigation fails: a device that was never onboarded, a mailbox whose audit was never checked, a workspace with no connector for the alerts that mattered.

SEC301 teaches the services together, from the engineering side:

The goal is concrete. By the end you can deploy, connect and configure the services so that an incident spanning identities, devices, mail, cloud workloads and data reaches the Defender portal as one incident with its evidence intact; prove that each service is feeding; and use what you built to investigate, contain and recover, with each step verified and written down.

The course is written for analysts in their first one to three years on a Microsoft estate, and for IT and cloud administrators moving into security operations. No prior security operations experience is assumed: every service, table and setting is explained the first time it appears.

If you already run a SOC, the course will still show you where your own platform's gaps are, because every lesson ends with a build you can run against your tenant.

The course is also deliberately not several things. It does not design a detection library or an automation program; that is SEC302. It does not design tenant architecture, go below scoping into forensics, or prepare you for a vendor certification. Each of those has a home elsewhere in the catalog.

The way to read it is as a build. Each module adds a part of the platform, proves it works, and leaves you with that part built in your own tenant. By Module 12 the parts are all in place and the course runs one incident through them end to end.

Read SEC301 as the build of one platform, module by module, with every part proved on the range and built in your own tenant.

The platform is made of six services, and each contributes something the others cannot:

Microsoft Defender XDR is the center. Its components, Defender for Endpoint, Defender for Identity, Defender for Office 365 and Defender for Cloud Apps, each watch one surface, and Defender XDR correlates their alerts into incidents in the Defender portal. Microsoft's own evaluation guide lists those four components and recommends deploying them in that order, starting with Defender for Identity, because of how much effort each typically takes.

Entra ID records every sign-in and every directory change, and ID Protection turns sign-in patterns into risk. Microsoft treats ID Protection as separate from Defender, and it needs Entra ID P2. Defender for Cloud watches Azure workloads: the posture of subscriptions and resources, and the alerts from its plans. Purview records what happened to data: the unified audit log, sensitivity labels, data loss prevention and insider risk.

Microsoft Sentinel is the workspace. It holds the logs the other services produce, the ones the Defender portal does not keep and the ones that come from outside Microsoft, and it runs rules and automation over them. In a tenant that onboards Sentinel to the Defender portal, the incidents and the hunting experience are shared.

Security Copilot sits over the same data as an assistant. It reads what the analyst can read and writes about it quickly, which is why the course treats it like any other source: every claim it makes is checked against a record.

None of these is useful on its own for long. An identity alert without the mailbox audit cannot say what the session did; an endpoint alert without the sign-in log cannot say how the attacker got the credential. The engineering in this course is mostly about the joins.

Learn the six services by what each contributes to one incident, and judge each configuration by whether its evidence arrives where the others can use it.

The SecOps Range is the course's practice environment: a month of records from one organization's tenant, with the five investigations the course works on inside it. Every alert on the range, by the product that raised it:

SecurityAlert
| summarize Alerts = count(), FirstSeen = min(TimeGenerated),
    LastSeen = max(TimeGenerated) by ProductName
| order by Alerts desc

733 alerts from 9 products. Defender for Cloud Apps raised the most, 432, because it watches cloud app activity, where most of a month's anomalies live. ID Protection raised 151, Defender for Office 365 77, and Defender for Identity 50. Defender for Endpoint raised 10. Sentinel's own analytics rules, Defender XDR's correlation, Defender for Cloud and Insider Risk Management raised the rest.

The product names in the result are not the ones on Microsoft's current pages. The alert table keeps the names the products had when the table was designed:

That mapping is the first thing to learn about the tables, and the first source of empty results for newcomers. A query filtered on "Microsoft Defender for Cloud Apps" returns nothing, because the table says "Microsoft Cloud App Security". The course uses the current product names in prose and the table's values in queries, and says so where they differ.

The distribution is also a statement about coverage. The range's organization has Defender for Endpoint on its devices, and it raised the fewest alerts of the Defender components. That is not a sign the endpoint estate is quiet; it is a reason to ask which devices are onboarded and what the protection is set to block or only report.

Every number in this course comes from a query like this one, run on the range as you read. Change it, rerun it, and the number in the prose is the one you get.

Read alert counts by product as a picture of what each service is set up to see, and filter on the product names the table actually holds.

The platform's purpose is the incident that spans services. Every incident on the range, by how many products contributed alerts to it:

SecurityIncident
| summarize arg_max(TimeGenerated, AlertIds) by IncidentNumber
| mv-expand Id = todynamic(AlertIds)
| extend SystemAlertId = tostring(Id)
| join kind=inner (SecurityAlert | project SystemAlertId, ProductName)
    on SystemAlertId
| summarize Products = make_set(ProductName) by IncidentNumber
| extend Services = array_length(Products)
| summarize Incidents = count(), Examples = make_set(IncidentNumber, 5)
    by Services
| order by Services asc

548 incidents. 544 came from a single product. Only 4 span more than one, and they are exactly the four incidents the course is built around: 100031, 100032, 100033, 100034. Incident 100031, the phishing compromise, draws on four products; the others on two each.

That ratio is normal. Most alerts describe one thing on one surface, and most incidents are single-product. The few that cross services are the ones that matter most, because they are the ones where an attacker moved, and they are the ones a platform configured product by product fails on.

Correlation joins alerts into one incident through the entities they share: the same user, the same device, the same mailbox, the same address, close together in time. It works only if each product extracted those entities, named them the same way, and sent its alerts to the same place.

A device that Defender for Endpoint knows by one name and Defender for Identity by another, a user the mail alert names by address and the sign-in alert by object ID, an alert that reached Sentinel and never reached the Defender portal: each of those breaks a join, and the incident arrives in pieces.

The fifth investigation shows the other failure. Its alert, from Insider Risk Management, sits on the range with no incident at all. An alert outside an incident is still evidence, but nobody working the queue sees it in context, and the platform's job is to make sure the alerts that belong together arrive together.

Much of the configuration in the protection and platform modules is about these joins: onboarding so the entities exist, connectors so the alerts arrive, entity mapping so they can be correlated.

Judge the platform by its multi-service incidents, and treat an alert that should have joined one and did not as a configuration defect.

Every lesson in Modules 1 to 12 has the same shape:

A lesson starts with a service setting: what it is, where it lives in the portal, what it decides, and the PowerShell that sets it where there is one. The portal comes first because it shows the setting in context, with the options beside it; PowerShell comes beside it because it is how the setting is recorded, repeated and checked.

The proof follows. At most two queries per lesson run on the SecOps Range and show the configuration working, or show what happens when it is missing: the sign-ins a Conditional Access policy would have stopped, the alerts a connector delivers, the footholds an eviction left. The query is there to prove the setting; KQL as a subject has a module of its own.

Each lesson then ends with a build: the same configuration in your own tenant, written as a build card with the role, license, cost and changes it needs, the steps, the checks that prove it worked, the evidence to keep, how to undo it, and a route for a student without a tenant.

Then an audit: another team's configuration, with real defects to find, and decoys, lines that look wrong and are right.

The last lesson of each module is an exercise. It takes the module's whole subject through one case on the range, and its practice is a second case for you to work yourself.

This module is the exception. Its five lessons orient you, set up your console and your tenant, set the rules for changing a tenant safely, and map the five investigations. It has builds and no audits.

The audits are worth more than they look. Reading a configuration someone else wrote, with no context, is what an analyst does on the first day in a new job, and the decoys train the judgment that stops you changing a setting that was right.

Work each lesson in its order: read the setting, run the proof, do the build in your tenant, then audit someone else's.

SEC301 engineers the platform. The courses beyond it build on that platform:

The boundary with SEC302 is the one that matters most, because the two courses use the same products. In SEC301 you configure Sentinel, write and tune a rule, and check what an automation did; in SEC302 you design a library of rules, an automation program and the metrics that show the SOC is working.

In SEC301 you use Security Copilot inside an investigation and check its answers; SEC302 treats AI agents as part of the operation's design.

The other courses go deeper into one part. SEC201 teaches KQL from basics to mastery, and SEC402 teaches hunting as a discipline. SEC401 builds detection engineering. FOR301 teaches triage, and FOR401 cloud incident response. ARC501 designs the tenant's security architecture, which SEC301 deliberately does not: this course configures what is there and proves it works, and leaves the question of how a tenant should be designed to the architecture course.

None of those is needed to finish SEC301. Each lesson teaches what its own student needs, and points elsewhere only for further reading. Where a topic is out of scope, the lesson says so in a line and moves on, rather than teaching half of it.

There are also things no course here teaches. Forensics below the level of scoping, offensive technique beyond what an investigation needs to recognize, and vendor certification preparation are all outside SEC301. The certifications in particular map loosely onto this material, and the course makes no claim to prepare you for one.

Knowing the boundary also helps when you are asked to do work on the far side of it. A request to design the SOC's rule library is SEC302 work, and doing it with only SEC301 behind you is possible, with the gaps that implies.

Use SEC301 to build the platform and investigate on it, and take the operation's design to SEC302 and depth on any one part to the course that owns it.

Each module builds one part of the platform, and they come in an order:

Modules 1 and 2 are the foundations. Module 1 establishes which service sees what, who may act, and how long evidence lasts, which is the coverage map every later module fills in. Module 2 works the Defender incident: the queue, the incident page, the timeline, the response actions, and a defensible classification.

Modules 3 to 7 configure protection, one surface each: endpoint, identity, mail and collaboration, cloud workloads and applications, and data. Each one configures the service, audits it, proves it on the range, and ends by containing something on that surface: a device, an account, a workload or application, a data loss.

Modules 8 to 10 build the platform layer. Module 8 configures Sentinel: the workspace, connectors, collection, tiers, retention, ingestion health, UEBA and threat intelligence. Module 9 is KQL for investigators: timelines and scope across services. Module 10 builds and tunes detections and checks what automation actually did.

Module 11 is Security Copilot, used inside an investigation and checked against the evidence. Module 12 is coordinated response: one incident taken from scope to a closed report, using everything the earlier modules built.

The order matters because each module's proof relies on the ones before. Module 9's cross-service timeline needs the tables Modules 3 to 8 configured; Module 12's response needs the containment actions Modules 3 to 7 taught.

Skipping ahead works for reading, and less well for the builds. A student who arrives for one module can still do its build, provided the earlier parts it depends on already exist in their tenant.

The protection modules have one more thing in common: each ends with a containment, because a service is configured for the response actions it must offer as well as the evidence it records.

Work the modules in order, because each module's proof and build rest on the parts the earlier modules put in place.

The course is a build, so the most useful thing to keep is a record of what you built. Each lesson's build card names the evidence to keep: a configuration export, a query result, a screenshot of a setting, a dated note.

Kept together, they become the record of your platform and the material for the course exam, which asks for an evidence-backed timeline, a scope, a response plan, verification results and a report on one incident across several services:

A single folder, organized by module, is enough. The point is that each item carries its date and its source, so that a later reader, or you in three months, can tell what was true when.

A lesson is meant to be read in one sitting with its queries run, and its build done afterward in your tenant, when you have the role and the time. The exercises take longer than a lesson, because they work a whole case.

Read with the console open. Every query block on the page runs against the range, and the fastest way to understand a result is to change the query and see what moves: widen the window, remove a filter, add a column. The reset button restores the original.

Keep the course's two rules in mind from the start. Every number in a lesson comes from a query you can run, so a number you doubt is one you can check. And every product and licensing statement carries the date it was checked, because Microsoft changes its products often; where a date is old, check the current page before relying on it.

The first practical step is the build below: a one-page map of your own platform. It takes an hour, changes nothing, and gives every later module a starting point to measure against.

The build maps the services in your own organization or lab against the parts this course builds.

SEC301 is the build of one Microsoft security platform, engineered so that an incident spanning identities, devices, mail, cloud workloads and data arrives as one incident with its evidence intact. Six services contribute: Defender XDR, Entra ID, Defender for Cloud, Purview, Sentinel and Security Copilot.

On the SecOps Range only 4 of 548 incidents span more than one service, and those are the ones the course is built around. Every lesson configures a service, proves it on the range, builds it in your tenant and audits another team's configuration. If you do one thing this week, draw the map of your own platform: which services are licensed, deployed and feeding.

Resources

Microsoft revises these pages; where a page and this lesson disagree, the page is newer.

• Microsoft Learn: Evaluate and pilot Microsoft Defender XDR (checked 8 November 2026)