Sentinel Automation Fundamentals

1.1 What this module builds

SA0 established the framework — the three automation tiers, confidence thresholds, blast radius assessment. This module turns that framework into working automation. You will build your first Sentinel automation rule in under five minutes, then build a Logic App playbook that enriches incidents with user risk data and posts the results to Teams.

The module covers every mechanical foundation you need before the enrichment, containment, and notification modules that follow. How automation rules execute. How Logic Apps process triggers. How managed identities authenticate to Microsoft APIs. How entity extraction feeds data into playbook logic. How error handling prevents silent failures. How testing validates behavior before production. How monitoring detects failures after deployment. How cost management keeps playbook expenses predictable.

By the end, you have two working automations in your Sentinel workspace: an automation rule that accelerates AiTM triage, and a playbook that enriches every incident with user context. Both are Tier 1 automations — zero blast radius, immediate operational value.

1.2 What you will learn

Ten sections plus an interactive lab, each building on the previous.

Section 1.1 — Automation Rules: The Lightweight Layer. How automation rules execute inline during incident creation. Trigger types, condition logic, action configuration. The decision boundary between automation rules and playbooks — property changes stay in automation rules, multi-step workflows go to playbooks.

Section 1.2 — Playbooks: The Power Layer. Logic App architecture — triggers, actions, connectors, control flow. The incident trigger schema. How playbooks connect to Sentinel through the Microsoft Sentinel connector. Run history, action-level debugging, and the execution model that determines how Logic Apps process data.

Section 1.3 — Your First Automation Rule. Building an automation rule that sets AiTM alert severity to High, assigns the incident to a senior analyst, and adds a triage-priority tag. Condition matching on incident title. Verifying execution in the Automation blade.

Section 1.4 — Your First Playbook. Building a Logic App playbook that queries the Microsoft Graph API for user risk data, retrieves recent sign-in activity, checks device compliance status, and posts an enrichment summary to a Teams channel. End-to-end walkthrough from resource creation through trigger configuration, API calls, and message formatting.

Section 1.5 — Authentication and Permissions. Managed identity vs service principal authentication. The three permission layers — workspace-scoped RBAC, Entra ID directory roles, and Graph API application permissions. Granting IdentityRiskyUser.Read.All through the Graph PowerShell SDK. Why over-permissioning is the most common playbook security failure.

Section 1.6 — Entity Extraction and Mapping. How the incident trigger delivers entity data. The entities array structure — account, host, IP, URL, file hash. Parsing entity JSON with Compose and Parse JSON actions. Building dynamic content references that feed entity values into API calls. Handling incidents with zero entities and incidents with multiple entities of the same type.

Section 1.7 — Error Handling and Retry Logic. Configure After settings — succeeded, failed, skipped, timed out. Scope blocks for try-catch patterns. Retry policies for transient API failures. The critical difference between action-level failure and run-level failure, and why monitoring must check both.

Section 1.8 — Testing Automation Safely. The testing methodology: dev workspace, synthetic incidents, condition narrowing, phased rollout. Creating test incidents with PowerShell. Validating playbook output against expected results. The pre-production checklist that catches permission gaps, entity edge cases, and cost surprises before production deployment.

Section 1.9 — Monitoring Automation Health. KQL queries against AzureDiagnostics for Logic App execution data. Tracking success rates, failure patterns, and execution duration. Building a Sentinel workbook that surfaces automation health alongside detection coverage. The three monitoring queries every playbook needs: failure rate, latency trend, and action-level error breakdown.

Section 1.10 — Cost Management. Logic App pricing model — per-connector-action billing, Standard vs Consumption plans. Calculating expected costs from incident volume and actions-per-run. The For Each trap that turns 25-entity incidents into budget surprises. Cost alerts, Azure Monitor budgets, and the cost-per-incident metric that keeps automation expenses visible.

Section 1.11 — Guided Walkthrough. A single walkthrough that connects the full chain — automation rule triggers playbook, playbook authenticates via managed identity, extracts entities, calls Graph API, handles errors, posts enrichment summary. Every section's concept in one working flow, with monitoring queries that verify the result.

1.3 How automation rules and playbooks work together

Automation rules and playbooks are complementary, not competing. Automation rules execute inline during incident creation — they modify incident properties (severity, status, owner, tags) and can trigger playbooks. They complete in under ten seconds, cost nothing, and require no external infrastructure.

Playbooks are Logic Apps triggered by Sentinel. They handle multi-step workflows — API enrichment, containment actions, notification routing, evidence collection. They carry execution costs, require managed identity permissions, and need error handling and monitoring. Every playbook in this course is triggered by an automation rule, not by a direct analytics rule action.

The separation matters for maintainability. When the on-call analyst changes, you update the automation rule. When the enrichment API changes, you update the playbook. Neither change requires touching the other. This separation is the foundation the enrichment, containment, and notification modules build on.

1.4 How to get the best from this module

Work through sections 1.1 and 1.2 first — they establish the mental model for how automation rules and playbooks execute. Then build your first automation rule (1.3) and first playbook (1.4) before reading the supporting sections. Having working automation in front of you makes the authentication, entity, error handling, and monitoring sections concrete rather than abstract.

If you already build Logic Apps in your day job, sections 1.1 through 1.4 will move quickly. Start at section 1.5 (authentication) if the fundamentals are familiar — the permission model, entity extraction patterns, and error handling approaches are where most production playbooks fail, and those sections are where this module adds the most value regardless of experience level.

The guided walkthrough in section 1.11 ties everything together. Save it for after you have completed sections 1.1 through 1.10 — it assumes familiarity with every concept and builds one end-to-end automation chain.

Estimated total time: 5 hours. Three to four sections per session produces consistent progress.

1.5 Module structure

• Section 1.1 — Automation Rules: The Lightweight Layer
• Section 1.2 — Playbooks: The Power Layer
• Section 1.3 — Your First Automation Rule
• Section 1.4 — Your First Playbook
• Section 1.5 — Authentication and Permissions
• Section 1.6 — Entity Extraction and Mapping
• Section 1.7 — Error Handling and Retry Logic
• Section 1.8 — Testing Automation Safely
• Section 1.9 — Monitoring Automation Health
• Section 1.10 — Cost Management
• Section 1.11 — Guided Walkthrough: Connecting the Automation Chain
• Section 1.12 — Module Summary
• Section 1.13 — Check My Knowledge

No prerequisites beyond SA0. If you completed SA0, you have the framework. This module builds the first working implementations.

Go to Section 1.1 — Automation Rules: The Lightweight Layer to begin.