Path 2 · Module 1 · Draft version C: Active recall
Design governance
How do you keep control of an Azure estate as it grows? With containers (management groups, subscriptions, resource groups), controls on them (tags, Azure Policy, RBAC), and a landing zone that sets it all up in code.
Reading once and moving on is why things fade after five minutes. This version makes you pull information out of your head, which is what makes it stay:
- Warm-up: guess the answers before you've read anything. Being wrong is fine; it primes your attention.
- Each unit gives three key ideas only. The rest is in "Go deeper"; open it when you want the detail.
- Say it back: close your eyes and explain the unit in two sentences, then write it with ✎ Note next to the heading.
- At the end: a one-page cheat sheet and flashcards. Come back to the flashcards tomorrow, in 3 days and in a week; the deck tells you which cards are due.
Warm-up · guess first
Answer each in your head. Don't look anything up. Open to check only after the module.
1. How many levels deep can a management group tree go?
Six (not counting the tenant root and the subscription level).
2. Do resources inherit the tags of their resource group?
No. Only with a policy such as "Inherit a tag from the resource group".
3. What's the default when no rule exists: Policy allows or denies? RBAC?
Policy: allow. RBAC: deny.
4. Can a virtual network span two subscriptions?
No. Connect them with peering or VPN.
5. What three subscriptions make up the platform landing zone?
Identity, Management, Connectivity.
Theory
1 · Design for governance
- Governance = staying in control of applications and resources: requirements, initiatives, priorities.
- Rules need a hierarchy: management groups → subscriptions → resource groups → resources, with the tenant root group on top.
- Anything assigned at a level is inherited by everything below it.
Go deeper
- Management groups manage access, policy and compliance across multiple subscriptions.
- Subscriptions are units of management and scale, and billing boundaries.
- Resource groups are logical containers you deploy and manage resources in.
- Resources are the instances: VMs, storage, SQL databases.
- The tenant root group contains all MGs and subscriptions; assignments there apply to the whole directory.
- The governance tools in this module: Azure Policy, tags and RBAC.
Why does structure come before rules? Explain it in two sentences, then write it down with ✎ Note.
2 · Design for management groups
- A management group exists because a set of subscriptions needs the same policies and access.
- Keep the tree flat (3–4 levels) under a top-level organisation MG; max depth is 6.
- Typical branches: by department or geography, plus production, sandbox, and an MG for sensitive data.
Go deeper
Use management groups to: limit regions across subscriptions; give access to many subscriptions with one role assignment; monitor and audit roles and policies across subscriptions; aggregate policy and initiative assignments.
Facts:
- Max six levels, excluding the root level and the subscription level. Up to 10,000 MGs per tenant.
- Each MG and subscription has one parent.
- New subscriptions go under the root by default; you can set a different default MG.
- RBAC authorization for MG operations isn't enabled by default (turn on hierarchy protection).
Design recommendations:
- Design with governance in mind: same security, compliance, connectivity and feature settings → same MG.
- Flat: no more than three or four levels; too many levels are hard to manage.
- Top-level MG for organisation-wide policies and role assignments.
- Organisational structure (Sales, Corporate, IT) or geographical structure (West, East) when compliance differs.
- Production MG for product-wide policies; sandbox MG for experiments, isolated from dev/test/prod.
- Isolate sensitive information (for example the corporate office) with standard and enhanced compliance policies.
Sketch, from memory, a management group tree for a company with three departments and a sandbox. Which MG gets the "allowed regions" policy?
3 · Design for subscriptions
- A subscription is a billing, management and scale boundary, and a policy boundary.
- Create a new one for separate Billing, Admins, Scale or Compliance ("BASC").
- Shared network goes in its own connectivity subscription; a VNet can't span subscriptions.
Go deeper
- Subscription types include Enterprise Agreement and Pay-As-You-Go. Each has limits and quotas.
- Use them to separate dev, test and production billing, meet different compliance standards, scale beyond one subscription's limits, and track costs per organisational unit.
Considerations:
- Treat subscriptions as a democratised unit of management, aligned with business needs.
- Group subscriptions with the same policies and roles under one MG (West and East under Sales).
- Dedicated shared services subscription for common network resources (ExpressRoute, Virtual WAN).
- Scale limits: large specialised workloads (HPC, IoT, SAP) in separate subscriptions.
- Administrative management: separate admins needed? If not, share (HR and Legal in one subscription).
- Policy assignment: isolate a PCI workload with a subscription instead of creating an MG for one or two subscriptions.
- Network topology: cross-subscription traffic needs peering or VPN.
- Owners: run access reviews quarterly or twice a year with Entra Privileged Identity Management.
What does "BASC" stand for? Give one real example for each letter.
4 · Design for resource groups
- Group resources that share a lifecycle: deployed, updated and deleted together.
- Two main strategies: by application or by type; usually a combination.
- The RG's region holds its metadata: if that region is down, resources run but can't be updated.
Go deeper
Use resource groups to: group by usage, type or location; organise by lifecycle; apply roles to a set of resources; protect resources with locks.
- Resources can be in other regions than their RG, and connect to resources in other RGs.
- Resources can be moved between RGs (with exceptions), added or removed at any time.
- RGs can't be nested or renamed; each resource is in exactly one.
| Strategy | Use when |
|---|---|
| By app (rg-app1, rg-app2) | All resources share policies and lifecycle; also test and prototypes. |
| By type (rg-sql, rg-web) | On-demand services not tied to one app. |
| Department, location, billing | Less common; when it fits how you manage. |
Check: lifecycle, administration overhead (central or decentralised admins?), access control (policies, roles, locks at RG level), compliance (metadata region).
Your app's web tier is redeployed weekly; its database lives for years. Same RG or not? Why?
5 · Design for resource tags
- Tags are name-value metadata on resources, RGs and subscriptions, and they're not inherited.
- Five types: Functional, Classification, Accounting, Partnership, Purpose ("FCAPP").
- Start small and enforce with Azure Policy; tags only work when consistent.
Go deeper
First decide the goal: search, automation, cost reporting? Align with the organisation's taxonomy (terms for compliance, cost, locations, confidentiality).
IT-aligned tagging tracks workload, application, function or environment and simplifies operations. Business-aligned tagging tracks accounting, ownership, cost responsibility and criticality, and shows business value. Many organisations are shifting towards business-aligned.
| Type | Examples |
|---|---|
| Functional | app = catalogsearch1, tier = web, env = production |
| Classification | confidentiality = private, SLA = 24hours |
| Accounting | department = finance, region = northamerica |
| Partnership | owner = jsmith, stakeholders = user1;user2 |
| Purpose | businessprocess = support, revenueimpact = high |
- Policy can require tags on new resources and re-apply removed tags.
- Not every resource needs every tag: only critical resources might have
impact. - Ask stakeholders for input.
Recite FCAPP and give one tag for each.
6 · Design for Azure Policy
- Policy controls the state of resources, whoever creates them; it's inherited and assigned at any scope.
- For a non-compliant resource you choose: deny, log (audit), alter (modify) or deploy something related; existing resources need a remediation task.
- Policy ≠ RBAC: Policy = what the result may be (default allow); RBAC = who may act (default deny). Use both.
Go deeper
- Definitions and initiatives (groups of definitions), many built in.
- Evaluates Azure and Arc-enabled resources; shows non-compliance; prevents and remediates; integrates with Azure Pipelines.
- Compliance dashboard: aggregated view, drill down, bulk remediation.
Evaluation triggers (expect some delay): resource created/updated/deleted in scope; new assignment; updated assignment; the standard 24-hour cycle.
| Handle non-compliance by… | Effect |
|---|---|
| Denying the change | Deny |
| Logging it | Audit / AuditIfNotExists |
| Altering the resource | Modify / Append |
| Deploying related resources | DeployIfNotExists |
If a user is allowed by RBAC to make a change, but the result is non-compliant, Policy still blocks it. Access lifecycle: no access → RBAC grants → Conditional Access verifies → Entra ID Protection monitors → access reviews confirm.
Name the four evaluation triggers, and the effect you'd use to fix a missing tag on existing resources.
7 · Design for role-based access control
- RBAC is an additive allow model: who (principal) + what (role) + where (scope); permissions sum up.
- Assign at the highest scope that meets the requirement, with least privilege, to groups, not users.
- Custom roles only when no built-in fits; shareable across subscriptions in the same Entra tenant.
Go deeper
Examples: one user manages VMs, another VNets; a DBA group manages SQL databases in a subscription; a user manages all resources in an RG; an application accesses an RG.
Steps: define role definitions → assign to users, groups, service principals → scope to MG, subscription, RG or resource. A scope-role matrix is a good planning tool.
Overlap: Contributor on the subscription + Reader on an RG = effectively Contributor on that RG. The Reader assignment has no effect.
| Azure Policy | Azure RBAC | |
|---|---|---|
| Focus | Resource properties | What users can access |
| Implementation | Rules | Roles + scopes |
| Default | Allow | Deny |
A user has Owner on RG-A and Reader on the subscription. What can they do in RG-B? Why?
8 · Design for Azure landing zones
- A landing zone is the foundation built before workloads arrive: network, identity, policy, monitoring ("utilities before houses").
- Platform landing zone (Identity, Management, Connectivity subscriptions) + application landing zones for workloads.
- Deploy it in code with the accelerator; for an existing estate, deploy in parallel in the same tenant.
Go deeper
- Landing zones are management groups and subscriptions designed to scale with business needs, with Azure Policy for continued compliance.
- The Azure landing zone IaC accelerator (Bicep or Terraform, using Azure Verified Modules) is the recommended route; a portal accelerator exists for organisations without IaC skills.
- Build in code and expect to refactor; a central IT team reviewing short- and long-term scenarios reduces that.
- Focus on applications rather than lifting and shifting VMs; prefer Azure-native services and follow the platform roadmap.
- Scope for both migration and greenfield, across the whole IT portfolio.
- Transition: deploy the accelerator in the same Entra tenant, with a new MG structure next to the existing one, then move subscriptions.
- Use the Azure landing zone review assessment to check your setup.
Explain a landing zone to a non-technical manager in one sentence, using the city analogy.
Cheat sheet
Everything in the module on one page. Print it (the flashcards and navigation are hidden when printing) or screenshot it.
- Root → MG → subscription → RG → resource
- Assignments inherit down
- Same rules for many subs
- Max 6 deep, aim for 3–4
- One parent; new subs → root (set default MG)
- Top-level · prod · sandbox · sensitive
- Billing · Admins · Scale · Compliance
- Shared connectivity sub
- VNet can't span subs
- Access reviews with PIM
- Group by lifecycle: by app or by type
- RG region = metadata; outage → can't update
- No nesting, no rename, one RG per resource
- Policies, roles, locks
- Functional · Classification · Accounting · Partnership · Purpose
- Not inherited
- Start small, enforce with Policy
- IT- vs business-aligned
- Resource state, default allow
- Deny · Audit · Modify · DeployIfNotExists
- Remediation task for existing resources
- Triggers: change · new/updated assignment · 24 h
- Who · what · where; default deny; additive
- Highest fitting scope, least privilege
- Groups, not users
- Custom roles: same tenant
- Utilities before houses
- Platform (Identity · Mgmt · Connectivity) + app LZs
- Code: accelerator (Bicep/Terraform, AVM)
- Existing estate → parallel, same tenant
Flashcards
Answer out loud, then check. Again brings the card back in this session; Good and Easy push it further out (1 → 3 → 7 → 21 days). Your progress is saved with your notes, so it's in your JSON export and cloud sync.
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.