Multi-Account Governance — Azure Solutions Architect (AZ-305)
Management Groups and Policy vs. Landing Zones
Applying consistent policy across existing subscriptions requires two things: a Management Group hierarchy to establish inheritance scope, and Azure Policy assignments attached at the appropriate level to propagate automatically. Azure Landing Zones provide something broader, the full scaffold including network topology, identity baselines, and policy configuration for net-new environments being built from scratch. When a scenario asks for enforcement on an estate that already exists, hierarchy plus Policy is sufficient. Landing Zones are the correct answer when the requirement is a governed foundation before workloads are deployed. Match scope to the requirement: retrofit versus greenfield is the first question to answer.
What This Pattern Tests
Azure governance questions test the management hierarchy: Management Groups > Subscriptions > Resource Groups > Resources. Azure Policy assigned at a Management Group applies to all child subscriptions — enforce tagging standards, restrict allowed regions, mandate encryption. For AZ-400, Azure DevOps project-level permissions control who can create pipelines, approve releases, and manage service connections, while Azure Policy ensures deployed resources comply with organizational standards. Blueprints (now superseded by deployment stacks) package policy assignments, RBAC roles, and ARM templates for repeatable environment provisioning. The trap is assigning policy at the subscription level when the requirement spans multiple subscriptions (use Management Groups), or using RBAC to enforce resource configuration (RBAC controls who can act, Policy controls what configurations are allowed).
Decision Axis
Governance scope determines the tool: hierarchy-wide = Management Groups + Policy, access control = RBAC, resource configuration = Azure Policy, environment provisioning = deployment stacks.
Associated Traps
Decision Rules
Whether to assign Azure Policy at the Management Group scope (single assignment, inherited by all child subscriptions) versus assigning Policy per subscription or delegating to Azure Blueprints, which provisions compliant environments but does not continuously enforce policy across already-deployed resources.
Whether to assign an Azure Policy initiative at the Management Group scope—inheriting enforcement to all child subscriptions automatically—versus deploying an Azure Blueprint per subscription or applying individual Policy assignments at each subscription, where the governing constraint is least-privilege continuous compliance with minimum administrative overhead.
Whether to assign an Azure Policy definition at the Management Group scope (single assignment, automatic inheritance, continuous enforcement) versus deploying Azure Blueprints to each subscription individually (per-subscription assignment, versioning overhead, and provisioning lifecycle that multiplies administrative burden across fifteen subscriptions).
Whether to assign a built-in RBAC Reader role once at Management Group scope—where inheritance propagates to all child subscriptions automatically—versus deploying Azure Blueprints artifacts to distribute role assignments across each subscription as a versioned, packaged environment artifact.
Whether to assign Azure Policy at the Management Group scope for persistent, continuously evaluated enforcement that auto-inherits to all current and future child subscriptions, versus deploying an Azure Blueprint containing a Policy artifact at the Management Group scope, which enforces the control only at provisioning time and does not re-evaluate compliance on existing resources.
Domain Coverage
Difficulty Breakdown