Multi-Account Governance — Azure DevOps Engineer (AZ-400)
Policy Scope Determines Whether Management Groups or Policy Wins
Requirement: enforce a tag-inheritance rule across forty subscriptions owned by three business units, without disrupting subscription-level RBAC assignments. Competing approaches: apply Azure Policy at the management group level, or assign policies individually per subscription. The deciding constraint is scale and inheritance—management groups propagate policy assignments down the hierarchy automatically; per-subscription assignment creates drift at exactly the audit point the scenario is trying to eliminate. The organizational scope is the answer, not the policy definition itself.
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 split security and quality validation into two independently scoped Azure Pipelines environments with distinct approver groups and service connections, versus collapsing both approvals into a single shared environment with multiple required reviewers — which satisfies the surface 'two approvals' requirement but merges trust boundaries and eliminates independent auditability.
Whether to satisfy both approval requirements through a single shared pre-deployment gate backed by one service connection with broad Key Vault access, or to implement two environment-scoped gates each backed by a distinct least-privilege service connection — one scoped to QA quality validation with no Key Vault role and one scoped to Security with Key Vault Reader.
Whether to enforce independent, least-privilege-scoped Azure Pipelines environment gates with separate service connections and approval groups per trust boundary, or to consolidate security and quality approval into a single environment gate with a shared service connection and a multi-step approval chain to reduce gate count and pipeline configuration overhead.
Whether to implement performance and quality release gates as two independently scoped, separately auditable pre-deployment gates in Azure Pipelines — each with its own least-privilege service connection — versus consolidating both evaluations into a single composite gate backed by one broadly-permissioned service principal.
Enforce each release gate at the narrowest possible scope — one gate per organizational trust boundary, each with a dedicated least-privilege service connection — rather than consolidating both security and performance checks into a single subscription-scoped Defender for Cloud posture gate.
Domain Coverage
Difficulty Breakdown