Security Automation Engineering

What the course builds and how it is built, the tools and their versions, installing them with the lab pack, and your first workflow run in the local runtime against the harness.

Build a Logic Apps Standard security playbook and run it locally: read an incident safely, decide, look up devices in Defender, comment on the incident and fail with a record.

Specify a security playbook as cases and run them on every change: decisions, inputs, outputs, components, stop conditions and regression checks.

Give a security playbook least-privilege identities: one token per API, a reader and a writer, a permission matrix run as tests, secrets out of run history and the repository, and a rotation with no failed run.

Add query evidence to a security playbook: the Log Analytics query API, saved functions with guarded parameters, a tested window, and a sentence for every way a query can fall short.

Call the Microsoft security APIs from a playbook: Graph alerts paged to the end, a shared child workflow with one vocabulary of failure, Defender rate limits, and an antivirus scan polled to its end.

Enrich the triage comment with the account, device, addresses and threat intelligence through saved workspace functions, audit the watchlists behind them, and keep a traceable evidence record of every fact.

Put code where the workflow needs it: inline JavaScript, inline PowerShell, and a tested PowerShell Azure Function that reads Microsoft Graph with its own identity and answers the playbook in one contract.

Ask an analyst before acting: an approval record bound to one device and one action, sent through the HTTP Webhook action with an expiry, a decision that must match its request, and a recheck before anything is done.

Act on an approval and verify it: isolate a device once, follow the machine action to its end, verify against the record, release with its own approval, disable an account through Graph, and package both as templates.

Make the triage playbook safe to run twice: guard each action against earlier work, key comments so reruns update them, close the race between concurrent runs, handle malformed entities, and label a failed containment.

Put the triage playbook into a tenant: managed identities, Bicep infrastructure, the Sentinel trigger, automation rules as code, a pipeline that checks before it deploys, and a rollback that switches the rules off first.

Keep the deployed playbook working: the health log, the run log, four alert rules, a cost model, retention and a generated handover; then the capstone, one incident through every stage in seven cases.

One sheet per subject of the course: the question, the workflow fragment, query or command that answers it, what to read in the result and what it does not prove.

Seven runbooks, one per stage of building a security playbook: the lab, the specification, identities, evidence, containment, running twice safely, and deployment with its handover.

The local lab every lesson runs in: what each part plays, what replaces it in a tenant, the settings and faults it can switch on, and how to prove it works and how far back its data reaches.

The six investigations the course automates, each worked end to end with the wrong turns: a suspicious sign-in, endpoint execution, a reported phish, an indicator, repeated incident updates and a failed containment.

The template pack, and one playbook for each thing that fires once the triage playbook is deployed: a rule run that did not start it, a failed run, a failed containment, an incident nothing touched, and a release that did not verify.

The exercise that closes each module, with what each asks you to build, the lab it runs in, and how it is checked.

Every Microsoft Learn page the lessons were built from, grouped by product, each with the lessons that rely on it.

Security Automation Engineering end-of-course exam: 29 questions in four parts, from building the workflow to operating it, ending on a case study.