Resources, resource groups, subscriptions and management groups

Four levels, four different jobs

A resource is the thing you actually create: a virtual machine, a storage account, a virtual network, a web app. Every resource lives in exactly one resource group, and a resource group is a management container for things that share a lifecycle. That is the whole idea behind it — deleting the group deletes everything inside it, so putting a project's resources in a group of their own turns "clean up the experiment" into a single action rather than a hunt.

A subscription is where billing and capacity meet. Usage inside it is accumulated and invoiced together, and quotas and limits apply per subscription, which is why a large estate that runs out of headroom gets more by adding a subscription rather than by asking for a bigger one. Splitting an estate along departmental or environmental lines is therefore not bureaucracy: it is how you get separate bills and separate capacity without reconstructing either from tags afterwards.

Above that, management groups exist for one purpose only — applying governance to many subscriptions at once. You cannot put a virtual machine in one. Every tenant gets a single root management group, every management group and every subscription has exactly one parent, and the result is a strict tree. The single-parent rule is load bearing rather than tidy: with two parents, an inherited policy and an inherited role assignment would have no unambiguous answer.

Inheritance runs downhill, and that is the design

A policy assignment or a role assignment made at a scope applies to everything beneath it: assign at a management group and it reaches every subscription under it, then their resource groups, then their resources. Nothing has to be repeated, and — the part questions turn on — nothing has to be remembered later, because a subscription created next quarter and placed under that management group inherits the assignment the moment it lands.

The working rule is to assign at the highest scope where the sentence you are enforcing is still true. "Only these regions are approved" is usually true for a whole department, so it belongs at a management group. "This team may read this one storage account" is true of exactly one resource, so it belongs there. Assigning too low is the mistake that looks correct on the day it is made and fails silently the first time somebody adds something.

The traps: a group's location, and what it cannot span

A resource group has a location of its own, and it is not gravity. It says where the group's own metadata is stored; the resources inside can sit in any region you like. Teams often do keep a group's resources in one region, because cross-region latency and egress charges are real, but that is a convention they chose. If you want it enforced, Azure Policy is how you impose it — there is no built-in restriction to lift, only one you can add.

Two shapes that do not exist and are offered as options anyway. A resource group cannot span subscriptions: it lives inside exactly one, and moving a resource to another subscription is a deliberate move operation rather than a shared group. And resource groups do not nest. What a group's location does buy you is one genuine failure mode worth knowing: an outage in that region can stop you managing the group even while the resources it lists are healthy elsewhere.

Reading the level out of the question

Almost every question on this lesson can be answered by finding the noun that names a level. "Delete everything this project created" is a resource group, because deleting the container deletes the contents. "Applies to subscriptions that do not exist yet" is a management group, because only inheritance covers the future. "Separate the bill" or "we have hit a quota" is a subscription. Tags are a reporting mechanism and turn up as a plausible wrong answer to the first of those — there is no delete-everything-with-this-tag operation, and anything created without the tag is silently missed.