Multi-Account Governance — Azure Fundamentals (AZ-900)
Policy Scope, Identity, and Org Hierarchy Aren't Interchangeable
Requirement: enforce compliance controls across multiple Azure subscriptions belonging to separate business units. Competing choices: Management Groups for hierarchical policy scope, Azure Policy for rule definition and enforcement, Microsoft Entra ID for identity and access federation, Azure Landing Zones for prescriptive multi-subscription bootstrapping. The deciding constraint is scope level. A policy applied at the Management Group cascades to all child subscriptions. Entra ID governs identities — not resource configurations. Both matter; neither substitutes for the other.
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
More Top Traps on This Exam
Decision Rules
Choose Azure Policy over RBAC when the requirement is to enforce a resource configuration state across all subscriptions via inheritance, not to restrict which identities can perform actions on resources.
When the requirement is preventive, configuration-level compliance that propagates automatically across a subscription hierarchy, Azure Policy (policy inheritance) is the correct answer — RBAC addresses who can act, not what configuration resources must maintain.
Which service enforces a resource-deployment configuration rule at ARM scope across subscriptions versus which service governs data classification and lineage within the data estate.
Whether the immutable delete-prevention requirement — one that must hold regardless of the caller's RBAC role — is satisfied by a direct resource-lifecycle control or by a data-estate governance tool.
Which service enforces resource-deployment constraints (allowed regions) automatically across subscriptions versus which service governs the data estate through classification and lineage.
Use Azure Resource Locks (CanNotDelete) to enforce resource lifecycle protection on a specific resource, rather than Microsoft Purview, which governs data classification and lineage but cannot intercept ARM delete operations.
Domain Coverage
Difficulty Breakdown