Multi-Account Governance — Azure Administrator (AZ-104)
Policy at the wrong scope enforces nothing useful
The scenario asks you to block resource creation outside approved regions across 40 subscriptions. Candidates apply Azure Policy at the subscription level, repeating the assignment across each. That works — but the exam is testing whether you recognize Management Groups as the correct tool for cross-subscription policy inheritance. Applying policy at the Management Group scope eliminates redundant assignments and enforces the constraint at the organizational boundary where it belongs.
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
Assign the Azure Policy definition at the Management Group that contains only the production subscriptions, not at the Tenant Root Group and not individually at each subscription, so that policy inheritance eliminates redundant assignments while respecting the production-only blast-radius constraint.
Whether to assign an Azure Policy definition once at the management group scope—where it cascades automatically to all child subscriptions—or once per subscription, where the latter constitutes over-provisioning of administrative assignments that provides identical enforcement coverage at 20x the maintenance cost.
Assign a deny-effect Azure Policy definition at the Production management group scope — not at each subscription individually and not at the tenant root management group — so the single assignment inherits down to all 15 child subscriptions without over-scoping to non-production hierarchy siblings.
At which management hierarchy level to assign the Azure Policy definition: the Finance management group (correct — inherits to exactly 8 Finance subscriptions) versus the Tenant Root Group (scope overreach — cascades to all 14 subscriptions including Corporate) or individual subscription assignments (under-scoping — 8 separate assignments defeats least-effort constraint).
Whether to assign an Azure Policy (DeployIfNotExists, CanNotDelete lock) once at the Production management group scope — which cascades to all current and future child subscriptions automatically — or to apply Resource Locks manually at each individual subscription or resource group, which satisfies the current requirement but breaks the least-effort and forward-coverage constraints.
At which management hierarchy level should the Azure Policy assignment be scoped so that it covers all production subscriptions—including future ones—without cascading into development subscriptions, and without requiring per-subscription reassignment?
Select the Azure Policy assignment scope that precisely matches the stated compliance boundary — Production management group — rather than the Tenant Root Group (scope overreach that also captures dev and sandbox subscriptions) or per-subscription assignment (administrative burden that requires manual updates as subscriptions are added).
Domain Coverage
Difficulty Breakdown