If the AZ-900 has a single load-bearing topic, this is it. Describe the core architectural components of Azure is the first objective inside Azure architecture and services, the largest scored domain on the exam at 35–40%, and almost every other Azure service you study — compute, storage, identity — is deployed into the structure this topic describes. Get the hierarchy straight and a whole class of exam questions becomes recognition instead of guesswork.
Azure’s architecture is really two hierarchies laid over each other. One is physical: the buildings and geography where your workloads actually run (datacenters, availability zones, regions, region pairs). The other is logical: the management and billing containers you use to organize, secure, and pay for what you deploy (resources, resource groups, subscriptions, management groups). The AZ-900 tests whether you can tell the two apart and pick the right one for a given need. This guide walks both, at the fundamentals altitude the exam actually asks about — what each component is and when it applies — with the confusable pairs pulled into decision tables, because that is exactly where the exam sets its traps.
The Two Hierarchies at a Glance
Before the detail, hold this map in your head. The physical side answers “where does my workload physically run and how do I survive a failure?” The logical side answers “how do I organize, govern, and bill for it?”
| Hierarchy | Components (largest → smallest) | Question it answers |
|---|---|---|
| Physical | Geography → Region (with its Availability Zones) → Datacenter | Where does it run? How resilient is it? |
| Logical | Management group → Subscription → Resource group → Resource | How is it organized, governed, and billed? |
A resource — a single VM, say — lives in one region (physical) and one resource group (logical) at the same time. Those two facts are independent, and mixing them up is the most common beginner error the exam probes.
The Physical Hierarchy: Where Your Workloads Run
Datacenters
A datacenter is a physical facility: a building full of racks, servers, storage, networking, backed by dedicated power, cooling, and connectivity. Datacenters are the atoms of Azure’s physical footprint, but you never deploy “to a datacenter” directly — Microsoft abstracts them behind availability zones and regions. You will rarely be asked about datacenters in isolation; they matter because availability zones are made of them.
Regions
A region is a set of datacenters deployed within a latency-defined perimeter and connected through a dedicated low-latency network. When you create a resource, you choose a region — East US, West Europe, Southeast Asia — and that is the geographic location where the resource physically lives and where its data resides (important for data residency and compliance).
Two practical exam points about regions:
- Not every service is available in every region. Newer or specialized services roll out to a subset of regions first. “Choose a region that supports the service you need” is a legitimate answer.
- You pick the region closest to your users to minimize latency, or a specific region to satisfy a data-residency requirement (“customer data must remain in Germany”).
Geographies
A geography is a discrete market, typically containing two or more regions, that respects data-residency and compliance boundaries (for example, the United States, Europe, or Asia Pacific). Geographies let customers with specific residency needs keep data and applications close and compliant. Region pairs (below) always sit within the same geography, so replicated data never leaves the compliance boundary.
Availability Zones
An availability zone (AZ) is one or more physically separate datacenters within a single region, each with independent power, cooling, and networking. Regions that support zones have a minimum of three of them, spaced far enough apart to survive a localized failure (a flood, a fire, a power outage in one zone) yet close enough for high-speed, low-latency replication.
Availability zones are Azure’s primary tool for high availability inside a region. There are two ways services use them:
- Zonal — you pin a resource to a specific zone (e.g., a VM in Zone 1). You get low latency, but you are responsible for spreading instances across zones yourself.
- Zone-redundant — the service automatically replicates across zones for you (e.g., zone-redundant storage, or a zone-redundant load balancer). One zone can fail and the service keeps running.
Exam cue: “protect an application against the failure of a single datacenter within a region” → availability zones. “protect against an entire region going down” → region pairs / multi-region (next). Confusing these two is the single most-tested distinction in this topic.
Region Pairs
Each Azure region is paired with another region in the same geography, usually at least 300 miles away. This region pair underpins cross-region resilience and disaster recovery:
- Some services replicate data to the paired region automatically. Geo-redundant storage is the classic example — see the Azure Storage redundancy guide for how LRS, ZRS, GRS, and GZRS build on zones and pairs.
- During a broad outage, Microsoft prioritizes recovery of at least one region out of every pair.
- Planned platform updates roll out sequentially across a pair — never to both regions at once — so an update problem can’t take down both halves simultaneously.
A subtle, current nuance worth knowing: Microsoft now positions availability zones as the preferred first line of high availability, and offers newer regions that are non-paired (relying on zones plus customer-managed replication) alongside the traditional paired model. For the AZ-900, remember the classic behavior of region pairs and that zones are the modern default for in-region HA.
Sovereign and Special Regions
Beyond the standard public cloud, Azure runs isolated instances for specific compliance and sovereignty needs:
- Azure Government — physically and logically isolated regions in the US for government agencies and their partners.
- Azure operated by 21Vianet — a separate instance of Azure in China, operated by a local partner to meet Chinese regulations; it is not connected to the global Azure network.
You won’t deploy to these day to day, but the exam may name them as examples of regions that meet strict data-sovereignty requirements.
The Logical Hierarchy: How You Organize and Govern
Now the other tree — the one you actually click through in the portal. From smallest to largest: resource → resource group → subscription → management group. Governance (policy and access control) applied higher up inherits downward, and that inheritance is the whole reason the hierarchy matters.
Resources
A resource is a single manageable instance of an Azure service: a virtual machine, a storage account, a virtual network, a web app, a public IP. Everything you create in Azure is a resource, and every resource is created through Azure Resource Manager — the deployment and management layer that also handles the portal, CLI, PowerShell, and ARM/Bicep templates covered in the management and governance guide. Every resource lives in exactly one resource group.
Resource Groups
A resource group (RG) is a logical container that holds related resources for an application or workload. The rules the exam cares about:
- Every resource belongs to exactly one resource group. A resource can be moved to another RG, but it is never in two at once.
- A resource group has its own location (region). That location stores the metadata about the group. Crucially, the resources inside an RG can live in different regions than the RG itself — the RG’s region is just where its record is kept.
- Deleting a resource group deletes every resource in it. This makes RGs an excellent lifecycle boundary: put everything for a short-lived project in one RG and tear it all down with a single delete.
- Resource groups are a natural scope for role-based access control (RBAC) and Azure Policy — assign a role or a policy at the RG and it applies to every resource inside.
- Group resources that share a lifecycle. If they’re created, updated, and deleted together, they belong in the same RG.
Subscriptions
A subscription is a logical unit of billing and management. It is the boundary at which usage is metered and invoiced, and it is where many quotas and limits apply (for example, caps on the number of certain resources you can create). Organizations commonly use multiple subscriptions to separate:
- Billing — e.g., one subscription per department or cost center, so each gets its own invoice.
- Access and management — different environments (production vs. development) in separate subscriptions to isolate blast radius and simplify access control.
Every subscription is associated with a single Microsoft Entra ID tenant (the identity boundary), which handles authentication for the resources in it. A subscription contains resource groups, which contain resources.
Management Groups
A management group sits above subscriptions and lets you manage many subscriptions at once. You apply governance conditions — Azure Policy assignments and RBAC role assignments — to a management group, and they cascade down to every subscription, resource group, and resource beneath it.
- Management groups can be nested (up to six levels of depth, not counting the root or the subscription level), letting you mirror an organization’s structure — e.g., a “Production” management group and a “Non-Production” management group, each holding several subscriptions.
- Every directory (tenant) has a single root management group at the top; all other management groups and subscriptions roll up to it.
- Use a management group when you need to enforce a rule once, at scale — “every subscription in the company must block resource creation outside approved regions” — rather than repeating the same policy on each subscription.
Exam cue: the trigger word is “multiple subscriptions.” The moment a scenario says you need to apply a policy or an access rule across several subscriptions at once, the answer is a management group, not a resource group and not a single subscription.
How Governance Inherits Down the Tree
The reason to learn the order is inheritance. A policy or role assigned at a higher scope applies to everything below it:
Root management group
└── Management group (policy/RBAC here → applies to all below)
└── Subscription (billing boundary; policy/RBAC here → applies to all below)
└── Resource group (lifecycle + access scope; policy/RBAC here → applies to all below)
└── Resource (the actual service instance)Assign a “require a cost-center tag” policy at the management group, and every resource group and resource under every subscription inherits it. This is why real Azure estates are governed from the top of the tree — a topic the management and governance guide picks up in detail with Azure Policy, resource locks, and RBAC.
Putting the Two Hierarchies Together
A single resource is described by both trees at once. Take a production web app’s virtual machine:
- Physically: it runs in the East US region, pinned to Availability Zone 2, with its data replicated to the paired region West US via geo-redundant storage.
- Logically: it lives in the rg-webapp-prod resource group, inside the Production subscription, which rolls up to the Production management group where the “approved regions” policy is enforced.
Nothing about the physical placement constrains the logical placement or vice versa. The VM’s region (East US) and its resource group’s region are independent. That independence — physical where it runs vs. logical how it’s organized — is the mental model the exam rewards.
Scenario Cues: Mapping Requirements to Components
The AZ-900 phrases this topic as business scenarios. Train the reflex to jump from the cue to the component:
| Scenario cue | Right component |
|---|---|
| ”Survive the failure of one datacenter within a region” | Availability zones |
| ”Survive an entire region outage / disaster recovery” | Region pair / second region |
| ”Keep customer data inside a specific country for compliance” | Region (in the right geography) |
| “Deploy resources close to users to reduce latency” | Region selection |
| ”Delete everything for this short-lived project in one action” | Resource group (delete the RG) |
| “Separate the production and dev bills / apply spending limits” | Subscriptions |
| ”Apply one policy across many subscriptions at once” | Management group |
| ”Give a team access to a set of related resources together” | Resource group (RBAC at RG scope) |
| “Isolated Azure for a US government agency” | Azure Government (sovereign region) |
Common Mistakes to Avoid
| Mistake | Reality |
|---|---|
| Thinking availability zones protect against a region failure | Zones protect against a datacenter failure within a region; use a region pair for region-level DR. |
| Assuming a resource group must be in the same region as its resources | The RG has its own region for metadata; its resources can be in any region. |
| Believing a resource can belong to multiple resource groups | A resource belongs to exactly one RG (it can be moved, but never shared). |
| Confusing a subscription with a resource group | A subscription is a billing/management boundary; a resource group is a lifecycle/access container inside it. |
| Applying the same policy to each subscription by hand | Apply it once at a management group and let it inherit. |
| Treating “region pair” as something you configure per resource | Pairs are a platform-defined relationship; specific services (like GRS) use them automatically. |
| Thinking every region has availability zones | Zone support is region-by-region; zone-enabled regions have at least three zones. |
Frequently Asked Questions
What is the difference between an availability zone and a region pair? An availability zone protects against the failure of a single datacenter within one region — the datacenters in different zones have independent power, cooling, and networking. A region pair protects against an entire region going down by pairing it with a second region in the same geography for replication and disaster recovery. Zones = in-region high availability; pairs = cross-region disaster recovery.
What is the difference between a resource group and a subscription? A subscription is a unit of billing and management (and where quotas apply); a resource group is a lifecycle and access container for related resources inside a subscription. One subscription holds many resource groups; one resource group holds many resources.
Can resources in one resource group be in different regions? Yes. A resource group has its own region, but that only determines where the group’s metadata is stored. The resources inside it can each be deployed to any region you choose.
When should I use a management group instead of a subscription? Use a management group when you need to apply governance — an Azure Policy assignment or an RBAC role — across multiple subscriptions at once. If everything fits in a single subscription, you don’t need a management group; the trigger is scale across subscriptions.
How many availability zones does an Azure region have? Regions that support availability zones have a minimum of three physically separate zones. Not all regions are zone-enabled, so availability is region-by-region.
Does choosing a region affect where my data is stored? Yes. The region you deploy to is where the resource physically runs and where its data resides, which is how Azure supports data-residency requirements. Region pairs stay within the same geography, so geo-replicated copies don’t cross the compliance boundary.
Is a resource group a security boundary? It’s a convenient scope for assigning RBAC and Azure Policy, but the strong isolation boundaries in Azure are the subscription and the Microsoft Entra ID tenant. Think of the resource group as an organizational and lifecycle container that also happens to be a handy place to attach access rules.
Practice Until the Hierarchy Is Automatic
This objective rewards a reflex: hear “multiple subscriptions” and think management group; hear “one datacenter fails” and think availability zone; hear “entire region fails” and think region pair. That reflex only comes from answering enough scenario questions that the cues become automatic. Sailor.sh’s AZ-900 Fundamentals mock exam bundle — 8 full-length mock exams built to mirror the current skills measured blueprint — weights the architecture-and-services domain heavily so you practice exactly these discriminations under timed conditions. To try the format first, work through the free AZ-900 practice questions and the full AZ-900 practice set.
To round out the rest of Azure architecture and services, pair this with the sibling guides on Azure Compute and Azure Storage, then connect the governance side with Azure Management & Governance and Azure Identity, Access & Security. Start with the AZ-900 exam guide for 2026 for logistics and the full blueprint, schedule your prep with the 30-day AZ-900 study plan, and if you’re still deciding, read is the AZ-900 worth it in 2026 or compare paths in AZ-900 vs AWS Cloud Practitioner.