Using the M365 Incident Response Course: Practice Cards and Study Routes

Introduction

Per IR0.1 every section of this course teaches a subject, demonstrates the action and then asks you to carry it out. This section is about the third part, because it is the one that decides whether you finish the course knowing the material or knowing your own environment.

It also covers how to move through a course that is navigable rather than linear, what to do if you have arrived for one specific subject, and what to do with the findings the practice cards produce.

Per IR0.1 the course is longer to work through than to read, and this is where the difference lives.

Each section closes with a card that asks you to do something in a real tenant. They are short, they are specific, and they are the part most readers skip.

Per IR0.1 the third beat is the one people skip, and this section exists because skipping it is the single biggest difference between two readers of the same material.

A card is not a comprehension check and it is not an exercise with a right answer. It is a question about your environment that only you can answer, and the course cannot tell you what the answer should be.

The reason to run them is that they produce findings rather than understanding. Reading that an audit search needs a particular role tells you a fact. Running the search from your on-call account tells you whether your organization has a problem, which is a different kind of knowledge and the one somebody will eventually ask you for.

The difference is in what you hold at the end.

They are also written to be run once rather than repeatedly. A card that establishes your retention horizon does not need re-running weekly; it needs running once, writing down, and revisiting when licensing or export configuration changes.

The cards are deliberately small. None of them is a project, most are one query or one portal blade, and the reason they are small is that a card somebody skips because it looks like work has failed at the only thing it was for.

Every card ends with a line saying what you should end up with. Treat that as the actual deliverable: if you have run the card and cannot produce the thing it names, the card is not finished.

That phrasing is chosen rather than incidental. A card that said understand how retention works would be satisfied by reading; a card that says write down the earliest date this tenant can answer a question about user activity is either done or not.

A few cards also build on each other directly. The retention horizon from module one is the input to the export decision in module two and to the scoping work in module four, so a card left undone reappears later as a question you cannot answer.

Two habits decide how much of this course survives contact with your own environment, and both are cheap.

Keep the outputs. Several of them are inputs to later modules, and the whole set is the closest thing you will have to a written statement of what your organization can and cannot do during an incident.

Section one is about what to do in each section. This one is about the order you take them in.

A course this size is usually read from the front, and this one does not require it.

The platform's position on this is deliberate. A student may start a course wherever they wish, and sequential progress is encouraged as a recommendation rather than enforced as a gate.

You may start wherever you wish. Later modules build on earlier ones rather than repeating them, so working in order means you meet each idea once with its reasoning attached, and that is a recommendation rather than a gate.

Working in order has one specific advantage worth stating. Each module's findings feed the next, so a reader going front to back arrives at module four already knowing what their tenant retains, which is the question module four would otherwise have to send them back for.

If you have arrived for a specific subject, go to it. Somebody who came here because they need to collect evidence for a live case should be in module four this afternoon rather than reading module one first, and the material is written so that the cross-references tell you what you have skipped.

Starting mid-course has one cost worth accepting knowingly. You will meet references to things established earlier and have to decide each time whether to follow them, and the alternative is reading four modules before reaching the one you came for.

The cross-references are how the course stays navigable. A reference like IR1.5 in the middle of a later module is not decoration: it names the section that established the thing being relied on, so a reader who skipped it can go back for one specific idea rather than a module.

The table above is not a set of tracks. It is a starting point, and once you are in the material the cross-references will pull you sideways as often as forwards, which is the intended way to use a course about a subject where everything constrains everything else.

A reader who genuinely cannot spare the time for the whole module should still run its practice cards, because the findings are the part later modules assume rather than the prose.

Module one is the exception worth arguing for. It establishes what your tenant can and cannot answer, and most of the later modules assume you know that about your own environment rather than in general.

It is worth being specific about what that means, because self-contained is a claim people have heard before and mostly not received.

Per IR0.1 no minimum experience is assumed and every concept is explained at first use. That is a real commitment rather than a marketing line, and it has consequences in both directions.

Read the second row as the encouraging one. Somebody who has spent two years reading logs in any system has most of the transferable skill this course needs, whatever their job title says.

The reason for teaching them in place is that a query language taught in the abstract is a syntax lesson, and taught beside the question it answers it is a technique. You will write queries here because a section needed one, which is how you will write them afterwards.

Every portal path is given as a navigation route rather than a screenshot, because the portals change and the route survives longer than the picture does.

Query languages are taught where they are used rather than in a block up front. You will meet KQL in the sections that need it, with the query written out and explained, and the same for PowerShell. Neither is a prerequisite.

What does not help, and is worth naming because people assume it does, is a background in host forensics. Per IR0.1 most of that expertise is inapplicable here, and a reader arriving with it will spend the first module unlearning an instinct rather than building on one.

Administering a tenant helps in a particular way that is worth naming: you will already know where the portals are, which removes a layer of friction from every practice card and lets you spend the attention on what the results mean.

The thing that genuinely helps and cannot be supplied is having seen an organization under pressure. If you have not, the worked case at the end of each module is the closest substitute, and it is written to show the decisions rather than only the outcome.

Sections one to three are about how to read. This one is about where to point the queries, which is the question that stops most people from running the cards at all.

Almost every practice card asks you to run something against a real environment, and the question of which environment is worth settling early.

The split is straightforward and worth deciding once rather than card by card.

Your production tenant is the right answer for the read-only work, which is most of it. Establishing your retention horizon, listing your role assignments and counting your device code authentications are all queries that change nothing.

That distinction is worth making explicitly because the instinct is to treat all of it as risky. A retention query, a role listing and an audit search are the same class of action as opening a report, and an organization that will not permit them has a problem the course cannot solve.

Anything that changes state belongs in a lab. The lab setup module covers building one, including what it costs and what it cannot teach you, and per IR0.5 you do not need a production tenant to work through this course.

A lab is also the only honest place to practice the containment work in later modules. Revoking sessions and disabling accounts are correct actions with real consequences, and rehearsing them somewhere that matters is how a rehearsal becomes an incident.

If your organization will not permit even read-only queries, that is itself a finding worth recording, and per module ten it is the kind of constraint that shows up during an incident as a delay nobody planned for.

Where you have neither, the course still works and produces less. You will understand what a throttled mailbox looks like and not know whether yours throttles, and the practice cards say which of the two you are getting.

The cards produce output and the output has to go somewhere, which is a decision worth making before you have eleven findings in a text file with no dates on them.

By the end of module one you will have four or five written observations about your own organization. By the end of the course there are considerably more, and what happens to them is a separate decision from finishing the material.

That last observation is the one worth carrying into the conversation with whoever owns the budget. These are not gaps somebody neglected; they are questions nobody was assigned, and the difference matters when you present them.

That is a larger number than most people expect from a course, and it is a consequence of the third beat rather than of the material being unusually revealing.

Most of them are cheap to fix and were never anybody's job. An on-call account without an audit role, a diagnostic category nobody exported, a plan citing a withdrawn document: none of those is a project, and all of them survive because nobody was looking.

Sorting them once at the end is harder than sorting them as they arrive, because by then you will have forgotten which ones you could have fixed yourself.

The useful pattern is to separate them as you go.

Four buckets are enough, and sorting takes a moment per finding.

Findings arrive faster than you can act on them, so sort each one as it arrives rather than all of them at the end.

The third row is worth holding rather than raising immediately. Several of the cost arguments in this course arrive with evidence attached in a later module, and a request made before that evidence exists is a request that gets declined once and is harder to make twice.

The last of the four is the one people discard and the one that matters most. A limit you have written down is a limit you can state during an incident instead of discovering.

The exercises are the part most readers skip and the part the course is built around, so it is worth being direct about why. Per IR2.9 running one against your own tenant produces a fact about your organization, and reading about it produces a fact about tenants in general. The second is interesting and the first is the one that changes what you do on the day.

Thirty days is a suggestion rather than a schedule, and the parts of it that matter are the two exercises in the first week. Per IR2.1 establishing your retention position early changes how the rest of the course reads, because every later module asks what your tenant would have recorded and you will already know.

Per the course-level convention this appears once, here, rather than being repeated in every module.

Some readers want a route rather than a table of contents. This is one, and per section two it is a suggestion.

Four weeks, one module group per week, arranged so that each week produces something the next one uses.

Week one, know your position. Module one end to end, running every practice card. It is the module that produces the most findings per section and the one everything else assumes.

Week two, make the tenant investigable. Modules two and three: the readiness work that closes the gaps week one found, then detection and scoping.

Week three, the incident itself. Modules four, five and six: collecting evidence that will hold, reading it, and removing an attacker in a way that stays removed.

The middle two weeks are the densest. Modules four and five between them cover the collection and reading of evidence, which is where a real case spends most of its effort, and neither compresses well.

Week four, everything after. Modules seven through ten: the per-attack playbooks, hunting, the report and notification, and the capstone.

Each week ends somewhere useful rather than mid-subject, which is the reason for grouping the modules this way rather than splitting evenly.

The weeks are a sequence rather than a schedule. Per the course's own convention there are no time estimates anywhere in this material, because how long a module takes depends on how much of your environment you stop to check.

Keeping the outputs matters more than it sounds because several of them compound. The retention position from module two is what module eight's hunt window rests on, the documentation page is what module nine's report cites, and per IR10.1 the recovery windows belong on the same page. A reader who ran the exercises and kept nothing has to run them again.

Sequencing is worth one caution. The course is navigable rather than linear, and the two places that genuinely depend on earlier work are the hunt window in module eight, which rests on the retention position from module two, and the recovery ceiling in module ten, which rests on the same page. Everything else can be read in the order the work in front of you demands.

One more thing changes as you go, and it is the reason the course asks you to write things down rather than simply notice them.

This course is written for an individual and most of what it produces is organizational, which is worth planning for rather than discovering.

The scale changes what the same card is worth.

On your own, the practice cards produce a personal picture of the environment and a set of things you can fix without asking anybody.

Working alone is the default assumption of every card, so nothing below is required. It is what becomes available if you are not alone.

With a team, the same cards are a division of labor. Splitting them across a rota and comparing answers surfaces something a single reader cannot see, which is that different people get different results from the same query, per module one, because the account decides the answer.

That is worth knowing before you start, because it changes how you write things down. A note to yourself and a line somebody else will read are different artifacts, and rewriting eleven of the first kind into the second is work you can avoid by choosing once.

At an organizational level, the outputs are the raw material for the readiness work in module two. A retention horizon, a permission map, a list of what the tenant cannot answer and a plan with its gaps marked is most of an IR readiness assessment, assembled as a side effect of working through the course.

The team version has a second benefit that only appears in practice. Comparing answers from different accounts surfaces the permission problem in module one directly, because two people running an identical query and getting different results is the clearest possible demonstration of why the account decides the answer.

That progression is the reason the practice cards ask you to write things down rather than simply to look. A finding in your head does not survive to the conversation where it is needed.

None of the four steps below takes long, and together they are the difference between working the course and reading it.

The next section is the estate this course runs on: Northgate Engineering, its shape, and why the problems in this material bite at that size.