What the exam is and how it is scored

Microsoft Azure Fundamentals (AZ-900) is Microsoft's Azure Fundamentals exam. A score of 700 or greater is required to pass. The skills measured below are those published as of July 20, 2026.

The exam is split into three skill areas:

• Describe cloud concepts (25–30%)
• Describe Azure architecture and services (35–40%)
• Describe Azure management and governance (30–35%)

This guide covers the middle one, 'Describe Azure architecture and services'. At 35–40% it is the largest area, so it is worth the most revision time. This guide works through two parts of it: Azure's core architectural components (physical layout and management structure) and Azure storage services. The source material is Microsoft Learn, licensed CC BY 4.0.

Much of this area consists of pairs of similar things that are easy to confuse. So the sections below focus on the differences between similar things.

Physical infrastructure: datacenters, regions, zones

Azure's architecture has two groupings: the physical infrastructure and the management infrastructure. Start with the physical one.

A datacenter is a facility with servers in racks and dedicated power, cooling and networking. You do not interact with individual datacenters. They are grouped into regions and availability zones.

Region. A geographical area containing at least one, and possibly several, datacenters that are nearby and joined by a low-latency network. When you deploy a resource you often choose a region. Two details matter:

• Some services or VM features exist only in certain regions, such as specific VM sizes or storage types.
• Some global services do not need a region. The examples given are Microsoft Entra ID, Azure Traffic Manager and Azure DNS.

Availability zone. A physically separate datacenter (or more than one) within a region, with independent power, cooling and networking. A zone is an isolation boundary: if one goes down, the others keep working. Zones are linked by high-speed private fiber.

Facts to hold onto:

• Every region that supports availability zones has a minimum of three separate zones.
• Not all regions support availability zones.
• Duplicating services and transferring data between zones can cost money.

Services that support zones fall into three categories:

• Zonal: you pin the resource to a specific zone (VMs, managed disks, IP addresses).
• Zone-redundant: the platform replicates across zones automatically (zone-redundant storage, SQL Database).
• Non-regional: always available from Azure geographies and resilient to zone-wide and region-wide outages.

Region pairs. Most regions are paired with another region in the same geography, at least 300 miles away. If one region in a pair is hit by a disaster, services can fail over to the other. The advantages the material lists:

• In a large outage, one region of each pair is prioritised for recovery.
• Planned updates roll out to paired regions one at a time.
• Data stays in the same geography as its pair (except Brazil South), which helps with data residency and compliance.

Sovereign regions are instances of Azure isolated from the main instance, used for compliance or legal reasons. The two examples are the US government regions (such as US Gov Virginia), and the China regions (such as China East), which are run through a partnership with 21Vianet, so Microsoft does not directly maintain those datacenters.

Management infrastructure: the hierarchy

This is the most testable structure in the area. Read it from the bottom up:

• Resource: the basic building block. Anything you create, provision or deploy (a VM, a virtual network, a database, an Azure AI service).
• Resource group: a grouping of resources.
• Subscription: a unit of management, billing and scale that holds resource groups.
• Management group: sits above subscriptions and holds them.

Rules for each level:

Resource groups

• Every resource belongs to exactly one resource group at a time. Some resources can be moved between groups.
• Resource groups cannot be nested and cannot be renamed after creation.
• Actions on a group affect everything inside it. Deleting a resource group deletes all its resources, and granting or denying access applies to all of them.

Subscriptions

• You need a subscription to use Azure. An account can have many, but only one is required.
• A subscription is both a billing boundary (separate reports and invoices per subscription) and an access control boundary (access policies are applied at subscription level).
• Reasons to create more than one: separating environments (sandbox, development, test, production), separating teams or workloads, and tracking billing separately.

Management groups

• Governance conditions applied to a management group are inherited by every subscription in it.
• They can be nested up to six levels deep, not counting the root level or the subscription level.
• Every Microsoft Entra tenant has a single top-level Tenant Root Group.
• A directory supports up to 10,000 management groups.
• Each management group and each subscription can have only one parent.

The material gives two uses. The first is applying a policy across subscriptions, for example limiting VM locations to US West in a group called Production. The owner of a resource or subscription cannot override that policy. The second is granting access to many subscriptions at once with one Azure RBAC assignment on the management group, which everything beneath it inherits.

Storage accounts

A storage account gives you a unique namespace for your Azure Storage data, reachable over HTTP or HTTPS. Two naming rules are easy marks:

• The name must be 3 to 24 characters, using numbers and lowercase letters only.
• The name must be unique within Azure, not just within your subscription.

The account name plus a service-specific endpoint forms each endpoint. The pattern is the same for each service, for example <name>.blob.core.windows.net for Blob Storage and <name>.file.core.windows.net for Azure Files. Data Lake Storage Gen2 uses dfs, Queue Storage uses queue and Table Storage uses table.

The account type decides which services and redundancy options you get:

• Standard general-purpose v2: blobs (including Data Lake Storage), queues, tables and Azure Files. Offers LRS, GRS, RA-GRS, ZRS, GZRS and RA-GZRS. Recommended for most scenarios.
• Premium block blobs: block and append blobs, for high transaction rates, smaller objects or consistently low latency. LRS and ZRS.
• Premium file shares: Azure Files only, for high-scale or high-performance applications. LRS and ZRS. Use this type if you want both SMB and NFS shares.
• Premium page blobs: page blobs only. LRS only.

The storage services

• Blobs: massively scalable object storage for text and binary data, including backup, archiving, media streaming and analytics.
• Files: managed file shares using SMB or NFS. SMB shares work from Windows, Linux and macOS; NFS shares from Linux and macOS.
• Queues: messages for asynchronous processing between application components. Messages are up to 64 KB, and queues are commonly paired with Azure Functions.
• Disks: block-level volumes for Azure VMs.
• Tables: a NoSQL store for structured, non-relational data.

Redundancy: the comparison that decides questions

Data is always replicated three times in the primary region. The choices differ in where those copies sit and whether a second region is involved.

What to take from it:

• LRS is the lowest cost, and protects against rack and drive failures. A datacenter-level disaster can still cause data loss.
• ZRS keeps data readable and writable if one zone is unavailable. It needs a region with availability zones.
• GRS and GZRS add a secondary region, which Azure assigns from the region pair. They protect against regional disasters.
• Secondary data is not readable by default unless failover occurs. RA-GRS and RA-GZRS add read access to the secondary before any failover.
• Replication to the secondary is asynchronous, so a regional failure can lose recent writes. The gap is the recovery point objective (RPO). Azure Storage typically has an RPO of less than 15 minutes, but there is no SLA on how long replication takes.

Blob access tiers

Tiers balance storage cost against retrieval speed:

• Hot: frequently accessed data.
• Cool: infrequently accessed, stored at least 30 days.
• Cold: infrequently accessed, stored at least 90 days.
• Archive: rarely accessed, stored at least 180 days, with flexible latency requirements (long-term backups).

Rules: hot, cool and cold can be set at account level, but archive cannot. All four can be set at blob level. Cool and cold have lower storage costs but higher access costs and lower availability SLAs. Archive has the lowest storage cost and the highest rehydration latency and access cost.

Moving data into and within Azure

The material separates large-scale migration from moving individual files.

Large scale

• Azure Migrate: a hub for assessing and migrating on-premises infrastructure to Azure, with a single portal to start, run and track migration.
• Azure Data Box: a physical device shipped to you, with a maximum usable capacity of 80 terabytes. Suited to very large data sets (often tens of terabytes or more) when network bandwidth is limited. It handles import and export, and the disks are wiped afterwards.

Files and small groups of files

• AzCopy: a command-line utility to upload, download, copy between storage accounts and synchronise. Synchronisation is one-direction only.
• Azure Storage Explorer: a graphical app for Windows, macOS and Linux that uses AzCopy in the background.
• Azure File Sync: installed on a Windows server so it stays bi-directionally synced with Azure Files. It supports cloud tiering, where frequently used files are kept locally and the rest stay in the cloud.

Common traps

• Zone versus region. A zone is a datacenter group inside a region. A region pair is two regions far apart. ZRS is about zones; GRS is about region pairs.
• Assuming failover is automatic. Not all services replicate or fail back automatically. For some, the customer must configure recovery and replication.
• Brazil South. It is paired in one direction only, with a region outside its geography (South Central US), and South Central US is not backed up by Brazil South. Some regions, such as Italy North, Poland Central and Israel Central, have no traditional pair and rely on availability zones and geo-redundant storage.
• Nesting resource groups. They cannot be nested. Management groups can, to six levels.
• Subscription as only a billing unit. It is also an access control boundary.
• Archive at account level. It is blob level only.
• One-way versus two-way sync. AzCopy sync goes one direction. Azure File Sync is bi-directional.
• Bandwidth. When a scenario stresses very large data and limited network bandwidth, think Data Box rather than an online copy tool.
• Read access. GRS and GZRS do not by themselves let you read the secondary. That needs the RA- versions.

How to study

1. Draw the hierarchy from memory: resource, resource group, subscription, management group, tenant root. Add the rule that applies at each level. 2. Build the redundancy table yourself, without looking, then check it. Add a column for 'survives zone loss' and 'survives region loss'. 3. Make flashcards for the numbers in this guide: three zones, 300 miles, six nesting levels, 10,000 management groups, 3 to 24 characters, 30/90/180 days, 64 KB, 80 TB. 4. For each tool pair (Migrate and Data Box, AzCopy and File Sync), write one sentence on when you would choose each. 5. Read each practice question for its deciding word: frequently, bandwidth, regional disaster, read access, billing. Those words usually point to one option. 6. If you practise in a real Azure account, remove resources you no longer need to avoid unexpected costs.

Practise

Reading builds recognition, but telling similar options apart takes practice. When you are ready, try AZ-900 practice questions on this topic and check which distinctions still catch you out.

Practise this with Microsoft Azure Fundamentals (AZ-900) questions

More of this guide