Azure governance design for AZ-305
Azure governance design means choosing where controls are applied so that every current and future subscription inherits them. The rule for AZ-305 answers: put the control at the highest scope where it is true for everything beneath it, and use management groups, not repeated per-subscription assignments, to get there. Policy says what is allowed, RBAC says who may act, and the hierarchy decides how far each one reaches.
The scopes and what each one is for
Azure resources sit in four levels of scope, and every management group tree starts at a single root management group:
| Scope | Boundary for | Typical design question |
|---|---|---|
| Management group | Policy and access for many subscriptions | Which controls must every production subscription share? |
| Subscription | Billing, quotas and limits, a security boundary | One per workload, environment or business unit? |
| Resource group | Lifecycle of related resources | What is deployed and deleted together? |
| Resource | Single object | Rarely a design level |
Policy assignments and role assignments both inherit downwards. A resource or subscription owner cannot remove a policy assigned above them, which is the whole point of governing from the top. Tags are different: they label resources and can feed Policy conditions, but they are not an inheritance mechanism.
Facts about management groups worth memorising
From Microsoft Learn (management groups overview):
- Each directory has one root management group, named Tenant root group by default, with the same ID as the Entra tenant. It cannot be moved or deleted, and new subscriptions land in it by default.
- Nobody has access to the root by default. A Global Administrator can elevate access to manage it. Anything assigned there applies to the whole tenant, so keep it for “must have” controls only.
- A tree can be six levels deep (not counting the root or the subscription level), and a directory supports 10,000 management groups.
- Each management group and each subscription has exactly one parent. A subscription cannot inherit from two branches.
- All subscriptions in a management group must trust the same Entra tenant.
- A custom role can list only one management group in its assignable scopes, and custom roles with data actions cannot be assigned at management group scope.
Which tool answers which requirement
| Requirement wording | Use | Why |
|---|---|---|
| “Only these regions”, “all storage must use HTTPS” | Azure Policy, Deny effect | Controls configuration regardless of who deploys |
| “Report non-compliant resources but do not block” | Policy, Audit effect | Evaluates and reports only |
| “Add the tag or enable diagnostics automatically” | Policy, Modify or DeployIfNotExists | Changes or deploys; needs a managed identity for remediation |
| “Team X can manage VMs in these subscriptions” | RBAC at management group or subscription | Controls who, not what |
| “Nobody can delete this resource, even an Owner” | Resource lock | Blocks delete or change on the resource |
| “Stand up a compliant environment repeatedly” | Infrastructure as code (Bicep or ARM templates, template specs, deployment stacks), landing zone accelerators | Azure Blueprints (preview) is being retired, with a phased retirement from July 31, 2026 and final retirement on January 31, 2027; Microsoft points to deployment stacks and template specs instead |
Policy effects are evaluated in a fixed order: disabled first, then append and modify, then deny, then audit, auditIfNotExists and denyAction; deployIfNotExists runs after the resource provider has accepted the request. Several assignments on the same resource are all evaluated and the net result is cumulative and most restrictive, so a resource blocked by any one deny is blocked. Related deep dive: Azure Policy vs RBAC vs locks.
Worked example: a retailer with 40 subscriptions
Requirements: development, test and production environments in three countries; customer data must stay in the EU; production must deny public storage accounts; developers must not alter production; sandbox subscriptions for experiments need freedom; a central team runs networking.
A defensible design:
- Under the root, create one top-level management group for the organisation, and assign only the universal controls there: an allowed-locations policy for the EU regions and a diagnostic settings policy that sends logs to a central workspace (see Azure Monitor and Log Analytics).
- Split into Platform (connectivity, identity, management subscriptions, owned by the central team), Landing zones (workload subscriptions), Sandbox and Decommissioned.
- Under Landing zones, create Production and Non-production groups. Assign the Deny policy for public storage and a stricter initiative on Production only.
- Give developers Contributor on the non-production group and Reader on the production group.
- Give each sandbox subscription a budget alert and keep it outside the Production policies by placing it in the Sandbox group.
New subscriptions are placed in the right group, and inherit everything without any new assignment. The mistake to avoid is mirroring the org chart three levels deep; design around where controls differ, not around reporting lines.
Landing zones as AZ-305 asks for them
An Azure landing zone is Microsoft’s reference architecture for a multi-subscription environment. It has two parts (Cloud Adoption Framework):
- The platform landing zone: the management group hierarchy plus centralised services such as connectivity, identity, management and security monitoring, usually in dedicated subscriptions.
- Workload landing zones: the subscriptions where workload teams deploy, placed under a landing zones management group inside the guardrails of the platform. Older material calls these application landing zones.
The reference hierarchy separates Platform, Landing zones, Sandbox and Decommissioned. Under Landing zones, workloads are grouped by their connectivity needs, for example Corp for internal workloads, Online for internet-facing ones, and, in the current reference architecture, Local for Azure Local (hybrid) workloads. A repeatable process for handing out new workload subscriptions is called subscription vending. For the exam, the point is the separation: platform team owns the shared foundation, workload teams own their resources, and Policy at the management group level keeps them consistent.
Which exams test this
| Exam | How the topic appears | Where on this site |
|---|---|---|
| AZ-305 | Identity, governance and monitoring domain: recommend a structure of management groups, subscriptions and resource groups with a tagging strategy, a compliance solution, and how access to Azure resources is authorized | AZ-305 identity, governance and monitoring |
| AZ-104 | Identities and governance domain: implement Azure Policy, locks, tags, resource groups, subscriptions and management groups, and assign roles at different scopes | AZ-104 identities and governance |
| AZ-900 | Architecture and services domain: describe the hierarchy of management groups, subscriptions and resource groups, and RBAC. Management and governance domain: the purpose of Azure Policy, locks and tags | AZ-900 architecture and services and management and governance |
| SC-500 | Identity, access and governance domain: enforce security and regulatory compliance with Azure Policy, locks, role assignments and infrastructure as code. Covers the tools, not the management group design | SC-500 identity, access and governance |
For roles at different scopes, see Azure RBAC vs Entra roles.
How exam questions are built
- “New subscriptions must inherit automatically” means assign at a management group, not per subscription or per resource group.
- “Without affecting other environments” means find the lowest group that contains exactly the target subscriptions.
- Who versus what. If the stem says “prevent anyone from creating”, it is Policy. If it says “allow only the team”, it is RBAC. If it says “prevent deletion”, it is a lock.
- One parent only. Options that put a subscription under two management groups are distractors.
- Least privilege at the right scope. The correct role is the narrowest one at the highest scope that still covers the requirement.
- A policy assigned at the tenant root affects everything, so answers that assign experimental policies there are usually wrong.
Question 1. A company has 30 production subscriptions today and adds new ones every month. Every production subscription must deny the creation of storage accounts that allow public blob access. Sandbox subscriptions must not be affected. What should you recommend?
- A. Assign the policy to each production subscription individually
- B. Assign the policy at the tenant root management group
- C. Place the production subscriptions in one management group and assign the policy there
- D. Apply a CanNotDelete lock to each production subscription
Show answer
Answer: C
A management group containing only the production subscriptions with a Deny policy assigned to it covers existing and future subscriptions through inheritance, and leaves sandbox subscriptions outside it. Per-subscription assignments need manual work for each new subscription. Assigning at the tenant root would also hit the sandbox subscriptions. A resource lock does not control the configuration of new storage accounts.
Question 2. One subscription must receive the policies of the Production management group and also the policies of the Regulated management group. How should you meet the requirement?
- A. Add the subscription as a child of both management groups
- B. Create a second copy of the subscription in the Regulated group
- C. Tag the subscription with the names of both groups
- D. Keep one parent and assign the additional policy initiative directly to the subscription
Show answer
Answer: D
A subscription has exactly one parent management group, so it cannot inherit from two branches. Either assign the extra policies directly to that subscription, or structure the hierarchy so that Regulated sits under Production or vice versa. Adding the subscription to both groups is not possible. Duplicating the subscription is not a feature. Using tags does not inherit policy.