Lesson 01 — Azure Resource Hierarchy

Why You Need to Understand This First

Everything in Azure — every policy, every RBAC role assignment, every network peering rule, every cost allocation — lives somewhere in a five-level hierarchy. If you do not have this hierarchy internalised, you will spend your entire Azure career making scope mistakes: applying a policy too broadly, assigning a role at the wrong level, failing to understand why a resource is or is not visible from a given context.

In production, this hierarchy is your governance model. In the exam, every scenario that mentions access control, policy, or resource management will implicitly test whether you know where in this hierarchy the action should happen.

The Five-Level Hierarchy

Azure organises every resource into a strict containment model. Each level inherits from everything above it.

Level 1 — The Tenant

A tenant is the top-level identity boundary in Azure. It maps 1:1 with a Microsoft Entra ID (formerly Azure Active Directory) instance. Every user, group, service principal, and managed identity lives in exactly one tenant.

Level 2 — Management Groups

Management groups are purely a governance container. They hold subscriptions (and other management groups). They have no billing impact. Their only purpose is to apply Azure Policy and RBAC at scale, across many subscriptions at once.

Limits you must know for the exam

Enterprise landing zone pattern

In real enterprise deployments, you will see a shallow hierarchy like this — never deep nesting:

Level 3 — Subscriptions

A subscription is the billing and scale unit in Azure. Every resource must live in exactly one subscription. Subscriptions have hard service limits — for example, 980 resource groups per subscription, or limits on vCPU quotas per region.

When to create a new subscription

This is a common architecture decision in enterprise environments:

Subscription types

Level 4 — Resource Groups

A resource group is the fundamental unit of deployment and lifecycle management in Azure. Every resource must belong to exactly one resource group. Resource groups are not a security boundary — they are an organisational and lifecycle container.

Key facts

• Resource groups have a location, but resources inside them can live in any Azure region — the resource group location only stores the metadata.
• Deleting a resource group deletes all resources inside it immediately and irreversibly (subject to soft-delete policies on individual services).
• RBAC applied at the resource group level is inherited by all resources inside it.
• Azure Policy assignments at the resource group level only affect that resource group (no downward children, since resources have no children).
• Resource groups cannot be nested.

Naming and grouping patterns

Enterprises use consistent naming conventions. Microsoft's Cloud Adoption Framework recommends a scheme like:

rg-<workload>-<environment>-<region>-<instance>
rg-payments-prod-eastus-001
rg-payments-dev-westus-001
rg-networking-shared-eastus-001

Level 5 — Resources

A resource is any Azure service instance: a VM, a storage account, a virtual network, a key vault, a function app. Resources are identified by a resource ID, which encodes the entire hierarchy:

/subscriptions/{subscriptionId}
  /resourceGroups/{resourceGroupName}
  /providers/{resourceProvider}
  /{resourceType}/{resourceName}

Example — a virtual machine resource ID:

/subscriptions/a1b2c3d4-1234-5678-abcd-ef1234567890
  /resourceGroups/rg-payments-prod-eastus-001
  /providers/Microsoft.Compute
  /virtualMachines/vm-payapi-prod-001

Resource providers

Resources belong to a resource provider (RP), which is the service namespace. Resource providers must be registered in a subscription before resources of that type can be created. Most common ones are auto-registered, but you may encounter this when using newer or less common services.

Scope: The Concept That Ties Everything Together

In Azure, scope is the specific point in the hierarchy where something is applied or measured. Scope is the answer to: "where does this permission/policy/budget take effect?"

Hands-On: Navigate the Hierarchy in the Portal

Open portal.azure.com and follow these steps to see the hierarchy in action. If you don't have a subscription yet, use the Microsoft Learn sandbox.

1. Find your Tenant ID: Search for Microsoft Entra ID in the portal. The Overview blade shows your Tenant ID and your primary domain. Copy the Tenant ID — you'll use it in later lessons.
2. Find Management Groups: Search for Management groups. If your tenant has never used them, you'll see only the Root Management Group. This is where you'll build the governance hierarchy in a real enterprise deployment.
3. Inspect a Subscription: Search for Subscriptions. Click on a subscription and look at the left menu — notice how RBAC (Access Control IAM), Policies, and Budgets all appear here. These are the subscription-level scope actions.
4. Inspect Resource Groups: Inside a subscription, browse Resource Groups. Click one. Notice the same left-menu pattern — Access Control (IAM), Policies — but now scoped to the resource group.
5. Find a Resource ID: Inside a resource group, click any resource → Properties → Resource ID. You should now be able to read this ID fluently and understand every segment of it.