0.1 What This Course Builds

Introduction

This course teaches you to build security automation on Microsoft's platform: a playbook that Microsoft Sentinel starts when an incident arrives, that gathers the evidence an analyst would gather, asks a person before it changes anything, contains a device when that person agrees, checks that the containment held, and reports every step on the incident.

You build one playbook, from its first trigger in Module 1 to a monitored deployment in a tenant in Module 12, and every lesson changes it and runs it.

This lesson shows where that ends. It quotes what the finished playbook writes on a real incident, lists the files you will have built, sets out the twelve modules and the six kinds of investigation they cover, and says who the course is for and what it leaves out. The rest of Module 0 explains how the course is built, installs the tools and runs your first workflow.

At the end of the course, the playbook is sent a High incident on a laptop called NE-THOMPSON-LT. It writes a triage note and, once an approver agrees, a containment line. The beginning and end of what it wrote, from the capstone run in Lesson 12.8:

Triage playbook | run 08584070123280099430474388575CU00
Incident 100448. Severity High, status New. Decision: investigate.
Entities (4): Host NE-THOMPSON-LT, Account d.thompson, Process powershell.exe, Ip
  185.234.89.112
- NE-THOMPSON-LT: device 3c9e0b7a5d14f2e86a1c4b07d9e3f5a2c8b6d410, Active
Sign-ins for d.thompson@ne.com from 2026-03-10T09:31:00Z to 2026-03-10T11:53:35Z:
  none under this name.
...
Approval: isolate NE-THOMPSON-LT approved by t2-lead@ne.com at
  2026-11-13T18:30:43.011Z; rechecked at 2026-11-13T18:30:45.4360169Z. Ready to act.
Isolation: NE-THOMPSON-LT isolated (Full); action
  98fdb469-4008-4c87-8ecb-113ee8012cde Succeeded at 2026-11-13T18:30:55.408Z;
  verified: no release since.

Every line is something the course builds. The first names the run that wrote it, so the note can be traced. The entities, the device matched in Microsoft Defender for Endpoint and the evidence lines come from Modules 1, 4, 5 and 6.

The approval line is Module 8's: it names who approved and when the playbook checked again that nothing had changed. The isolation line is Module 9's: it names the device, the action Defender recorded and the word that matters most, verified, which the playbook writes only after reading Defender's own history.

What it does not write matters as much. It does not say the account is compromised, because nothing it read proved that. It does not disable the account or touch the other host the evidence implies, because those are decisions for a person with the whole picture. The note says what the playbook found and what it did, and the analyst starts from there.

Behind the two comments is what the run actually did, read from the run itself:

{
  "what the capstone run did": {
    "Defender actions": [
      "RunAntiVirusScan",
      "Isolate"
    ],
    "evidence facts": 7,
    "comments written": 2,
    "run": "Succeeded"
  }
}

Two actions in Defender, a scan and an isolation, both requested only after the playbook had decided they were warranted, and the isolation only after a person approved it. The evidence facts are the separate lookups the triage note summarizes, each with its own source, and the run status says the workflow ended as designed.

That is the standard the course holds every step to. A playbook that acts on a guess, hides a failed lookup or reports an action as done when it was only requested is worse than no playbook, because people trust it.

Each module adds a capability and the control that makes it safe to run unattended: the evidence step reports what it could not find, the approval names one device and one action, the containment is verified, a duplicate incident does not trigger a second isolation, and a failure leaves a label someone will see.

None of this needs to make sense yet. Each line will, in the module that builds it, and by the capstone you will be able to read a note like this and say which action in the workflow wrote each clause and what it checked first.

By Module 12 the playbook is also something an operations team can run: its runs are logged, four alerts watch it, its cost is modeled and a handover document is generated from the files that deploy it.

The finished playbook is not one file. Its shape at the end of the course:

{
  "the playbook at the end of Module 12": {
    "workflows": [
      "block-indicator",
      "call-api",
      "disable-account",
      "enable-account",
      "entry",
      "entry-block-indicator",
      "entry-disable-account",
      "entry-enable-account",
      "entry-release",
      "entry-remove-message",
      "entry-restore-message",
      "entry-restrict-app-execution",
      "entry-unblock-indicator",
      "entry-unrestrict-app-execution",
      "release",
      "remove-message",
      "restore-message",
      "restrict-app-execution",
      "triage",
      "unblock-indicator",
      "unrestrict-app-execution"
    ],
    "actions in triage": 188,
    "identities": [
      "reader",
      "writer",
      "scanner",
      "container",
      "account"
    ],
    "deployed by": [
      "main.bicep",
      "rules.bicep",
      "monitor.bicep",
      "workflows.zip"
    ]
  }
}

The triage workflow is the playbook proper: 188 actions that read the incident, decide, gather evidence, ask, act and verify. Around it sit small workflows with one job each. call-api makes every call to a Microsoft API in one place, so throttling and errors are handled once. release, disable-account and enable-account are the containment actions and their reverses, each with its own approval.

The entry workflows hold the Sentinel trigger, which lets the triage workflow be tested in the lab with a plain request and run in a tenant by an automation rule without changing.

Five managed identities each hold exactly the permissions their calls need: one reads, one writes comments, one starts scans, one isolates devices and one changes accounts. Module 3 sets that split up with lab identities, and Module 11 replaces them with managed identities that have no secrets at all.

Four files deploy it. main.bicep creates the logic app, its identities, its Key Vault and its connection to Sentinel. rules.bicep creates the two automation rules that start it. monitor.bicep adds the queries and alerts that watch it. workflows.zip carries the workflow definitions. A script deploys a tagged version; another rolls back with the rules switched off first.

The split into small workflows is a design decision the course argues for in Module 2 and Module 5. One workflow that did everything would be hard to test, because a case could not exercise the API calls without the decisions around them, and hard to change, because every change would touch the part of the playbook that isolates devices.

Small workflows with clear inputs and outputs can each be tested on their own and replaced without the others noticing.

Everything is a text file in a repository: definitions in JSON, infrastructure in Bicep, tests in JSON, scripts in bash and Python. That is deliberate. A playbook built by clicking in a portal cannot be reviewed, versioned or redeployed the same way twice, and the course treats a playbook as software that happens to respond to incidents.

The modules, in the order the playbook grows, each with what you have built when it ends:

{
  "Module 1": {
    "title": "Your First Security Playbook",
    "builds": "an incident-commenting playbook"
  },
  "Module 2": {
    "title": "Designing the Workflow",
    "builds": "workflow specification and decision table"
  },
  "Module 3": {
    "title": "Identity and Secrets",
    "builds": "tested permission matrix, allowed and denied calls run"
  },
  "Module 4": {
    "title": "Querying Evidence",
    "builds": "a query-backed evidence step"
  },
  "Module 5": {
    "title": "Calling the Security APIs",
    "builds": "a reusable API integration with predictable errors"
  },
  "Module 6": {
    "title": "Enrichment and Evidence",
    "builds": "an enrichment record and evidence package"
  },
  "Module 7": {
    "title": "Code in the Workflow",
    "builds": "a tested Function the playbook calls"
  },
  "Module 8": {
    "title": "Analyst Approval",
    "builds": "an approval tied to one target and action"
  },
  "Module 9": {
    "title": "Response and Verification",
    "builds": "a controlled containment workflow with verified outcomes"
  },
  "Module 10": {
    "title": "Surviving Failure",
    "builds": "a workflow that survives injected failures, repeating nothing harmful"
  },
  "Module 11": {
    "title": "Deploying to a Tenant",
    "builds": "a versioned deployment in the student's tenant"
  },
  "Module 12": {
    "title": "Operating It, and Capstone",
    "builds": "an operational workflow with documentation, monitoring and handover"
  }
}

Modules 1 to 3 build the skeleton and its identities. Module 1 receives an incident, reads it, decides and writes a comment back. Module 2 steps back and specifies what the playbook should do, with a decision table and the cases that will test it, before it grows. Module 3 gives it identities, separating what it may read from what it may change.

Modules 4 to 7 give it evidence. Module 4 queries Log Analytics through saved functions that report when results are incomplete. Module 5 calls the Microsoft Graph and Defender APIs, with paging, throttling and asynchronous actions.

Module 6 enriches accounts, devices, addresses and files and keeps a record of every fact and where it came from. Module 7 adds code where expressions are not enough, in inline code and an Azure Function.

Modules 8 to 10 make it safe to act. Module 8 asks an analyst for approval, with expiry and a recheck before anything happens. Module 9 isolates a device and disables an account, follows each action and verifies the outcome, and packages both as templates. Module 10 makes the playbook survive duplicate incidents, failures and malformed input without repeating anything harmful.

Modules 11 and 12 take it to production. Module 11 deploys it to a tenant with Bicep, managed identities and automation rules, through a pipeline. Module 12 monitors it, costs it, hands it over and ends with the capstone.

The order is the order of trust. A playbook first earns the right to read, then to report, then to propose, and only then to act, and each step brings the controls the next one depends on.

Containment comes in Module 9 because it needs the identities of Module 3, the evidence of Modules 4 to 6 and the approval of Module 8 to be safe. Deploying comes last because a playbook that has not survived Module 10 should not be running unattended anywhere.

Every module ends with an exercise: a reference build and two drafts that each fail in a way the module teaches you to catch, run against the same cases so the difference is visible in the results.

The playbook meets the kinds of incident a SOC handles every day. The course works through six, each with a control that is the reason the automation can be trusted with it:

{
  "suspicious sign-in": {
    "automates": "account context, recent authentication, privilege",
    "control": "escalate incomplete evidence; a location is not compromise"
  },
  "endpoint execution": {
    "automates": "process, network and device context; a recommendation",
    "control": "exactly one device; protected assets refused"
  },
  "phishing report": {
    "automates": "the message, its URLs, related recipients and activity",
    "control": "keep message identifiers; validate the removal scope"
  },
  "malicious indicator": {
    "automates": "a search of the estate, with supporting activity",
    "control": "no automatic block on one reputation result"
  },
  "repeated incident updates": {
    "automates": "refreshed enrichment and synchronized notes",
    "control": "no loops, duplicate notifications or repeated actions"
  },
  "failed containment": {
    "automates": "timeouts, denials and partial completion, reported",
    "control": "record the actual state; leave a manual recovery path"
  }
}

The sign-in investigation teaches that a sign-in from an unusual place is a question, not a conclusion: the playbook gathers the account's context and recent authentication and escalates when the evidence is incomplete. The endpoint investigation is the one the capstone uses: process, network and device context, and a containment recommendation that names exactly one device and refuses a protected one.

The phishing investigation resolves the reported message and checks the scope of any removal before it happens, because a loose filter removes legitimate mail across the organization. The indicator investigation searches the estate for an address or file, and never blocks on one source's reputation alone.

Each control is something the playbook does, not something it is told. An unusual location is not compromise because the sign-in step reports what it found and leaves the conclusion to the analyst. Exact device identification is a check in the workflow that stops when a host name matches more than one device.

The last two are about the playbook itself. Repeated updates to an incident must not start loops, duplicate notifications or a second containment. And a containment that fails, times out or half-completes must record what actually happened and leave a path for a person to finish the job.

The investigations are not separate modules. Four run through the lessons, each appearing where the capability it needs is taught: the sign-in and endpoint investigations from Module 4, where evidence first comes in; failed containment from Module 9; and repeated updates in Module 10.

Module 6 teaches the threat intelligence lookup the indicator investigation relies on. The indicator and phishing investigations are not built as playbooks in the lessons; their walkthroughs work the queries an evidence step would call, against the course corpus, and say so. The walkthroughs in the course resources follow all six from start to finish.

Two outcomes count as success that a beginner might not expect. An investigation that ends with no action because the activity was legitimate is a success. So is one that stops because the evidence is not enough to decide. The course has exercises that end each way, because a playbook that always finds something to do is not reading the evidence.

The course ends with a capstone: one incident, the playbook you built, and 7 cases that each test one way it could go wrong:

{
  "capstone cases, incident 100448": [
    "cap-contained",
    "cap-duplicate",
    "cap-evidence-down",
    "cap-isolate-fails",
    "cap-wrong-target",
    "cap-protected-now",
    "cap-rejected"
  ]
}

The cases are run with run-spec, the course's test runner, against the harness that plays Microsoft's services in the lab. They check the happy path, a duplicate incident, every evidence query failing at once, an isolation that fails, an approval for the wrong device, a device that becomes protected while the approval waits, and an approver who says no.

They ship with the course, so you check your own build, and the reference that passes them is shown in Lesson 12.8 beside two drafts that do not.

The capstone measures five things: whether the playbook's output is useful, whether its permissions are as narrow as they can be, whether it acts only on the right target, whether it survives duplicates and failures, and whether it verifies what it did. A workflow that finishes successfully while acting on the wrong device fails, however green its run.

The capstone incident is deliberately not the one the course uses from Module 1. A build that only works because it was tuned to one incident would show it on a different device, a different account and a different pattern of evidence, which is what an incident in a real queue looks like.

The course exam is the graded assessment. It asks the same kind of judgment through questions and case studies drawn from every module, and passing it earns the course certificate.

Passing the capstone is a statement about your build, not about the course's. The reference passes all 7; the point of the cases is that your own playbook, built lesson by lesson, can be checked the same way. A failing case points at a stage, and the stage points at the module that built it, which is where the fix belongs.

The cases are also how the course is built. Every module's exercise is a set of cases, and every lesson's change is run against the cases that came before it, so a change that breaks something earlier is caught where it was made.

The course is written for SOC analysts and security engineers who run Microsoft Sentinel or Defender XDR and want to build the automation for response work they already do by hand. The objective is that you can build it, not that you can describe it.

You do not need to have written code before. Every concept is explained the first time it is used, including JSON, HTTP, Logic Apps and how connectors work. What a playbook receives from Sentinel is JSON, and you will read a lot of it:

{
  "what a playbook receives, in part": {
    "object": {
      "properties": {
        "incidentNumber": 100472,
        "severity": "High",
        "status": "New",
        "title": "Ransomware activity detected"
      }
    },
    "relatedEntities": [
      {
        "kind": "Host",
        "properties": {
          "hostName": "NE-BENNETT-LT"
        }
      },
      {
        "kind": "Account",
        "properties": {
          "accountName": "l.bennett",
          "upnSuffix": "ne.com"
        }
      }
    ]
  }
}

That is a small part of an incident as the harness sends it, in the shape Sentinel uses: the incident's own properties, and the entities related to it. A real incident carries many more fields, most of which the playbook never reads. By the end of Module 1 you will read the whole thing, pull out the fields the playbook needs and handle the ones that are missing.

The playbook reads that JSON with expressions, small formulas written into the workflow, such as one that takes the host name from the first Host entity. Module 1 introduces them one at a time, and the cheatsheets at the end of the course collect every expression the playbook uses.

You need a computer that can run Visual Studio Code and a few command-line tools, and about two hours for Module 0. You do not need an Azure subscription, a Sentinel workspace or any license until Module 11: everything before that runs on your own machine against the harness. Module 11 needs a tenant where you can create resources and grant permissions, and the lessons say exactly which roles.

The tools are free. Visual Studio Code, the Azure Logic Apps (Standard) extension, the storage emulator it uses, Python and Node.js all cost nothing, and the lab pack holds the harness and the data it serves. Lesson 0.3 names each tool and why it is there, and Lesson 0.4 installs them on Windows, macOS or Linux.

The course assumes you know what a SOC does with an incident: triage, investigation, containment. It does not teach investigation technique beyond what a workflow encodes, and it does not assume you have built automation before.

Some things that sit close to security automation are deliberately not here:

{
  "not taught here": {
    "investigation technique": "only as far as a workflow encodes the procedure",
    "detection rules": "analytics rules appear only as the triggers of automation",
    "Logic Apps and Functions": "for security automation, not general development",
    "third-party SOAR": "the ideas transfer; the course builds on Microsoft's tools",
    "certification": "the course teaches the work, not an exam syllabus"
  }
}

Investigation technique is taught only as far as a playbook encodes it. The course shows how to automate the evidence an analyst gathers for a sign-in or an endpoint incident, not how to run an investigation from scratch; other courses on the platform do that.

Detection rules appear only as the thing that creates incidents and triggers automation. Writing and tuning them is a separate discipline. Logic Apps and Azure Functions are taught for security automation, not as general development platforms, so features a security playbook does not need are left out.

Microsoft Defender XDR's own automated investigation is mentioned where it overlaps, but the course does not depend on it. Module 2 explains when a built-in automation rule, a playbook, Defender's automated response or a function is the right tool for a job, and the playbook the course builds is the case where a custom workflow is the right answer.

Third-party SOAR platforms are not covered. The ideas transfer, approval, verification, idempotence, but the course builds on Microsoft's own tools from end to end. And it is not a certification course; it teaches the work, not an exam's syllabus.

The course also does not try to automate everything. Some steps stay with a person on purpose, and the course says which and why: approving a containment, deciding about a privileged account, judging whether a pattern of evidence adds up to a compromise.

A playbook that took those decisions away would be faster on a good day and much worse on a bad one, and much of the course is about drawing that line well.

The playbook you build is also not a product. It is a well-built example of how to automate safely, and its templates can be deployed, but a SOC adopting it will change its approvers, protected groups, thresholds and evidence to fit its own environment. The course shows where each of those lives, so that changing them is a parameter, not a rewrite.

Before installing anything, look at what the course builds and decide which part matters most to you.

Lesson 0.2 explains how the course is built: the lab, the harness, the cases and how a lesson is laid out.