Any seasoned barista will tell you that consistency is the secret ingredient. The same holds true for your cloud estate — it’s no good if every subscription ends up with a slightly different flavour. Governance in Azure Landing Zones (ALZ) ensures every cup (or workload) comes out consistent, auditable, and within your compliance recipe.

This post explores how Azure Policy, security baselines, and Microsoft’s Sovereign Landing Zone work together to create policy‑driven guardrails. We’ll look at how automation enforces consistency at scale and how those controls transfer neatly from an Azure Landing Zone (ALZ) to a Secure Landing Zone (SLZ).

☁️ What is Policy‑Driven Governance?

Policy‑driven governance is the backbone of any ALZ. It forms the control plane, enforcing compliance, tagging standards, cost management, and security configurations across management groups.

At the heart of this model is Azure Policy, which uses declarative JSON definitions to apply rules and standards across your environment. These can enforce mandatory compliance (deny actions) or informative compliance (audit only).

Microsoft’s Cloud Adoption Framework (CAF) and Azure Landing Zone Accelerators provide foundational policy sets that align with key governance disciplines:

• Resource Consistency: Standard naming, tagging, and region restrictions
• Security & Compliance: Enforce Defender plans, encryption, or private networking
• Operational Governance: Ensure diagnostic and monitoring settings are applied by default
• Data Sovereignty: Especially critical in Sovereign Landing Zone (SLZ) contexts

⚙️ How It Works

Azure Policy enforcement operates at multiple levels in your management group hierarchy, creating a cascading and inheritable model for governance.

Updated Example – ALZ Management Group Structure

Policies and initiatives are typically assigned at the management group level:

• Definitions – JSON policy logic describing compliance rules
• Initiatives – Bundled sets of policies for a common intent (e.g. Security Baseline)
• Assignments – Bind the definition or initiative to a specific scope
• Remediation – Automated correction of non‑compliant resources

A practical example of this is constraining Private DNS Zone creation. By assigning a policy that restricts DNS resource providers to only the Connectivity Management Group, we ensure network services remain centralised and consistent. This prevents application teams from spinning up ad‑hoc DNS zones that undermine cross‑environment name resolution — a subtle guardrail that pays big dividends later.

For Sovereign Landing Zones, these initiatives also incorporate regional membership, encryption requirements, and connectivity isolation patterns aligned with frameworks like IRAP (Australia) or FedRAMP (US).

🌏 Real‑World Impact

In large organisations, subscriptions proliferate quickly and with good intent — but without policy control, drift and inconsistency take hold fast.

Deploying ALZ policy assignments upfront ensures governance remains proactive. For example:

• Scenario: You need to ensure Private DNS Zones live only in the central Connectivity Zone.
  Outcome: The policy denies or remediates deployments of Microsoft.Network/privateDnsZones outside approved management groups — keeping name resolution consistent across the enterprise fabric.

• Scenario: The security team mandates encryption‑at‑rest for all storage.
  Outcome: A centrally enforced policy denies creation of unencrypted storage accounts, avoiding drift before it happens.

• Scenario: A financial institution operating under Australian data sovereignty constraints.
  Outcome: Using the Microsoft Sovereign Landing Zone baseline automatically ensures data only resides in the Australia East/Southeast region pair, maintaining integrity and compliance with IRAP standards.

When these controls are defined early and baked into your deployment pipelines, the platform team spends less time firefighting and more time improving developer experience.

💻 Implementation Examples

Deploy via Azure Portal

From the Azure Policy blade:

1. Navigate to Definitions → Policy Initiatives (set)
2. Select Assign Initiative at the top‑level management group
3. Choose the ALZ Policy Set (for example, AzureLandingZone-PolicySet-v3) or a Sovereign variant such as SovereignLandingZone-IRAP
4. Configure relevant parameters like allowedLocations, connectivityManagementGroupId, or logWorkspaceId

Select Review + Create to assign — Azure will begin evaluating and remediating resources automatically.

Deploy via Bicep

Here’s a minimal example for assigning a security or governance initiative:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

@description('Management group name for the policy assignment')
param mgName string = 'platform-connectivity'

@description('Policy initiative ID')
param initiativeId string = '/providers/Microsoft.Authorization/policySetDefinitions/AzureLandingZone-Connectivity-v3'

@description('Assignment display name')
param assignmentName string = 'Connectivity-Guardrails'

resource policyAssignment 'Microsoft.Authorization/policyAssignments@2022-06-01' = {
  name: assignmentName
  scope: tenantResourceId('Microsoft.Management/managementGroups', mgName)
  properties: {
    displayName: 'ALZ Connectivity Guardrails'
    policyDefinitionId: initiativeId
    parameters: {
      connectivityMG: {
        value: mgName
      }
    }
    enforcementMode: 'Default'
  }
  identity: {
    type: 'SystemAssigned'
  }
}

This initiative enforces connectivity‑scope controls — such as location restrictions, DNS zone centralisation, and mandatory diagnostic settings — across all workload subscriptions downstream of the connectivity management group.

⚠️ Gotchas & Edge Cases

• Timing matters: Policies often depend on existing platform resources such as Log Analytics or Defender plans. Deploy connectivity and identity layers first.
• Initiative drift: Modifying a single policy definition inside a standard initiative can cause inconsistencies. Always track initiative versions.
• Policy assignment identity: System‑assigned managed identities must have proper permissions, particularly for remediation tasks.
• Sovereign feature parity: Not all policy aliases are supported in sovereign clouds — validate definitions against your regulatory baseline matrix.

✅ Best Practices

• Apply initiatives at management group level, not per subscription, to reduce governance drift.
• Use parameterised initiatives for environment‑specific exceptions.
• Store your policy definitions and initiatives in source control alongside your IaC modules.
• Enable Azure Policy insights for continuous compliance reporting.
• Integrate Policy assignments and Security Baselines with Azure Pipelines or GitHub Actions for repeatable governance.
• Explicitly restrict resource types like Private DNS Zones to designated management groups or subscriptions.
• Extend ALZ guardrails using Sovereign Landing Zone modules if operating in regulated sectors.

🏛️ Extending Governance for SLZ and Regulated Environments

While most Enterprise ALZ deployments share a common governance baseline, Secure and Sovereign Landing Zones (SLZ) introduce additional depth around compliance validation, exemption management, and continuous monitoring.

1. Compliance and Regulatory Mapping
SLZ policies are frequently tied to frameworks such as IRAP (AU), ISO 27001, and NIST 800‑53. Each policy initiative maps to specific control families (identity, networking, audit, data protection). Integrating these mappings into Defender for Cloud’s Regulatory Compliance Dashboard provides automated evidence collection for audit teams.

2. Policy Exemption Governance
Even in regulated environments, exceptions happen — for example, legacy workloads or non‑supported services. SLZ governance patterns encourage time‑bound policy exemptions with recorded business justification, approval tracking, and optional remediation targets. This process can be automated using policy parameters and version control metadata.

3. Enhanced Monitoring and Audit Policies
SLZ reference guides go beyond standard ALZ diagnostics, enforcing activity log forwarding, resource diagnostic settings, and retention standards for key services such as Key Vault, Storage, and Firewalls.
Embedding those as part of your policy assignments (or deploying the Azure Monitor Baseline initiative) closes the observability gap and builds defence‑in‑depth.

Together, these enhancements ensure governance not only enforces configuration but also proves compliance — a must‑have for regulated sectors and government workloads.

📚 Learn More

• Azure Landing Zone Accelerator - Applications
• Azure Landing Zone Accelerator - Platform
• Azure Policy Documentation
• Sovereign Landing Zone Design
• Cloud Adoption Framework – Governance Design Area
• Deploy Policy Assignments with Bicep