In this section

0.2 How This Course Is Structured

Module 0

Seven modules, forty-two teaching sections, and an order that is not arbitrary. Each module is a prerequisite for the next in a way that becomes obvious the first time somebody skips one. This section is the map, and it is worth five minutes before you start.

The seven, and why they sit where they do

Module 1, Deployment and Access Control. What the tool reaches and what it never will, the architecture behind a two-second answer, choosing a deployment model, standing up a server, users and roles, and enrolling clients. This is first because Section 0.1's condition is absolute: the agent has to have been there beforehand, so the deployment is the capability rather than a preliminary to it.

Module 2, Driving the Console. Finding a host, the virtual file system, retrieving and inspecting a file, collections, notebooks, and labels. The module where you learn the difference between a cached view and a live one, which is the single most common early misreading. It also introduces labels, which look like organizational tidiness in Module 2 and turn out by Module 5 to be the mechanism that decides what a fleet-wide action reaches.

Module 3, VQL for Investigators. The query language, from the shape of a statement through row sources, transformations, composition and debugging. It comes third because everything after it is expressed in queries, and because the one behavior in this language capable of doing real damage lives here.

Module 4, Collecting from One Endpoint. Order of volatility, choosing artifacts for a question, scoping, the offline collector, failure handling, and the custody record. One machine, done properly, before anything is multiplied. This is the module that most changes how somebody works day to day, because most investigations are one machine and the difference between a good collection and an adequate one is decided in the first ninety seconds.

Module 5, Hunts Across the Fleet. Almost nothing in the mechanism is new, which is deliberate: a hunt is the collection you already know how to build, addressed to many clients. What changes is the consequence of every decision you learned to make in Module 4.

Module 6, Fleet Analysis and Correlation. Turning a set of separate answers into one account: relating findings across machines, baselines, timelines that span hosts, clock skew, choosing the next question, and writing the result. It is the module with the least tooling and the most judgment, since the platform will happily produce six correct results and has nothing to say about whether they are one incident.

Module 7, Extending and Operating It. Writing your own artifacts, judging somebody else's, monitoring continuously rather than asking, containment, keeping the deployment healthy, and one case worked end to end. Each of those is dangerous or expensive without what precedes it, which is why it is last rather than because it is advanced.

Why the order is load-bearing

The temptation with a tool like this is to start with the interesting part, which is hunting, and pick up the rest as needed. Three things break if you do.

A hunt is a collection multiplied, so somebody who has not learned to scope a collection scopes a hunt badly and finds out at estate scale. A hunt result is read with queries, so somebody who cannot debug a query cannot tell a broken hunt from a clean estate. And containment is an action taken against a machine, which needs an account of what it is containing before it is a decision rather than a reflex.

The same logic runs at section level inside each module. Section 5.1 explains why a hunt never completes before Section 5.3 shows you how to launch one, because launching without that fact produces analysts who read a settled count as a finished hunt.

Where a section depends on something earlier, it says so by number rather than assuming you remember. That cross-referencing is deliberate and it is also a map: if a section keeps pointing back at one earlier idea, that idea is doing more work than its length suggests. Section 3.5's evaluation order and Section 4.1's volatility ordering are the two that recur most, and both are worth rereading before the fleet modules.

What a section looks like

Every teaching section has the same shape, and knowing it makes the course quicker to work through.

It opens with a scenario: a specific, plausible failure, usually somebody competent getting a confident wrong answer. That is the problem the section exists to prevent, and it is worth reading properly rather than skimming to the explanation. None of them are hypothetical in shape: each is a mistake that gets made because the tool makes it easy.

The body teaches the capability, with real queries, real artifact definitions and real output rather than illustrations. Where something is shown, it is something you can run.

A common confusion names the belief that produces the scenario, because most errors here are not ignorance but a reasonable assumption that happens to be wrong on this platform.

An anti-pattern describes the habit rather than the mistake, since the same error usually has a behavior behind it that will produce more of them.

A verification checkpoint gives you something to run on your own deployment, with what to expect and what it means if you see something else.

And an investigation principle closes it: one paragraph, the thing to carry. There is no boxed summary card, because the principle is the summary and a second one would be padding.

Each module then ends with a summary and a knowledge check of eight scenarios. The knowledge checks are harder than they look, deliberately: the wrong answers are the reasoning a competent practitioner offers, and several are correct in substance while being insufficient for the question asked.

That design is worth explaining rather than leaving as a difficulty. A knowledge check whose wrong answers are obviously wrong tests whether you read the section. One whose wrong answers are things a good analyst would say tests whether you can tell a real technique applied to the wrong problem from the right one, which is the actual failure mode in this work. Getting one wrong for the right reason is more useful than getting it right by elimination, and the explanations are written for that.

If you already do parts of this

The course is built to be worked in order and it does not assume you are starting from nothing.

If you already run a deployment, Module 1 is still worth an hour for the coverage argument and the roles model, which are the two parts most deployments get approximately right and the two that decide what your results mean.

If you already write queries, Module 3 will be quick until Section 3.5, which is the section experienced users most often learn something from, because the behavior it describes is invisible until it costs you an afternoon.

If you already hunt, start at Module 5 and read Module 4 afterwards rather than skipping it. Fleet work inherits every habit from single-host work, and the modules are ordered that way because the inheritance runs in one direction.

And if you have used this tool for years, the sections most likely to be new are the ones about what a result does not say: 4.5 on partial results, 5.1 on the missing denominator, 6.1 on evidence horizons, and 6.4 on clocks. Those are not advanced techniques, they are the assumptions the interface lets you keep.

The Course Fit Check in Module 0 will place you against the material, and its verdict is worth taking seriously in either direction. Somebody who answers all six correctly should still work the course, and should expect the value to be in the back half rather than the front.

Time and pace

Twenty-one hours of teaching content across seven modules, plus whatever time you spend on your own deployment, which is where the material becomes usable rather than familiar.

The realistic shape is a module a week for somebody doing this alongside a job, with the lab work folded into each module rather than saved for the end. Sections 5.4 and 7.3 in particular need a machine you can leave running for a day, so they reward being started early in a week rather than late.

The course also works as a reference after a first pass, which is what the two modules after Module 7 are for. The operational reference collects the commands, queries and procedures in one place for the working moment, and the references module points at the vendor documentation and community sources worth reading when something here stops being enough.

The one section to give an uninterrupted block is 7.6, the end-to-end case. It teaches nothing new and uses everything, and its value is in working it as an investigation rather than reading it as a chapter. Do it on your own deployment with a scenario you invent, and read the section afterwards rather than alongside, so that the joins are yours rather than borrowed.