Alz Accelerator

Azure Landing Zones Accelerator Skill

Deploy Azure Landing Zones using the ALZ Accelerator with Azure Verified Modules (AVM). This skill captures the recommended workflow, decision framework, and best practices from the ALZ core team.

Key Concepts

AVM (Azure Verified Modules): An infrastructure-as-code standard for deploying Azure resources following best practices. AVM has resource modules (single resources) and pattern modules (complex architectural patterns composed from resource modules). AVM is the only recommended way to deploy Azure Landing Zones infrastructure.

ALZ Accelerator: A tool that bootstraps the entire Azure Landing Zone deployment including CI/CD pipelines, version control, and infrastructure configuration. It uses AVM modules under the hood.

Deployment Stacks (Bicep): Used by the Bicep accelerator to handle resource lifecycle management, eliminating the pain of manually managing policy assignments and resource deletions.

Decision Framework: Bicep vs Terraform

Guide the user through this decision before proceeding with deployment.

When to Choose Terraform

• Team already has Terraform expertise
• Multi-cloud strategy (AWS, GCP, Azure) — avoids learning two IaC languages
• Terraform ALZ modules are more mature (released ~early 2025) with full configuration via tfvars
• Need for state-based drift detection

When to Choose Bicep

• Azure-only organization with no multi-cloud plans
• Team familiar with ARM templates or Azure-native tooling
• No state file to manage (pro and con — simpler ops but less drift visibility)
• Microsoft ARM/Bicep product groups recommend Bicep for Azure-only shops
• Bicep ALZ released ~Feb 2026 with full AVM support, deployment stacks, and customizable modules

Neutral Position

• Both use AVM modules — same underlying resource definitions
• Both are supported by the accelerator with identical bootstrapping UX
• The gap between them is closing rapidly in 2026
• Default recommendation: Match the team's existing skills

Accelerator Deployment Workflow

Prerequisites

1. Install the ALZ PowerShell module:

   Install-Module -Name ALZ

2. Ensure you have:

• Azure CLI or PowerShell authenticated
• GitHub PAT or Azure DevOps PAT (depending on VCS choice)
• At least 4 platform subscriptions: Management, Connectivity, Identity, Security
• A bootstrap subscription for state storage and identities

Step 1: Launch the Accelerator

Deploy-Accelerator

The accelerator runs interactively with guided prompts. No parameters are required (as of the latest release).

Step 2: Software Checks

The accelerator validates required software is installed. Address any missing dependencies before proceeding.

Step 3: Choose Cache Location

Select where to store temporary files during setup. The default is usually fine.

Step 4: IaC Language Selection

Choose between:

• Terraform — More mature configuration, everything via tfvars
• Bicep — Azure-native, no state file, deployment stacks for lifecycle management

Step 5: Version Control & CI/CD Platform

Choose from:

• GitHub (default, recommended)
• Azure DevOps
• Local filesystem (for custom bootstrapping)

Step 6: Connectivity Scenario

Select the networking topology:

• Hub and Spoke — Traditional hub-spoke with VNet peering (most common)
• Virtual WAN — Azure Virtual WAN managed hub
• Multi-region variants of the above

Step 7: Interactive Configuration

The accelerator queries Azure for your existing resources and presents selection prompts:

1. Bootstrap region — Where to deploy state storage and identities 2. Root management group — Parent MG for the ALZ hierarchy 3. Platform subscriptions:

• Management subscription (Log Analytics, monitoring)
• Identity subscription (Active Directory, DNS)
• Connectivity subscription (Hub VNet, Firewall, VPN/ER gateways)
• Security subscription (Sentinel, Defender)

4. Bootstrap subscription — For Terraform state storage and managed identities

Step 8: Naming Convention

Accept defaults or customize resource naming patterns for the bootstrap resources.

Step 9: Runner Configuration

Choose between:

• Self-hosted runners — Recommended for private networking
• Microsoft-hosted runners — Simpler but requires public endpoints

If self-hosted, choose whether to enable private networking (storage accounts not publicly accessible).

Step 10: Authentication

Provide:

• Personal Access Token — GitHub PAT or Azure DevOps PAT (stored as environment variable, never in config files)
• GitHub/ADO organization name
• Apply approver — Username that approves plan-to-apply stage

Step 11: Review & Open in IDE

The accelerator generates configuration files and opens them in VS Code. Review and update:

1. Platform landing zone config:

• Primary and secondary deployment regions (e.g., UK South, UK West)
• Defender email security contact

2. Sensitive values are stored as environment variables in the current terminal session, not in plain text files

Step 12: Bootstrap Deployment

Confirm the configuration is complete. The accelerator bootstraps:

• State storage (Terraform) or deployment stack (Bicep)
• Managed identities for CI/CD
• GitHub repos/Azure DevOps projects with pipelines
• Branch policies and approvals

Post-Deployment

After the accelerator completes:

1. CI/CD pipelines are created in your chosen VCS 2. Plan/What-If stage runs automatically on PR 3. Apply/Deploy stage requires approval from the configured approver 4. Subsequent changes are made through the configuration files and pushed through the pipeline

AVM Module Architecture

The ALZ deployment uses these key AVM pattern modules:

You can use these modules standalone (compose them yourself) or through the accelerator (recommended path).

Rules

1. Always use AVM modules — Never deploy ALZ resources with raw azurerm/azapi resources when an AVM module exists 2. Use the accelerator — Don't manually compose the modules unless you have a specific reason; the accelerator handles bootstrapping, CI/CD, and configuration 3. Match team skills — Don't push Terraform on a Bicep team or vice versa 4. Private networking for production — Use self-hosted runners with private networking for any production deployment 5. Never store PATs in config files — The accelerator uses environment variables for sensitive values; maintain this pattern 6. Four platform subscriptions minimum — Management, Connectivity, Identity, Security — don't collapse them 7. Plan before apply — Always review the plan/what-if output before approving deployment 8. Customize via config, not module edits — For Terraform, all customization goes through tfvars. For Bicep, you can edit modules directly but prefer the config approach when possible

Troubleshooting

Resources

• Questions form: aka.ms/alz/quests
• ALZ documentation: aka.ms/alz
• AVM registry: aka.ms/avm
• ALZ Accelerator docs: aka.ms/alz/accelerator

---

Gotchas

• Bicep `what-if` is best-effort — nested deployments may show resources as "Create" when they exist; trust ARM deploy output, not what-if alone.
• AVM module versions pin at deploy time — an outdated version: parameter pulls a months-old release with bugs you fixed locally.
• Management group ID is global — choosing a name collision returns 409 mid-deploy, halfway through other deployments.
• Default policy assignments include audit effects that flood activity logs in non-prod — disable explicitly or noise drowns real signal.
• Subscription quotas check at create-time, not validation-time — what-if passes, create fails with quota error 5 min in.
• Bicep template specs vs raw .bicep: template specs are versioned in ARM; raw .bicep deploys skip that versioning entirely.

ALZ Accelerator Interactive Flow — Step-by-Step Reference

This documents the exact interactive flow demonstrated by the ALZ core team (Jared) in the ALZ Weekly video series (2026).

Prerequisites Checklist

Before running Deploy-Accelerator:

• [ ] ALZ PowerShell module installed (Install-Module -Name ALZ)
• [ ] Azure CLI authenticated (az login)
• [ ] GitHub PAT or Azure DevOps PAT ready
• [ ] Platform subscriptions created:
• Management subscription
• Connectivity subscription
• Identity subscription
• Security subscription
• Bootstrap subscription (for state/identities)
• [ ] Root management group identified or created

Interactive Flow Sequence

Phase 1: Setup

Deploy-Accelerator

1. Software validation — Checks for required tools (az, terraform/bicep, git) 2. Cache directory — Where to store temp files (accept default or specify)

• If directory exists with prior data, confirm overwrite

3. IaC selection — Terraform or Bicep 4. VCS selection — GitHub (default) | Azure DevOps | Local filesystem 5. Connectivity scenario — Multiple options:

• Scenario 1: Full multi-region hub-and-spoke virtual networking
• Other scenarios for vWAN, single-region, etc.

Phase 2: Azure Resource Discovery

The accelerator queries your Azure tenant to discover:

• Available regions
• Existing management groups
• Available subscriptions

This takes ~1 minute depending on tenant size.

Phase 3: Configuration Prompts

Each prompt shows numbered options from your Azure tenant:

6. Bootstrap region — Select from numbered list of Azure regions

• Example: 49 for Sweden Central

7. Root management group — Select parent MG for ALZ hierarchy 8. Management subscription — Select from numbered subscription list 9. Identity subscription — Select from list 10. Connectivity subscription — Select from list 11. Security subscription — Select from list 12. Bootstrap subscription — For Terraform state storage / managed identities

Phase 4: Bootstrap Configuration

13. Resource naming convention — Accept defaults or customize prefix/suffix 14. Runner type — Self-hosted or Microsoft-hosted

• Self-hosted recommended for private networking

15. Private networking — Yes/No (storage account public access)

• Recommended: Yes for production

16. Personal Access Token — Paste PAT (displayed obfuscated) 17. GitHub/ADO organization name — Your org handle 18. Apply approver — Username for plan→apply approval gate

Phase 5: Review & Customize

19. Open in VS Code? — Yes (default) opens generated config files 20. Review generated files:

• Bootstrap config: All selections pre-populated
• Sensitive values: Stored as env vars in terminal session, NOT in files
• Platform landing zone config: Requires manual edits:
• Primary deployment region (e.g., uksouth)
• Secondary deployment region (e.g., ukwest)
• Defender email security contact

21. Confirm configuration complete — Type yes when done editing

Phase 6: Bootstrap Execution

22. The accelerator runs Terraform/Bicep to provision:

• Azure Storage Account (Terraform state backend)
• Managed Identities (for CI/CD pipeline auth)
• GitHub repository with Actions workflows / ADO project with pipelines
• Branch policies and protection rules
• Approval gates between plan and apply stages

File Structure Generated

<output-directory>/
  bootstrap/
    terraform.tfvars          # Bootstrap configuration (auto-generated)
  platform/
    terraform.tfvars          # Platform landing zone config (needs manual edits)
  .github/
    workflows/                # CI/CD pipeline definitions (if GitHub)

Key Security Points

• PATs are stored as environment variables in the current terminal session
• They are never written to config files in plain text
• The accelerator displays sensitive values as obfuscated text
• Self-hosted runners + private networking = no public storage endpoints

Notes from the Demo

• The interactive mode is new (early 2026) — previously required manual config file editing
• The "advanced scenario" docs still show the old manual method
• Planning docs are linked from each prompt for reference (aka.ms/alz/accelerator)
• You can still supply input config files directly for automation/CI scenarios

Bicep vs Terraform for Azure Landing Zones — Detailed Comparison

Feature Matrix (as of early 2026)

Terraform Strengths

• Mature configuration model: Everything customizable through tfvars without touching module code
• State-based operations: Reliable drift detection, import, targeted apply
• Multi-cloud portable skills: Same language for AWS, GCP, Azure
• Longer ALZ track record: ~1 year head start on AVM integration
• Ecosystem: Rich provider ecosystem, community modules

Bicep Strengths

• No state file: Eliminates state locking issues, state corruption, state migration
• Deployment Stacks: Azure-native lifecycle management for resource cleanup
• Full module ownership: You get the complete repository — customize anything without waiting for upstream releases
• Separated policy management: Custom policies and Azure default policies are cleanly separated
• Azure product group recommendation: ARM/Bicep teams recommend Bicep for Azure-only organizations
• First-class Azure integration: No provider version lag, immediate support for new Azure features

Decision Checklist

Ask the user these questions to guide the decision:

1. Does your organization use or plan to use non-Azure clouds?

• Yes → Terraform (avoid learning two IaC languages)
• No → Either works, lean Bicep

2. Does your team have existing IaC expertise?

• Strong Terraform team → Terraform
• Strong ARM/Bicep team → Bicep
• No existing expertise → Bicep (simpler ops, no state management)

3. Do you need robust drift detection?

• Critical requirement → Terraform
• Nice-to-have → Either works

4. How important is immediate access to new Azure features?

• Very important → Bicep (no provider lag)
• Can wait for provider updates → Either works

5. How do you feel about state file management?

• Comfortable with it → Terraform
• Want to avoid it → Bicep

ALZ Core Team Positions

From the ALZ weekly video (2026):

• Matt: "Whichever one your team is best suited for — it's down to team skills" (diplomatic answer)
• Jared: "Obviously Terraform better" (joking, but acknowledges Terraform's maturity lead)
• Zach: Leans Bicep due to familiarity but notes Terraform is equally viable
• Consensus: The gap is closing rapidly in 2026. Both are fully supported with AVM.