Multi-Account Governance — Azure Security Engineer (AZ-500)
Policy Scope Determines Whether Compliance Scales or Drifts
Requirement: enforce diagnostic settings across sixty subscriptions owned by four business units with different regulatory requirements. Competing approaches: Azure Policy at management group level with exemptions, or per-subscription policy assignments. The deciding constraint is organizational scale. Per-subscription assignment works for five subscriptions; at sixty, it creates audit gaps. Management groups propagate policy down the hierarchy. The exam tests whether you can match governance scope to organizational reality.
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
Whether to assign an Azure Policy initiative at management group scope — covering all child subscriptions declaratively at standard pricing — versus enabling Microsoft Defender for Cloud enhanced security plans across all subscriptions to leverage its regulatory compliance assessment dashboard, which over-provisions capability and introduces per-resource premium billing not justified by a pure policy-enforcement requirement.
Whether to assign the Deny-effect Azure Policy definition at the Production management group scope (correct — inherits to all member subscriptions, excludes dev/test) versus escalating to tenant root management group (scope overreach — over-governs beyond the production-only boundary) or substituting Azure RBAC role assignments (wrong control plane — enforces access identity, not resource configuration state).
Whether to enforce key rotation compliance through Azure Policy assigned at management group scope (policy-plane, no marginal licensing cost, uniform coverage) versus enabling Microsoft Defender for Cloud's Key Vault protection plan (threat detection, per-subscription premium cost) or configuring per-vault Azure RBAC roles or vault access policies (data-plane access control, not rotation enforcement).
Azure Policy assigned at management group scope with a Deny effect targeting Key Vault instances where enableRbacAuthorization is false is the only control that prevents non-compliant vault creation and reconfiguration across all 15 subscriptions at a single enforcement point, satisfying both the authorization model requirement and the no-premium-licensing constraint — Defender for Key Vault must be eliminated because it adds per-vault threat-detection cost without enforcing the authorization model.
Domain Coverage
Difficulty Breakdown