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

Once you start using Azure, resources (VMs, storage, databases) quickly grow into the hundreds or thousands. To organize them and govern permissions and cost, Azure provides a four-level hierarchy: management group > subscription > resource group > resource. Higher levels group broader scopes; lower levels approach individual instances. Understanding this nesting lets you see "where to apply a rule (policy or permission) and how far it reaches."

2.2.1The four levels

1. Management group: the top-level container grouping multiple subscriptions. Apply policy and access control in bulk across the org or by division; can be nested.
2. Subscription: the billing and usage boundary and a logical container for resources. It is the unit for invoicing and quotas, often split by department or environment (prod/dev).
3. Resource group (RG): a container that groups related resources, managing permissions and lifecycle (e.g., delete together) as a unit. The group has a location for its metadata, but its resources may live in other regions.
4. Resource: the individual service instance—a VM, storage account, database, etc. Each belongs to exactly one resource group (never multiple).

2.2.2Scope and inheritance

Where this hierarchy pays off is scope and inheritance. Access control (RBAC) and Azure Policy can be assigned at any of the four levels and inherit (propagate) to everything below the level you assigned. For example, assign a "use only certain regions" policy at a management group, and it automatically applies to all subscriptions, resource groups, and resources beneath it. Broad rules go high, narrow rules go low—this is the basic governance strategy.

2.2.3Azure Resource Manager (ARM)

Azure Resource Manager (ARM) is the unified management layer that handles creating, updating, and deleting resources. Whether you enter via the Azure portal, Azure CLI, Azure PowerShell, SDKs, or ARM templates / Bicep, every request goes through ARM. That is exactly why consistent authentication, access control (RBAC), tags, and locks apply no matter which tool you use.

Another value of ARM is declarative templates (ARM templates in JSON, or Bicep, a more concise syntax). You write the "desired state" as code and apply it, and ARM realizes that state. The same template reproduces an identical environment any number of times, letting you manage configuration as code (IaC: Infrastructure as Code).

Note the governance tools ARM provides. Tags attach "key=value" labels to resources so you can classify and report across them by department, environment, cost center, and so on (useful for viewing cost across resource-group boundaries). Resource locks prevent mistakes by setting CanNotDelete or ReadOnly, guarding important production resources against accidental deletion or change. These can be set at the subscription, resource group, and resource levels and inherit downward.

In practice, deciding a naming convention and a tagging policy up front is the norm so you do not lose track of ever-growing resources. For example, a name like "env-app-region-type" and required tags (owner / costCenter / env) enforced by Azure Policy make later cleanup and cost allocation far easier.

2.2.4Section summary

• Hierarchy: management group > subscription > resource group > resource
• Subscription = billing/usage boundary; resource group = container (a resource belongs to one RG)
• RBAC/Policy inherit below the assigned level—broad rules high, narrow rules low
• ARM = the unified management layer for create/update/delete; codify environments with templates/Bicep (IaC)