Azure Platform Landing Zone Accelerator Issue

Hello Ashish Sharma

What you are observing during your POC is expected and by design for the Azure Platform Landing Zone Accelerator (Terraform).

The ALZ Accelerator’s purpose is to bootstrap a governed Infrastructure‑as‑Code (IaC) environment and provide starter Terraform code for Azure Landing Zones. Specifically, it:

• Bootstraps CI/CD (Azure DevOps or GitHub)
• Creates:
  • Terraform backend (storage account, container, state RG)
    • Managed identities for Plan / Apply
      • Initial repository structure and pipelines
      • Deploys only the platform components explicitly enabled in the starter module configuration

This is documented in Microsoft’s official ALZ Accelerator documentation: Azure Landing Zone IaC Accelerator – Overview

Why only MG hierarchy, subscription placement, connectivity resources are created?

When using the Terraform ALZ Accelerator:

• Management group hierarchy
• Subscription placement
• Connectivity resources

are deployed only if they are enabled in the Terraform starter module inputs and archetypes.

The accelerator does not automatically deploy all CAF design‑area services (Security, Management, Monitoring). This separation is intentional.

Reference: Azure Landing Zones – IaC Accelerator documentation

Policy and role assignments in ALZ are archetype‑driven, not automatic.

• alz_custom.alz_architecture_definition.yaml defines management group structure
• Policy assignments and RBAC come from archetype definitions
• If your custom archetypes do not inherit or explicitly include policy/role assignments, nothing will be applied

This behavior is documented in Microsoft’s ALZ override library guidance: Azure Landing Zone library with overrides

The Terraform Platform Landing Zone (AVM) modules:

• Do NOT deploy Microsoft Sentinel
• Do NOT enable Defender for Cloud plans
• Do NOT deploy Azure Monitor / Log Analytics by default

Reason: These services are subscription‑specific, region‑dependent, and workload‑dependent, and Microsoft intentionally keeps them out of the core platform deployment to avoid forced assumptions.

Official references:

• Deploy Azure Landing Zones – Platform deployment scope
• ALZ AMA / Management parity guidance

Microsoft’s recommendation is to deploy these using separate Terraform stacks or AVM modules, once the platform foundation is in place.

The Terraform backend (storage account, container, tfstate) is created and controlled by the bootstrap module, not by:

• alz_architecture_definition.yaml
• Starter module logic

Backend customization (naming, SKU, RG) is supported only during the bootstrap configuration phase.

Official documentation: Advanced Bootstrap – Azure Landing Zone Accelerator

Microsoft recommends:

• Use separate Terraform deployments (separate states)
• Reuse the same backend storage account
• Deploy:
  • Microsoft Sentinel
    • Defender for Cloud
      • Azure Monitor / Log Analytics
        • Additional policy initiatives

This separation is a documented ALZ design principle, not a limitation.

Source: Azure Landing Zones – Implementation options

The Azure Platform Landing Zone Accelerator is working as designed. It bootstraps a governed Terraform environment and deploys only the components explicitly enabled in the starter module and archetypes.

Azure Policy assignments, RBAC, Microsoft Sentinel, Defender for Cloud, and Azure Monitor are not deployed automatically and must be implemented using separate Terraform modules or stacks, as recommended by Microsoft.

Terraform backend resources are created during the bootstrap phase and are not controlled by architecture YAML files.

Thanks,
Suchitra.

Hi ,

Thanks for reaching out to Microsoft Q&A.

The Azure Landing Zones Accelerator bootstrap only sets up core platform scaffolding like management groups, subscriptions, connectivity, and tfstate storage, and does not deploy security services such as Microsoft Sentinel or configure Microsoft Defender for Cloud, since those are treated as Day-2 operations. Customisation of the storage account and tfstate is limited through inputs.yaml, so for full control you need to modify or fork the bootstrap module or provision your own backend separately. Policy and initiative assignments will not happen unless you explicitly include CAF archetypes or define policy blocks in your configuration.

For security, monitoring, and additional governance, the recommended approach is to use separate Terraform stacks leveraging Azure Verified Modules, reusing the same backend with different state keys and optionally referencing ALZ outputs via remote state, which gives better modularity and aligns with enterprise landing zone design. 

Please 'Upvote'(Thumbs-up) and 'Accept' as answer if the reply was helpful. This will be benefitting other community members who face the same issue.