Subscriptions, Resource Groups & Management Groups
Azure's organisational hierarchy is how you structure billing, access, and governance at scale. Learn how subscriptions, resource groups, and management groups work together — and why getting this right matters for everything else.
Azure’s organisational hierarchy
Think of Azure’s hierarchy like a company’s filing system.
A management group is the cabinet. A subscription is a drawer. A resource group is a folder. And the actual resources (VMs, databases, storage) are the documents inside.
Why does this matter? Because permissions, policies, and budgets are set at each level and flow downward. Set a policy at the cabinet level, and it applies to every drawer, folder, and document inside. Set a budget on a drawer, and every folder in that drawer counts against it.
Subscriptions
A subscription is a billing and access boundary in Azure. Every Azure resource belongs to exactly one subscription.
Key facts:
- Each subscription trusts exactly one Entra ID tenant
- A subscription has an owner (an Entra ID account) and a billing account
- Subscriptions have limits (quotas) — e.g., max 980 resource groups per subscription
- You can have multiple subscriptions per tenant
- Resources cannot span subscriptions (but can communicate across them via networking)
Common reasons to create separate subscriptions:
- Billing separation — different departments, projects, or customers
- Access boundaries — isolate environments (Prod vs Dev)
- Quota limits — stay within Azure’s per-subscription limits
- Compliance — separate regulated workloads
Real-world: Meridian Financial's subscription strategy
Meridian Financial uses 12 subscriptions organised by business unit and environment:
- Finance-Prod, Finance-Dev, Finance-Test
- Insurance-Prod, Insurance-Dev, Insurance-Test
- Corporate-Prod, Corporate-Dev, Corporate-Test
- Shared-Services, Security, Sandbox
All 12 trust the same Entra ID tenant. RBAC is scoped per subscription — the Finance developers can’t touch Insurance resources. A management group sits above them all for company-wide policies.
Resource groups
A resource group is a logical container for resources that share a common lifecycle. When you delete a resource group, all resources inside it are deleted.
Rules to remember:
- Every resource must be in exactly one resource group
- A resource group can contain resources from different Azure regions
- A resource group has its own region (where its metadata is stored), but this doesn’t limit where resources can be deployed
- You cannot nest resource groups
- Resources can communicate across resource groups (within the same subscription)
Naming strategy matters:
rg-prod-webapp-uksouth— environment + workload + regionrg-dev-database-eastus— clear, scannable, consistent
| Feature | Subscription | Resource Group |
|---|---|---|
| What it is | Billing and access boundary | Logical container for related resources |
| Contains | Resource groups | Resources |
| Can be nested? | No (but management groups can) | No |
| Deleted = ? | All RGs and resources inside are deleted | All resources inside are deleted |
| RBAC scope? | Yes — roles apply to all RGs within | Yes — roles apply to all resources within |
| Limit | Depends on account type | 980 per subscription |
Management groups
Management groups sit above subscriptions in the hierarchy. They let you apply governance (policies and RBAC) across multiple subscriptions at once.
Key facts:
- Every tenant has a root management group by default
- Management groups can be nested — up to 6 levels deep (not counting root)
- A subscription can only be in one management group
- 10,000 management groups per tenant
- RBAC and Policy assigned at a management group are inherited by all child management groups and subscriptions
Root Management Group
├── IT Management Group
│ ├── Production Subscription
│ └── Development Subscription
├── Finance Management Group
│ ├── Finance-Prod Subscription
│ └── Finance-Dev Subscription
└── Sandbox Management Group
└── Sandbox SubscriptionExam tip: Management group access
By default, new management groups are created under the root management group. Only Global Administrators who have elevated their access (the toggle from Module 1) can manage the root management group initially.
The exam often tests: “Who can create management groups?” Answer: anyone with the Management Group Contributor or Owner role at the parent management group scope.
Moving resources
You can move resources between resource groups and subscriptions. This is a commonly tested scenario.
What you need to know:
- Not all resources support move — check Azure documentation per resource type
- Both source and target resource groups are locked during the move operation
- Moving a resource changes its resource ID
- RBAC and Policy at the new scope apply; old scope’s RBAC no longer applies
- Some resources can be moved across subscriptions; others only within the same subscription
- VMs can be moved (but all dependent resources like disks and NICs must move together)
Knowledge check
CloudFirst Labs has grown from 5 VMs to 50 and needs to separate billing for their customer-facing platform and internal tools. What should Alex recommend?
Meridian Financial wants to enforce a policy that prevents anyone from creating resources in the East US region across ALL their 12 subscriptions. Where should the policy be assigned?
Alex deleted a resource group called 'rg-test-webapp'. What happened to the three VMs, the storage account, and the SQL database that were inside it?
🎬 Video coming soon