Deploy Microsoft Sentinel End-to-End with Terraform on Azure

Microsoft Sentinel is Azure's cloud-native SIEM and SOAR platform, built on top of a Log Analytics Workspace that ingests security signals, runs scheduled KQL detections, and drives automated incident response. In production SOC environments, clicking through the Azure portal to onboard Sentinel, import threat intelligence, and author analytics rules does not scale and leaves no auditable record of how the detection estate was assembled. Treating Sentinel as infrastructure-as-code (declaring the workspace, its onboarding state, threat intelligence indicators, analytics rules, and automation rules in Terraform) makes the entire security foundation versioned, reviewable, and reproducible across subscriptions and environments.

The catch is that Sentinel objects are not independent resources: a scheduled analytics rule, a threat intelligence indicator, and an automation rule are all children of a workspace that must first be onboarded to Sentinel, and the Terraform provider has a well-known ordering pitfall where these children silently bind to the wrong workspace if the dependency graph is not made explicit. In this lab, you will author Terraform from an in-browser IDE to deploy a complete Sentinel foundation end to end: a Log Analytics Workspace, the Sentinel onboarding resource, a workspace-scoped threat intelligence indicator, one scheduled KQL analytics rule, and one automation rule. You will use explicit depends_on relationships to guarantee the provider builds them in the correct order.

By completing this Intermediate lab, you will be able to:

• Author Terraform that provisions a Log Analytics Workspace and onboards it to Microsoft Sentinel using azurerm_sentinel_log_analytics_workspace_onboarding
• Deploy a workspace-scoped threat intelligence indicator with azurerm_sentinel_threat_intelligence_indicator as an indicator of compromise declared in code
• Define a scheduled KQL analytics rule with azurerm_sentinel_alert_rule_scheduled, setting severity, query frequency, and trigger threshold
• Create an incident automation rule with azurerm_sentinel_automation_rule that acts on generated incidents
• Apply explicit depends_on ordering so Sentinel children bind to the onboarded workspace and avoid the known provider race condition
• Run the full terraform init, plan, and apply workflow against a pre-provisioned resource group and confirm the deployed Sentinel foundation

Who is this lab for?

This lab is designed for:

• Cloud and Security engineers who want to manage Microsoft Sentinel as infrastructure-as-code rather than through the portal
• SOC engineers and detection-content authors moving toward versioned, reviewable security configuration