2.2 Azure Resource Hierarchy (Management Groups, Subscriptions, Resource Groups)

The Four Management Scopes

Azure organizes every deployment into four nested scopes. From top to bottom they are Management Groups → Subscriptions → Resource Groups → Resources. Each scope is a place where you can assign Azure Policy (rules) and Role-Based Access Control (RBAC) (permissions), and those assignments inherit downward to every child scope.

Level 1 — Management Groups

Management groups are containers above subscriptions used to apply governance across many subscriptions at once. Key limits the exam likes:

• A tenant (your Microsoft Entra directory) has exactly one built-in root management group; every subscription ultimately folds up to it.
• The tree nests up to six levels deep (this depth count excludes the root level and the subscription level).
• You can create up to 10,000 management groups per tenant.
• Each management group and subscription has exactly one parent, but a parent can have many children.

Use case: a bank creates a "Production" management group, assigns a policy that forces disk encryption, and every current and future subscription under it is automatically compliant — no per-subscription work.

Level 2 — Subscriptions

A subscription is two boundaries at once:

• Billing boundary — each subscription produces a separate invoice; you split subscriptions by department, environment, or project to track spend.
• Access and limit boundary — RBAC can be scoped here, and subscriptions carry quota ceilings (for example a default cap on vCPUs per region). Hitting a limit is often the reason to add another subscription.

Level 3 — Resource Groups

Resource groups (RGs) are logical containers for related resources. Memorize these rules:

Level 4 — Resources

A resource is a single manageable service instance: a VM, a storage account, a virtual network, a SQL database. It always lives inside one resource group.

Inheritance — the most-tested idea

Policy, RBAC, and tags assigned at a higher scope cascade to all children. Inheritance is one-directional.

Worked scenario

A company assigns a policy at the "Corp" management group that denies creation of any VM larger than Standard_D4s_v5. A developer in a subscription three levels below tries to deploy a Standard_D16s_v5 VM. The deployment is blocked — the deny policy was inherited all the way down. Moving the subscription to a management group without that policy would lift the restriction.

Trap 1: Inheritance flows down only. A tag set on one resource does NOT propagate up to its resource group.

Trap 2: "How many resource groups can a resource belong to?" — exactly one. Resources can be moved, never co-owned.

Trap 3: Which scope is the billing boundary? The subscription, not the resource group.

Why Organizations Use Multiple Subscriptions

Because a subscription is both a billing boundary and a limit boundary, splitting workloads across subscriptions is a common governance pattern. Three typical strategies appear in scenarios:

• Per environment — separate dev, test, and production subscriptions so a misconfigured dev resource can never affect production, and each environment's spend is isolated on its own invoice.
• Per department or business unit — IT, Marketing, and Finance each get a subscription, making chargeback and budgeting clean.
• Per limit ceiling — when a single subscription approaches a quota (such as the default vCPU cap in a region), adding another subscription raises headroom.

Resource Group Design in Practice

The golden rule for resource groups is shared lifecycle: put resources that you will create, update, and delete together into the same group. A three-tier web app — front end, API, and database for one project — belongs in one resource group so you can tear it all down in a single action when the project ends.

Because a resource group's region is only metadata (where its deployment record lives), a single group can legitimately hold a VM in East US and a storage account in West Europe. The group's location does not constrain where its resources run.

Tags Round Out Governance

Management scopes organize resources structurally; tags organize them logically across scopes. A tag is a name=value pair (for example environment=production, costCenter=marketing) attached to a subscription, resource group, or resource. Tags power cost reporting and can be required by Azure Policy — a policy can deny any resource that lacks a mandatory owner tag. Note that, unlike RBAC and Policy, tags applied to a resource group are NOT automatically inherited by the resources inside it (a frequent exam trick); you must apply or enforce tags at the resource level or use policy to inherit them.

One-line recap: Management group = governance across many subscriptions; subscription = billing + limits; resource group = lifecycle container; resource = the thing itself; and Policy/RBAC inherit downward while resource tags do not bubble up.