Episode 1 — The Lay of the Land — Tenants, Subscriptions, and the Four Levels of Scope

Before you can manage a single user or lock down a single virtual machine, you need the map. Over eleven episodes, this module walks the AZ-104 "identities and governance" domain — identities in Microsoft Entra ID (Part I), access with Azure RBAC (Part II), then governance and cost control (Part III) — and this first episode draws the terrain that every later episode builds on.

Learning objectives

• Distinguish the two planes of administration: the Microsoft Entra tenant (identities) and Azure resources managed through Azure Resource Manager.
• Name the four levels of management scope and explain how inheritance flows down them.
• Relate an Azure account, a subscription, and a Microsoft Entra tenant to one another.
• Decode a resource ID into its scope segments.
• Map the governance toolbox (RBAC, Policy, locks, tags, budgets) onto the scope levels where each tool applies.

Why it matters

The "Manage Azure identities and governance" domain weighs 20–25% of the AZ-104 exam, and almost every question in it boils down to at what level does this setting live, and what inherits it? In real administration the stakes are the same: assign a role or a policy one level too high and you widen the blast radius across an entire directory; one level too low and you repeat the work for every subscription. Learn the scope ladder once, and users, roles, policies, locks, tags, and budgets all snap into place.

Two planes of administration

Azure administration happens on two distinct planes that beginners constantly conflate.

The first is the Microsoft Entra tenant — the directory. It holds your identities: users, groups, licenses, and the Microsoft Entra roles (directory roles such as Global Administrator, User Administrator, and Billing Administrator) that govern who may create users, reset passwords, manage licenses, or manage domains. In the Azure portal, these roles live on the Roles and administrators page.

The second is the world of Azure resources — virtual machines, storage accounts, networks — managed through Azure Resource Manager (ARM), the deployment and management service for Azure. Authorization on this plane uses Azure RBAC, an authorization system built on ARM, and appears on the Access control (IAM) page of every management group, subscription, resource group, and resource.

The single most important ARM fact: every request goes through ARM. Whether you click in the Azure portal, run Azure PowerShell or Azure CLI, call the REST API, or use an SDK, Resource Manager receives the request, authenticates and authorizes it, then forwards it to the appropriate Azure service. Because all requests flow through the same API, you get consistent results and capabilities across all tools.

By default, the two planes don't overlap: a Global Administrator — all-powerful in the directory — has no access to Azure resources. The one built-in bridge is elevate access: a Global Administrator can flip the "Access management for Azure resources" switch and receive the User Access Administrator Azure role at root scope, over all subscriptions of the tenant — useful to regain access to a subscription, and the only default path to manage the root management group (below). Episode 8 returns to this in depth.

The four levels of scope

Azure provides four levels of management scope: management group → subscription → resource group → resource. Scopes are structured in a parent-child relationship, each level more specific than the one above — and the governing rule of the whole module is that lower levels inherit settings from higher levels. Apply a policy to a subscription and it applies to all resource groups and resources in it; assign a role on a management group and it inherits to every subscription beneath.

Management groups are a governance scope above subscriptions: conditions applied there cascade by inheritance to all associated subscriptions, and the subscription or resource owner cannot alter an inherited policy. One role assignment on a management group grants access to all subscriptions beneath it. A key constraint: all subscriptions within a single management group must trust the same Microsoft Entra tenant.

Every directory has a single top-level management group, the root management group — displayed as Tenant Root Group, with an ID equal to the tenant ID. It can't be moved or deleted, new subscriptions land there by default, everyone can see it, but no one has default access to manage it — only a Global Administrator who elevates access can, and anything assigned there applies to every resource in the directory, so keep root-level assignments "must have" only.

🧠 Mnemonic: The scope ladder, top rung to bottom: "Managers Sign, Resource Groups Receive" — Management group → Subscription → Resource Group → Resource. Picture settings as water poured on the top rung: they always flow down the ladder (inheritance), never up.

Scope has an address: the resource ID

Every scope is a slash-separated string — in the portal it appears as the Resource ID:

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

Cut the string shorter and you climb the ladder: /subscriptions/{subscriptionId} alone is subscription scope; add /resourceGroups/Example-Storage-rg for resource-group scope; keep going for a specific resource. Management groups use a different prefix: /providers/Microsoft.Management/managementGroups/{managementGroupName}. Limiting the scope limits what is at risk if a security principal is ever compromised — always a good exam answer and an even better production habit.

Account, subscription, tenant

Three words that sound interchangeable and aren't:

The must-remember sentence: a subscription trusts exactly one tenant (while one tenant can be trusted by many subscriptions). Historical note: subscriptions were once governed by classic administrator roles (Account/Service/Co-Administrator); these are retired — fully as of May 2026 — and Azure RBAC is the only current model. Episode 8 tells that story.

The ARM survival kit

A handful of ARM terms and behaviors recur throughout the module:

• A resource is any manageable item in Azure — VMs, storage accounts, web apps, databases, virtual networks. Resource groups, subscriptions, management groups, and tags are themselves resources.
• A resource group is a container for related resources that share the same lifecycle (deployed, updated, deleted together). Each resource lives in exactly one resource group, but resources in a group can be in different regions than the group — the group's location only says where its metadata is stored. Deleting a resource group deletes all resources in it, and each group supports up to 800 instances of a resource type (some types exempt).
• A resource provider is the service supplying a resource type — Microsoft.Compute supplies virtual machines, Microsoft.Storage supplies storage. You saw providers in the resource ID above.
• Declarative syntax — ARM templates (JSON) and Bicep files — lets you state what to deploy instead of scripting how; templates can target resource groups, subscriptions, management groups, or tenants.
• An extension resource adds capabilities to another resource — and the flagship example is a role assignment, which is why RBAC can attach to any scope. File that away for Episode 7.
• Concurrency: when two operations update the same resource simultaneously, ARM allows one to complete and blocks the others with a 409 error — updates stay conclusive and reliable.
• Resiliency: control-plane operations go to the global endpoint management.azure.com, distributed across regions and availability zones, independent of any single datacenter and never taken down for maintenance.

The governance toolbox, mapped onto scopes

Everything this module teaches is a setting applied at some rung of the scope ladder. Here is the season preview:

Notice the pattern: the higher you apply a tool, the wider it reaches — and two tools (locks, tags) stop short of management groups entirely. Keep this table handy; each row becomes a full episode.

Exercises

Exercise 1.1 — Map a fictional org onto the hierarchy

Contoso has two departments, Finance and Research, and each department runs a production and a development environment. Sketch a sensible layout of tenant, management groups, subscriptions, and resource groups. Where would you apply a policy that restricts allowed VM regions for everything Finance runs?

Exercise 1.2 — Read a Resource ID like a native

In the Azure portal, open any resource in a trial subscription (a storage account works well), find its Resource ID, and name the scope level of each segment.

/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/Example-Storage-rg/providers/Microsoft.Storage/storageAccounts/azurestorage12345

az role assignment list

Key takeaways

• Azure has two planes of administration: the Microsoft Entra tenant (identities, governed by Microsoft Entra roles) and Azure resources (governed by Azure RBAC through ARM) — no overlap by default; elevate access is the Global Administrator's bridge.
• Every request goes through ARM, which authenticates, authorizes, and forwards it — so portal, CLI, PowerShell, REST, and SDKs behave consistently.
• The four scope levels — management group → subscription → resource group → resource — form a parent-child hierarchy where lower levels inherit settings from higher levels.
• The root management group (Tenant Root Group, ID = tenant ID) can't be moved or deleted, receives new subscriptions by default, and is managed by no one until a Global Administrator elevates access.
• An account is the billing relationship; a subscription organizes access and billing and trusts exactly one tenant.
• A role assignment is an extension resource — the ARM mechanism that lets RBAC attach to any scope.
• Resource-group rules: same lifecycle, one group per resource, contents may span different regions, and deleting the group deletes everything in it.
• Concurrent updates to one resource end in a 409 error for all but one operation; the global endpoint management.azure.com keeps the control plane resilient.

Quick recall

Q: What are the four levels of management scope, top to bottom? A: Management group → subscription → resource group → resource; lower levels inherit settings from higher levels.

Q: What does Azure Resource Manager do with every incoming request? A: It receives the request from any tool (portal, CLI, PowerShell, REST, SDK), authenticates and authorizes it, then forwards it to the appropriate Azure service — one API, consistent behavior everywhere.

Q: Scenario: A region-restriction policy is assigned to the Corp management group. The owner of a subscription under Corp wants to opt out for a special project. Can they? A: No. Governance conditions applied at a management group cascade by inheritance, and the subscription or resource owner can't alter an inherited policy.

Q: A new subscription is created in the tenant. Which management group does it land in? A: The root management group (Tenant Root Group) — new subscriptions default there.

Q: Must resources share the region of their resource group, and how many groups can one resource belong to? A: No — resources in a group can be in different regions (the group's location is only metadata); and each resource belongs to exactly one resource group.

Q: Your Global Administrator complains they can't manage any Azure resources. Is something broken? A: No — Entra roles and Azure roles don't span by default. If needed, the Global Administrator can elevate access via "Access management for Azure resources" to gain User Access Administrator at root scope.

Coming up

Now that the terrain is mapped, we zoom into the identity plane. Episode 2 covers managing users in Microsoft Entra ID: the member/guest × internal/external user types, creating, inviting, deleting, and restoring users, profile management — and exactly which role you need for each move.