Path 2 · Module 1 · Draft version A: Know → Decide → Recall
Design governance
Governance is how you keep control over an Azure estate as it grows: who may do what, which configurations are allowed, and who pays for it. In this module you design the containers (management groups, subscriptions, resource groups) and the controls you attach to them (tags, Azure Policy, RBAC), and you finish with the landing zone that puts it all together.
Every unit has the same five blocks, always in the same order, so your brain knows where to look:
- Gist: the unit in one sentence. If you remember nothing else, remember this.
- Know: the facts and limits. Decide: the design rules you apply to a scenario.
- Prose with the details and the reasons behind them.
- Exam trap: the thing AZ-305 likes to test.
- Recall: two questions. Answer them in your head before you open them. That small effort is what makes it stick.
The bar under each unit title shows where in the hierarchy the unit lives.
Theory
1 · Design for governance
- Four levels: management groups → subscriptions → resource groups → resources.
- The tenant root group sits above everything, one per Entra tenant.
- Policies and role assignments flow down.
- Ask "who else needs the same rule?" The answer is the level where you assign it.
- Design the hierarchy before the first workload arrives.
Governance is the set of mechanisms and processes that keep you in control of your applications and resources in Azure. It starts with deciding your requirements and priorities: which regions are allowed, how costs are split, which data must stay where, who can change production.
To apply those rules exactly where they're needed, you need a structure. Azure gives you four levels:
- Management groups manage access, policy and compliance for multiple subscriptions.
- Subscriptions are units of management, billing and scale.
- Resource groups are logical containers you deploy and manage resources in.
- Resources are the instances: VMs, storage accounts, databases.
Above them all sits the tenant root group. It contains every management group and subscription, so a policy or role assignment there applies to the whole directory.
"Apply this to all subscriptions, including future ones" → a management group, not a script that loops over subscriptions. Future subscriptions inherit automatically when they're placed under it.
Name the four levels, top to bottom, and what sits above them.
Management groups, subscriptions, resource groups, resources. The tenant root group sits above all of them.
Why design the hierarchy first?
Because governance is attached to levels. Without a structure you can only assign rules one subscription or resource at a time, and you miss the ones created later.
2 · Design for management groups
- Up to 6 levels deep (not counting the root and the subscription level).
- Up to 10,000 management groups per tenant.
- Each MG and subscription has exactly one parent.
- New subscriptions land under the root by default (you can change the default MG).
- RBAC authorization for MG operations is not on by default: turn on hierarchy protection.
- 3–4 levels is plenty.
- One top-level MG for organisation-wide rules (not the root itself).
- Split by department or by geography when rules differ.
- Add a production MG, a sandbox MG, and isolate sensitive workloads.
A management group is a container for subscriptions (and other management groups). Its job is to let you write a rule once for many subscriptions. Typical uses:
- Limit the regions where VMs can be created, across all subscriptions in the group.
- Grant access to many subscriptions with one role assignment.
- Monitor and audit role and policy assignments across subscriptions.
The design recommendations all come back to one idea: a management group exists because a set of subscriptions needs the same governance. If two branches would get exactly the same policies and roles, they probably shouldn't be two branches.
- Keep it reasonably flat. Three or four levels give flexibility without becoming hard to reason about. Every extra level is another place a rule could hide.
- Use a top-level management group under the root (for example "Contoso") for organisation-wide policies and role assignments. Assigning at the tenant root itself is possible but harder to test and to move away from.
- Organisational or geographical structure: separate Sales, Corporate and IT if they have different rules; separate regions (West, East) when compliance differs per region.
- Production MG for policies that apply to all production workloads.
- Sandbox MG where people can experiment, isolated from dev, test and production, with looser rules but tight budgets.
- Isolate sensitive data in its own MG with standard and enhanced compliance policies.
The 6-level limit doesn't count the root or subscriptions. And a subscription can't be in two management groups; if two teams both "own" one, the design is wrong, not the limit.
A new subscription is created. Where does it end up, and why can that be a governance gap?
Under the tenant root group (unless a default management group is set). It then misses the policies of your top-level MG, so set a default MG and turn on hierarchy protection.
Give three management groups almost every design should have.
A top-level organisation MG, a production (or landing zones) MG, and a sandbox MG. Isolating sensitive workloads is the common fourth.
3 · Design for subscriptions
- Subscription types: Enterprise Agreement, MCA, Pay-As-You-Go, …
- Each has limits and quotas, so it's also a scale unit.
- A VNet can't span subscriptions; connect with peering or VPN.
- Policy and RBAC can be assigned at the subscription too.
- New subscription when you need: separate billing, separate admins, separate compliance, or more scale.
- Put subscriptions with the same rules under the same MG.
- A dedicated shared services / connectivity subscription.
- Big specialised workloads (SAP, HPC, IoT) in their own subscription.
You can't use Azure without a subscription: it's the container you create and pay for resources in. Because it's also a boundary for limits, access and policy, it's the main tool for separating things: dev from test from production, one department's costs from another's, a PCI workload from everything else.
The design considerations, each with the question to ask:
- Treat subscriptions as a democratised unit of management. Align them with business needs and priorities, not just with IT teams.
- Group under management groups. The West and East sales subscriptions both inherit from the Sales MG.
- Dedicated shared services subscription. Common network resources (ExpressRoute, Virtual WAN, hub VNet) are billed together and isolated from workloads.
- Scale limits. Every subscription has resource limits. Large, specialised workloads (HPC, IoT, SAP) get their own subscription so they don't eat into everyone else's quota.
- Administrative separation. Do these teams need different administrators? If not, one subscription can serve both (HR and Legal could share one).
- Policy boundary. A PCI workload needs extra policies. You can isolate it with a subscription instead of creating yet another management group for one subscription.
- Network topology. Workloads that talk a lot need peering or VPN across subscriptions; factor that in.
- Owner responsibilities. Make subscription owners aware of their role and run access reviews (quarterly or twice a year) with Entra Privileged Identity Management.
"Minimise the number of management groups" + one workload needs extra compliance → isolate it with its own subscription under an existing MG, and assign the extra policy at that subscription.
Two departments share one VNet today. You split them into two subscriptions. What breaks, and what's the fix?
A VNet belongs to one subscription, so one department's resources leave it. Connect the two VNets with VNet peering (or a hub-spoke via a connectivity subscription).
Which tool reviews subscription owners' access every quarter?
Access reviews in Microsoft Entra ID Governance / Privileged Identity Management.
4 · Design for resource groups
- An RG has a region where its metadata lives.
- That region down → you can't update its resources (they keep running).
- Resources can be in other regions than their RG.
- No nesting, no renaming, one RG per resource.
- Resources can talk across RGs and move between them (with exceptions).
- By app when resources share policies and lifecycle.
- By type for shared services not tied to one app.
- By department, region or cost centre only when it helps.
- Usually a combination.
- Need RG metadata in a specific region? Pick the RG's region for compliance.
Resource groups are the containers you deploy into. You use them to:
- Group resources of similar usage, type or location.
- Organise by lifecycle, so you can create or delete everything at once.
- Apply role permissions to a set of resources.
- Protect resources with locks (CanNotDelete, ReadOnly).
Two main strategies, with an example of two applications (App1 and App2), each with a web service, a SQL database, VMs and storage:
| Strategy | Example | Use when |
|---|---|---|
| By application | rg-app1 holds App1's web app, database, VMs and storage | Resources share the same policies and lifecycle. Also good for test and prototype environments. |
| By type | rg-sql for all databases, rg-web for all web services | On-demand or shared services that aren't tied to one app, often run by a central team. |
| By department, region, cost centre | rg-finance, rg-weu | Less common; only when it matches how you manage or bill. |
Then check the design against four questions: lifecycle (deployed and deleted together?), administration overhead (how many RGs can your admins handle, central or decentralised?), access control (policies, roles and locks at RG level) and compliance (where must the metadata live?).
"The resource group's region has an outage. Can users still reach the VMs in another region?" Yes: the resources run. But you can't change them until the RG's region is back, because the metadata is unavailable.
What's the one question that decides most resource group designs?
"Do these resources share a lifecycle?" If they're deployed, updated and deleted together, they belong in the same resource group.
Name three things you can't do with a resource group.
Nest it, rename it, or put one resource in two of them.
5 · Design for resource tags
- A tag is a name-value pair:
env = production. - On resources, resource groups and subscriptions; up to 50 per item.
- Tags on an RG are not inherited by its resources.
- Set them with the portal, CLI, PowerShell, ARM/Bicep or REST.
- Start with the goal: cost reporting? automation? search?
- Follow the organisation's taxonomy.
- IT-aligned, business-aligned, or both.
- Start with a few tags, then grow.
- Enforce with Policy (require, add, inherit).
Before any tagging project, decide what you want to achieve: better cost reports, automation that targets env = dev, or finding owners quickly. Then align tag names with terms the business already uses for cost and compliance.
IT-aligned or business-aligned? IT-aligned tags track workload, application, function or environment; they make operations easier ("our five colour printers are busy 80% of the time, buy more"). Business-aligned tags track ownership, cost responsibility and criticality; they show value ("marketing's brochures raised revenue 10%, invest in printing"). Many organisations are moving towards business-aligned tagging, usually combined with a few IT tags.
| Tag type | Answers | Examples |
|---|---|---|
| Functional | What does it do in the workload? | app = catalogsearch1, tier = web, env = production |
| Classification | How is it used and protected? | confidentiality = private, SLA = 24hours |
| Accounting | Who pays? | department = finance, program = business-initiative, region = northamerica |
| Partnership | Which people (outside IT) are involved? | owner = jsmith, contactalias = catsearchowners |
| Purpose | Which business function and value? | businessprocess = support, revenueimpact = high |
Two last rules. Not every resource needs every tag: if only mission-critical resources carry impact, an untagged resource simply isn't mission-critical. And ask stakeholders across the organisation for input, or finance will report on tags nobody fills in.
"Resources must automatically get the costcenter tag of their resource group" → tags don't inherit by themselves. Use the built-in policy Inherit a tag from the resource group (Modify effect), plus a remediation task for existing resources.
Which tag type is owner = jsmith? And department = finance?
Partnership. Accounting.
Why start with only a few tags?
Tags only work if everyone applies them consistently. Prototype a few critical ones, check they're used and useful, then add more.
6 · Design for Azure Policy
- Policy definitions, grouped into initiatives; many are built in.
- Assigned at a scope (MG, subscription, RG), inherited down.
- Evaluates Azure resources and Arc-enabled resources.
- Can prevent and remediate; integrates with Azure Pipelines.
- Default for anything without a policy: allowed.
- Broad rules high (production MG), app-specific rules low (RG).
- Choose the effect per rule: deny, audit, modify, deploy.
- Plan remediation, especially for tags.
- Use the compliance dashboard for the overall picture.
- Use Policy and RBAC together.
Azure Policy lets you create, assign and manage rules that keep resource configurations in line with company standards. Some policies go on the production management group (for example "only these regions"); others go on an application's resource group (for example "only these VM sizes").
When does Policy evaluate?
Evaluation isn't instant everywhere, so plan for a delay in seeing non-compliance. It's triggered when:
- a resource is created, updated or deleted in an assigned scope;
- a policy or initiative is newly assigned;
- an existing assignment is updated;
- the standard compliance cycle runs, once every 24 hours.
What happens to a non-compliant resource?
You choose per rule. The options map to policy effects:
| You want to… | Effect |
|---|---|
| Block the change | Deny |
| Log it, but allow | Audit, AuditIfNotExists |
| Alter the resource (add or fix a property or tag) | Modify, Append |
| Deploy a related resource (diagnostic setting, agent) | DeployIfNotExists |
For resources that already exist, Modify and DeployIfNotExists need a remediation task; new resources are fixed automatically. Tagging is the classic case: Policy can add a tag and re-add it when someone removes it.
Policy vs RBAC
They're different and you need both. RBAC controls user actions: who can do what, where. Policy controls the resulting state, regardless of who does it. If a user has permission to create a VM, but the VM would be non-compliant, Policy still blocks it.
Policy is one step in the access lifecycle: a user starts with no access, gets it through RBAC, it's verified with Conditional Access, monitored by Entra ID Protection, and confirmed periodically with access reviews.
"Ensure existing resources become compliant" → assigning a Modify / DeployIfNotExists policy isn't enough; you also need a remediation task (with a managed identity on the assignment).
List the four triggers for a policy evaluation.
Resource created/updated/deleted in scope; new assignment; updated assignment; the 24-hour compliance cycle.
A Contributor creates a storage account with public access. Policy denies public access. What happens?
The deployment is blocked. RBAC allowed the action, but Policy evaluates the resulting state and denies it.
7 · Design for role-based access control
- Role assignment = who (principal) + what (role definition) + where (scope).
- Default: everything denied until a role allows it.
- Permissions add up across assignments.
- Custom roles can be shared by subscriptions that trust the same Entra tenant.
- Define roles → assign to principals → set the scope.
- Highest scope that meets the need; no higher.
- Least privilege; separate duties.
- Assign to groups, not users.
- Custom role only when no built-in role fits.
Azure RBAC evaluates every request and decides whether it's allowed. It's an allow model: a role lists what you may do, and anything not listed isn't allowed. Reader on a resource group lets you read; to write, a role must explicitly allow writes.
Typical scenarios: one user manages VMs in a subscription while another manages VNets; a DBA group manages all SQL databases; a user manages everything in one resource group; an application (through its identity) accesses all resources in a resource group.
Planning steps: (1) decide the role definitions you need, (2) assign them to users, groups and service principals, (3) scope them to a management group, subscription, resource group or resource. A scope-role matrix (rows: teams; columns: scopes; cells: roles) is a good design artefact.
Overlapping assignments are summed. Contributor on the subscription plus Reader on one of its resource groups = effectively Contributor everywhere in that subscription; the Reader assignment adds nothing.
| Azure Policy | Azure RBAC | |
|---|---|---|
| What it is | Rules that keep resources compliant | Fine-grained authorization system |
| Focus | Properties of resources | What users can access and do |
| You implement it by | Defining and assigning rules | Assigning roles at scopes |
| Default | Allow | Deny |
"Grant the minimum permissions" with a built-in role that's too broad → a custom role, scoped as low as possible. "Minimise administrative effort" with many users → assign roles to a group.
User has Owner on RG-A and Reader on the subscription. What can they do in RG-B?
Only read. Permissions add up, but the Owner role applies to RG-A only.
Where can a custom role be reused?
In any subscription that trusts the same Microsoft Entra tenant (listed in the role's assignable scopes).
8 · Design for Azure landing zones
- Platform landing zone: identity, connectivity, management subscriptions, run centrally.
- Application landing zones: one or more per workload (dev, test, prod).
- Policies keep it compliant.
- Provisioned through code: the IaC accelerator (Bicep or Terraform with Azure Verified Modules); a portal accelerator exists too.
- Include landing zones in every enterprise design.
- Build them in code, expect to refactor.
- Start from the accelerator.
- Focus on applications, Azure-native services.
- Scope for migration and greenfield.
- Existing estate? Deploy the new hierarchy in parallel, same tenant.
Think of a new neighbourhood: water, gas and electricity are in place before the houses are built. A landing zone does the same for workloads: network, identity and access, policies and monitoring are active before the first application lands, so every migration doesn't have to reinvent them.
Technically, a landing zone is a set of management groups and subscriptions designed to scale with business needs. The reference architecture has a Platform branch (Identity, Management, Connectivity subscriptions) and a Landing zones branch (for example Corp for internal apps, Online for internet-facing apps, and specialised ones like SAP), plus Sandbox and Decommissioned. Chapter 11 of path 1 built exactly this tree.
Design considerations:
- Include landing zones in the overall design: subscriptions as the unit of scale, policies as guardrails for platform and apps.
- Create them through code and iterate. Have a central team review both short- and long-term scenarios to limit refactoring.
- Use the Azure landing zone accelerator for a full, opinionated implementation of management groups and policies.
- Focus on applications, not on lifting and shifting VMs.
- Be Azure-native and follow the platform roadmap, so new capabilities become available.
- Scope for migration and greenfield, across the whole IT portfolio, not just the first wave.
- Transition existing architectures by deploying the accelerator into the same tenant in parallel, with a new management group structure that doesn't disturb what runs today. Then move subscriptions over.
Microsoft offers an Azure landing zone review assessment to check an existing setup or find where to invest.
"Adopt landing zones without disrupting the existing environment" → deploy the new MG hierarchy alongside the old one in the same Entra tenant, then migrate subscriptions. A new tenant is not the answer.
What are the three platform subscriptions?
Identity, Management, Connectivity.
What's the recommended way to deploy a landing zone?
The Azure landing zone IaC accelerator (Bicep or Terraform with Azure Verified Modules). The portal accelerator is the option without IaC skills.
One-page summary
| Level / control | It's a boundary for… | Create a new one when… |
|---|---|---|
| Management group | Policy and access across subscriptions | A set of subscriptions needs different governance |
| Subscription | Billing, scale, administration, policy | You need separate Billing, Admins, Scale or Compliance |
| Resource group | Lifecycle, access, locks | Resources have their own lifecycle |
| Tags | Metadata: cost, owner, purpose (not inherited) | A report or automation needs it; enforce with Policy |
| Azure Policy | Resource state (default allow) | A rule must hold for everything in a scope |
| RBAC | User actions (default deny, additive) | A group needs to do something at a scope |
| Landing zone | The whole foundation, in code | Always, before workloads arrive |
Module assessment
1. All current and future subscriptions in the company may only use EU regions. Where do you assign the policy?
C. A management group assignment is inherited by every subscription under it, including new ones.
2. One application processes card payments and needs extra PCI policies. You want as few management groups as possible. What do you do?
B. A subscription is a policy boundary too, so it isolates the workload without another MG.
3. Resources must carry their resource group's costcenter tag, including resources that already exist. What do you use?
D. Tags don't inherit. The Modify policy fixes new resources; a remediation task fixes existing ones.
4. A user is Contributor on a subscription and Reader on one resource group in it. What can they do in that resource group?
A. RBAC is additive. Contributor from the subscription still applies.
5. The region of a resource group has an outage. Its VMs run in another region. What's true?
C. The RG's metadata is unavailable, so management operations fail; the resources themselves keep working.
6. A company with an existing Azure estate wants landing zones without disrupting running workloads. What do you recommend?
B. A new MG structure next to the existing one, in the same tenant, doesn't affect current workloads.
Design exercise
Larkspur Health runs three hospitals in the Netherlands and one clinic in Belgium. Requirements:
- All patient data must stay in EU regions. The Belgian clinic has an extra national rule: its data must stay in Belgium Central.
- Finance wants costs per hospital and per application.
- Three applications: the patient portal (internet-facing), the internal HR system, and a research platform that needs large GPU quotas.
- Each application has dev and prod. Developers must be able to try new services without risk to production.
- A central platform team runs the network (ExpressRoute to the hospitals) and identity. Application teams must not change the network.
- Minimise administrative effort.
-
Task
Design the management group hierarchy
Draw the tree from the tenant root down to (but not including) subscriptions. Write next to each management group why it exists.
Done when- The tree has at most 4 levels below the root.
- Every management group has a governance reason (a policy or access rule that differs from its siblings).
- There's a place for experiments that's isolated from production.
Hint
Start from the landing zone reference architecture (Platform, Landing zones, Sandbox, Decommissioned). Which requirement is different for the Belgian clinic?
Model answer
- Larkspur (top level): Allowed locations = EU regions; required tags; Defender for Cloud.
- └ Platform: only the platform team has write access.
└ Identity · Management · Connectivity. - └ Landing zones: deny changes to the hub network for app teams; diagnostics to the central workspace.
└ Corp (internal: HR, research): deny public IPs.
└ Online (patient portal): WAF in front of public endpoints. - └ Sandbox: no ExpressRoute connectivity, budget alerts, looser service list.
- └ Decommissioned.
The Belgian rule applies to the clinic's subscriptions (an extra Allowed locations assignment), not a separate geographic MG, since it's one rule for a few subscriptions. Splitting by hospital isn't needed: hospitals differ in cost, not in governance, and tags solve cost.
-
Task
Decide subscriptions and resource groups
List the subscriptions and, for one application, its resource groups. Give the "BASC" reason for each subscription.
Done when- Dev and prod are separated.
- The GPU-heavy research platform doesn't share quota with others.
- The network has its own subscription.
Model answer
sub-connectivity(Admins + Billing: ExpressRoute, hub VNet),sub-identity,sub-management(Log Analytics, automation).sub-portal-prod,sub-portal-devunder Online (Compliance: internet-facing rules).sub-hr-prod,sub-hr-devunder Corp.sub-research-prod,sub-research-devunder Corp (Scale: GPU quota).sub-sandbox-*per team under Sandbox.- For the patient portal (prod):
rg-portal-web,rg-portal-data,rg-portal-monitor; grouped by lifecycle (data lives longer than the web tier).
-
Task
Attach tags, policies and roles
Make a table: requirement → control → scope, for every requirement in the scenario.
Done when- Each requirement maps to Policy, RBAC, tags, or a structure choice.
- Roles are assigned to groups, at the highest scope that fits.
- Cost per hospital is possible even for shared resources.
Model answer
Requirement Control Scope EU only Policy: Allowed locations (Deny) Larkspur MG Belgium Central for the clinic Policy: Allowed locations (Deny), narrower Clinic subscriptions Cost per hospital and app Tags hospital,app,env(accounting/functional); Policy: require on RG + inherit to resourcesLanding zones MG App teams can't change the network RBAC: Network Contributor only for the platform group; app groups get Contributor on their own subscriptions Connectivity subscription / app subscriptions Safe experiments Sandbox MG + budget alerts, no peering to hub Sandbox MG Minimise effort Landing zone accelerator in code; groups instead of users Whole tenant
- You can explain what each level of the hierarchy is a boundary for, and when to create a new one.
- You can choose between Policy, RBAC and tags for a requirement, and pick the scope.
- You can describe a landing zone and how to adopt one next to an existing estate.