Organising Azure: resources, resource groups, subscriptions and management groups

Why this matters

An Azure environment that starts as a few test machines can grow into thousands of resources spread across teams, projects and countries. Azure gives you four levels to organise that growth: resources, resource groups, subscriptions and management groups. Each level is a place where you can set permissions, apply rules and read costs, and whatever you set at one level flows down to everything beneath it. Getting the structure right early saves a great deal of untangling later.

A finance manager needs it to get one invoice per department instead of a single bill nobody can split. A security lead needs it to grant read access to the whole estate in one step, rather than chasing every new subscription. A junior administrator needs it to understand why deleting one resource group removed an entire test environment, or why a virtual machine cannot be placed in a management group. Without the hierarchy, policies get applied one subscription at a time, gaps appear, and costs and access drift apart.

The lesson

Resources and resource groups

A resource is any manageable item you create in Azure: a virtual machine, a disk, a storage account, a virtual network, a database, a web app. If you can create it, configure it and delete it in Azure, it is a resource.

A resource group is a logical container for resources. It has no physical existence; it is a way of grouping things so they can be managed together. The rules are strict and worth learning exactly:

• Every resource belongs to exactly one resource group. A resource cannot exist without a group, and it cannot sit in two groups at once.
• Resource groups cannot be nested. One group cannot contain another.
• Resources can be moved. Most resources, including storage accounts and virtual machines, can be moved from one resource group to another without being recreated. If a storage account lands in the wrong group, you move it. Resource groups themselves cannot be renamed.
• A group can hold many types of resource. VMs, databases and networks can share a group.
• A group's location is only where its metadata lives. A resource group created in West Europe can hold resources in other regions. Nothing ties its contents to West Europe or to West Europe's paired region.
• Deleting a group deletes everything in it. The resources are not moved to a default group or left behind; they are gone.

That last rule is the main reason for the usual design guidance: put resources that share a lifecycle in the same group. If an app's web server, database and storage account are always deployed, updated and retired together, one resource group holding all three means one action can deploy them and one action can remove them. A test environment of VMs, disks and a virtual network built in one group can be cleaned up by deleting the group.

A resource group is also a scope for access and rules. A role or a policy assigned to a resource group applies to every resource in it, both the ones already there and any added later. Granting a user the Contributor role on a resource group gives them Contributor on everything inside, by inheritance. Lesson 11 explains role-based access control, and lesson 13 explains Azure Policy and resource locks.

Subscriptions

A subscription is a container for resource groups, and it is also two kinds of boundary:

• A billing boundary. Azure produces billing reports and invoices per subscription. A company that wants a separate invoice for each department gives each department its own subscription. Separate resource groups would all share one subscription's invoice. Lesson 12 covers cost management.
• An access control boundary. Permissions granted on one subscription do not reach another. Developers can have full control in a development subscription and no access at all to a production subscription.

So a common structure is one subscription per environment, such as development and production, which keeps both costs and access apart. Tags on resources help with reporting, but a tag on its own does not stop anyone reaching production.

Other facts about subscriptions:

• An account can have many subscriptions. Organisations use several to separate environments, departments or billing.
• Subscriptions are not regional. One subscription can deploy resources to any region it is allowed to use, and it can use availability zones. You do not need a new subscription to reach a new region.
• Subscriptions have limits and quotas. Some limits are set per subscription. When a workload reaches them, a further subscription is one way to work around the ceiling.
• Each subscription trusts exactly one Microsoft Entra ID tenant. The tenant is the directory that authenticates the users, groups and apps who can be given access to the subscription. One tenant can have many subscriptions, but a subscription cannot trust several tenants at the same time. Lesson 10 covers Microsoft Entra ID.

Each resource group is in exactly one subscription. A subscription can hold many resource groups, and a resource group can never span two subscriptions.

Management groups

Once an organisation has more than a handful of subscriptions, applying the same rule to each one becomes slow and error-prone. Management groups solve this. A management group is a container for subscriptions, and it can also contain other management groups.

• Policies and access set on a management group are inherited by every subscription beneath it, and by every resource group and resource in those subscriptions. An enterprise with forty subscriptions assigns one Azure Policy to a management group above them all, rather than forty separate assignments that would miss whatever is created next.
• Management groups can be nested. A company can build a Corporate management group with Production and Development groups beneath it, and subscriptions beneath each of those. Resource groups cannot do this, because they cannot be nested and cannot contain subscriptions.
• Each tenant has one root management group. It sits at the very top. Every other management group and subscription folds up to it. A role assigned at the root is inherited by everything beneath it, including subscriptions added next year. If a security team needs read access to every subscription in a large organisation, assigning the role at the root management group is the efficient way.
• One parent only. Each management group and each subscription has exactly one parent. A subscription cannot sit under two management groups at once, and so it never inherits from two groups.
• One directory. A management group hierarchy belongs to a single Microsoft Entra tenant, so every subscription placed in it must trust that same tenant. The subscriptions do not need to share a region or a payment method.
• Management groups hold only subscriptions and other management groups. You cannot deploy a virtual machine, or any other resource, directly into one. Resources always go into a resource group inside a subscription.

A practical example: a multinational wants every subscription used by its European teams to allow resources only in European regions. It places those subscriptions under a European management group and assigns an allowed-locations policy there. The rule then covers every European subscription, including ones created later. A "Europe" tag on each subscription would label them for reporting, but it would not stop a deployment to a region outside Europe.

How resource groups, subscriptions and management groups nest

From the broadest scope to the narrowest, the hierarchy is:

1. Management groups, starting from the single root management group, and optionally nested.
2. Subscriptions, each with one parent management group.
3. Resource groups, each in exactly one subscription.
4. Resources, each in exactly one resource group.

Inheritance flows down, never up. A policy assigned to a subscription applies to all its resource groups and the resources in them. It does not apply to the parent management group above it, or to any other subscription in the same tenant. A role assigned on a resource group reaches every resource in it, existing or new, but nothing outside that group.

A worked example. A company has a root management group, and beneath it a Corporate management group holding two more: Production and Development. The Production group holds two subscriptions, one for the online shop and one for internal systems. Inside the shop's subscription sit resource groups such as one for the web tier and one for the shared network, and inside each of those sit the actual resources. An auditors' read-only role assigned at the root reaches every one of those resources. An allowed-regions policy assigned to Production applies to both production subscriptions but not to anything under Development. A Contributor role given to the web team on the web tier's resource group reaches only the resources in that group. The finance team reads one invoice per subscription.

This is why the placement of an assignment is a design choice. Assign high, at a management group, for rules that should cover everything, such as allowed regions or a read-only role for auditors. Assign low, at a resource group, for permissions that belong to one team's project. Assigning at every resource individually is almost never the right answer.

What the exam is really asking

Questions in this area usually describe a requirement and ask which level fits. Match the need to the level:

• Separate invoices or separate quotas: a subscription.
• Apply one rule or role to many subscriptions, including future ones: a management group, and the root management group if it must cover everything.
• Deploy, manage and delete things together: a resource group.
• Build a nested Corporate, Production and Development structure: management groups.

The common traps are putting resource groups above subscriptions in the order, believing a resource can belong to two groups or that groups nest, thinking a resource group's location restricts where its resources go, assuming a subscription is tied to a region, and expecting a subscription to trust several Entra tenants or sit under two management groups. Remember that deleting a resource group deletes its contents, that a subscription is both a billing and an access boundary, and that inheritance only ever flows downward.