D2 · Architecture and Services

Azure resource hierarchy

, , , , and Resources — the structure that organizes everything in Azure. Understanding it means understanding billing, access control, and governance.

Complete Azure hierarchy

Top to bottom — each level contains the next and inherits policies and permissions from the level above.

01

Tenant

Entra ID directory

An instance of Microsoft Entra ID (formerly Azure Active Directory). Represents your organization. A domain like contoso.com. Everything else lives inside the tenant.

Key for the exam

One company = 1 tenant (normally). The highest boundary of your Azure universe.

02

Root Management Group

Automatic root

The root Management Group, created automatically when you activate Azure. Contains all the tenant's Management Groups and Subscriptions. Applying a policy here = affects EVERYTHING.

Key for the exam

Only the tenant's Global Administrator can manage the Root MG.

03

Management Groups

Up to 6 levels deep

Containers for subscriptions used to apply governance at scale. Policies and permissions inherit downward. Maximum 6 levels of hierarchy. An MG can contain other MGs and subscriptions.

Key for the exam

Main purpose: apply Azure Policy and RBAC to multiple subscriptions at once.

04

Subscription

Billing unit and quota boundary

Billing unit. Each subscription = one invoice. Has limits (quotas) per resource type. A tenant can have thousands of subscriptions. It's Azure's main trust boundary.

Key for the exam

Subscription ≠ Tenant. Subscription is billing. Tenant is identity.

05

Resource Group

Logical container of resources

Groups related resources for joint management. Defines the container's region (resources can be in other regions). Deleting the RG deletes all its resources. Typical deployment unit.

Key for the exam

Resources in an RG should share the same lifecycle — they get created, updated, and deleted together.

06

Resources

VMs, Storage, SQL, etc.

The individual entities in Azure: VMs, disks, databases, virtual networks, storage accounts. Everything you create in Azure is a resource. Each resource has a type, name, region, and subscription.

Key for the exam

Each resource belongs to exactly 1 Resource Group, 1 Subscription, 1 Region.

Tenant and Microsoft Entra ID

What exactly is the Tenant?

When you sign up for Azure, Microsoft automatically creates an Entra ID Tenant for your organization. It's the centralized identity directory. All users, groups, applications, and permissions in Azure are managed here.

IdentifierTenant ID (unique GUID) or domain name (contoso.onmicrosoft.com)
ContentUsers, groups, applications, service principals, devices
ScopeCan have subscriptions of multiple types (Pay-As-You-Go, EA, CSP)
Multi-tenantAn app can be multi-tenant: accepts users from other tenants
B2B/External IDB2B: invite external users. External ID: customer identities (successor to Azure AD B2C)

Entra ID = Azure's identity brain

Previously called Azure Active Directory (). Renamed to Microsoft Entra ID in 2023. Do NOT confuse it with Windows Server Active Directory — they're distinct, though they integrate.

On-prem AD vs Entra ID

Windows Server AD: LDAP/Kerberos protocol. On-premises. Manages domain-joined computers.
Microsoft Entra ID: OAuth/OIDC/SAML protocol. Cloud. Manages identities for cloud and SaaS apps.
Microsoft Entra Connect: Syncs on-prem AD users to Entra ID for hybrid SSO.
Icon-general-11

Management Groups — governance at scale

Real case: an enterprise with 50 subscriptions

Root Management Group (Contoso)
├── MG: Production
│ ├── Sub: Finance-Prod ($15k/month)
│ ├── Sub: Sales-Prod ($8k/month)
│ └── Sub: Operations-Prod ($12k/month)
├── MG: Non-Production
│ ├── Sub: Dev ($2k/month)
│ ├── Sub: Staging ($3k/month)
│ └── Sub: Testing ($1k/month)
└── MG: Sandbox
└── Sub: Experiments ($500/month)

Why use Management Groups

  • Policy on MG-Production: All Prod subs inherit the policy. "All VMs must be in approved regions" → applies to 30 subs at once.
  • RBAC on MG-NonProd: The QA team has Contributor access to MG-NonProd. They automatically get access to the Dev, Staging, and Testing subs.
  • Budget on Sandbox MG: $500/month limit on MG-Sandbox. No experiment can spend more without approval.

MG limits and restrictions

10,000Maximum Management Groups per tenant
6Maximum levels of depth (not counting Root)
1An MG can have only 1 parent
InheritancePolicies and RBAC inherit downward, never upward
Icon-general-2

Subscriptions — types, limits, and strategies

Pay-As-You-Go (PAYG)

Monthly billing based on consumption. Credit card. No commitment. Highest price per resource.

Ideal for

Individuals, startups, proofs of concept

Enterprise Agreement (EA)

3-year contract with Microsoft. Negotiated price (~15-30% discount). Annual invoice. Prepaid credit that gets consumed.

Ideal for

Companies with $100k+/year in Azure spend

Cloud Solution Provider (CSP)

Through a Microsoft partner. The partner bills you (not Microsoft directly). Support included from the partner.

Ideal for

SMBs wanting local support included

Reasons to have multiple subscriptions

Environment separation: Prod, Dev, Staging in separate subs. You avoid an error in Dev affecting Prod. Separate budgets.
Per-subscription quota limits: Max 980 Resource Groups per sub. Max 25k VMs per region per sub. For massive workloads, multiple subs.
Billing per business unit: Finance, Sales, IT have separate subs. Each department sees its own invoice. Easier chargeback.
Compliance and data isolation: Regulated data (HIPAA, PCI-DSS) in a separate sub with more restrictive policies. Smaller blast radius.
Independent teams: Team A has Owner on its sub. Team B on its own. They don't interfere. Autonomy with governance at the MG level.
Controlled spending limits: Budget per subscription + alerts. If Dev overspends, it doesn't affect the Prod budget.
Icon-general-7

Resource Groups — best practices

Fundamental RG rules

  • One resource, one RG: Each resource belongs to exactly 1 RG. You can't share a resource between RGs.
  • Same subscription: All resources in an RG must be in the same subscription. You can't have resources from different subs in the same RG.
  • RG region ≠ resource region: The RG has a region (where its metadata is stored), but its resources can be in different regions.
  • Deleting an RG = deleting everything: Deleting an RG permanently deletes ALL its resources. This is the most destructive operation in Azure.
  • Inherited RBAC: Permissions assigned at the RG level apply to all resources within it.

RG organization strategies

By environment (recommended for most)

rg-prod-westeurope, rg-dev-eastus, rg-staging-eastus

Medium-sized teams. Each environment has its own RG and separate access.

By application

rg-webapp-prod, rg-database-prod, rg-api-prod

Multiple independent apps. Each app has its own lifecycle.

By region

rg-eastus-prod, rg-westeurope-prod

Multi-region architectures where resource locality matters.

By team / department

rg-finance-prod, rg-hr-prod, rg-it-prod

Companies with per-department chargeback.

applied to the hierarchy

Role-Based Access Control — who can do what, at what scope.

Main built-in roles for the AZ-900

RoleCanCan'tUse case
OwnerEverything: create, modify, delete resources AND manage accessNothing within the assigned scopePerson responsible for a whole subscription or RG
ContributorCreate, modify, delete resourcesManage access (can't grant roles to others)Developer who deploys resources but doesn't manage permissions
ReaderView all resources and their configurationCreate, modify, or delete anythingAuditor, stakeholder who only needs visibility
User Access AdministratorManage access (grant/revoke roles)Create or modify resources themselvesIAM/security team that manages permissions without operating resources

RBAC inheritance

Permissions assigned at a HIGHER level are automatically inherited downward.

Owner on MG-Production
→ Owner on all subs in MG-Prod
→ Owner on all RGs in those subs
→ Owner on all resources in those RGs

Least-privilege principle

Assign the most restrictive role that lets someone do the job, at the smallest possible scope.

Owner on the entire Subscription
Contributor on just their Resource Group
Contributor just to view logs
Reader on the specific RG

and inheritance

Azure Policy vs RBAC — key difference

RBAC — Who can do what?

Controls user actions. "User John can create VMs" or "Mary can only read".

Focus: identities and permissions

Azure Policy — What configurations are allowed?

Controls resource properties. "VMs can only be created in East US" or "Every resource must have an 'Owner' tag".

Focus: resource configuration and compliance

Azure Policy effects

Deny: Blocks creation/modification if it violates the policy. Error when trying to create it.
Audit: Doesn't block, but logs a non-compliance alert. For monitoring without enforcement.
Append: Adds additional properties to the resource when it's created (e.g., automatically adding a tag).
DeployIfNotExists: If the resource lacks a certain configuration, it deploys it automatically.
Modify: Modifies resource properties when created or updated.

Tags and Resource Locks

Tags — resource metadata

Key-value pairs you can assign to resources and resource groups. Max 50 tags per resource.

Common uses

Environment: Production

Filter resources by environment in Cost Management

Owner: azure-team@contoso.com

Know who to contact if there's an issue

CostCenter: IT-0042

Automatic chargeback to cost centers

Project: SAPMigration

Group a project's resources for its billing

Tags are NOT inherited from RG to resources by default. You need Azure Policy to enforce inheritance.

Resource Locks — protection against deletion

Locks that prevent accidental modifications or deletions. Applied to resources, RGs, or subscriptions.

CanNotDelete

Anyone can read and modify the resource, but no one can delete it (without removing the lock first).

Critical resources that should never be deleted: prod storage, prod SQL.

ReadOnly

No one can modify or delete the resource. Read-only. Similar to assigning the Reader role to everyone.

Reference infrastructure that should never change without a formal process.

Locks are inherited from an RG to all its resources. To remove a lock, you need to be Owner or User Access Administrator.

Related labD2 · Architecture and services

Explore the Azure Portal

Learn to navigate the Azure Portal, find key resources, and explore the main interface you'll use as an Azure administrator.

Identify the main elements of the Azure Portal
Navigate to the Resource Groups service

+1 more...

5 min3 steps
Related labD2 · Architecture and services

Create your first Resource Group

Create a Resource Group in Azure to organize and manage your cloud resources. Resource Groups are Azure's fundamental container.

Understand what a Resource Group is and what it's for
Create a Resource Group with the right name and region

+1 more...

8 min6 steps

Did you get this topic?

Test what you just learned

At which level of the Azure hierarchy should policies be applied so they automatically affect all of an organization's subscriptions?

Ready to test "Resource hierarchy"?

Put what you learned to the test with original AZ-900 exam questions.

Start AZ-900 mock exam

Unlimited mock exams with the Pro plan

Log in to track your progress.