Storage is one of the most heavily tested — and most frequently confused — areas of the AZ-900 exam. It sits inside the “Describe Azure architecture and services” domain, which is 35–40% of your marks, and the questions are rarely about clicking through the portal. They ask you to reason: which redundancy option survives a full region outage, which access tier is cheapest for data you touch once a year, and which storage account type you’d pick for a specific workload. Get the mental model right and this becomes a reliable source of points instead of a guessing game.
This guide builds that model from the ground up. We’ll cover the three decisions every Azure storage account forces you to make — the account type, the data services it holds, the access tier for your blobs, and the redundancy that keeps your data safe — and finish with a decision table and the exact exam cues that map a scenario to the right answer. Everything here is also genuinely useful on the job, well beyond the exam, because these are the same trade-offs a cloud engineer weighs every day.
What an Azure Storage Account Actually Is
An Azure Storage account is the top-level container that groups a set of Azure Storage data services under a single namespace, a single set of settings (redundancy, encryption, network rules), and a single billing boundary. Every blob, file share, queue, and table lives inside a storage account, and the account name becomes part of the URL you use to reach your data — for example, https://mystorage.blob.core.windows.net.
Because so many settings are fixed at the account level, choosing the account type and its redundancy correctly up front matters. You can change the access tier of a blob any time, but the account kind and some redundancy transitions are more constrained.
The Four Core Data Services
A general-purpose storage account can hold four data services. The exam expects you to match each to its purpose, not to configure them.
| Service | What it stores | Typical use |
|---|---|---|
| Blob (object storage) | Unstructured objects — images, video, backups, logs, documents | Static website assets, data lakes, backups, anything file-like at massive scale |
| Azure Files | Fully managed SMB and NFS file shares | Lift-and-shift file servers, shared configuration, mounting a share across VMs |
| Queue | Simple messages (up to 64 KB each) | Decoupling application components with asynchronous messaging |
| Table | Schemaless NoSQL key-value data | Fast, cheap storage for large amounts of structured, non-relational data |
Blob storage is by far the most tested. It also has three blob types worth recognizing: block blobs (the default — files and objects), append blobs (optimized for append operations like logging), and page blobs (random read/write, the backing store for older unmanaged VM disks).
Storage Account Types
Not every account can do everything. The type determines which services and performance tiers are available.
| Account type | Performance | Services supported | When to choose it |
|---|---|---|---|
| Standard general-purpose v2 (GPv2) | Standard (HDD-backed) | Blob, File, Queue, Table | The default recommendation for almost all scenarios |
| Premium block blobs | Premium (SSD) | Block/append blobs only | High transaction rates, low latency, small objects |
| Premium file shares | Premium (SSD) | Azure Files only | Enterprise or high-performance file shares |
| Premium page blobs | Premium (SSD) | Page blobs only | Specialized page-blob workloads |
For AZ-900, the key takeaways are simple: Standard general-purpose v2 is the modern default that supports all four services, and Premium accounts trade broader service support for SSD-backed speed aimed at a single service. (General-purpose v1 and the legacy Blob storage account still exist but are older; Microsoft recommends GPv2 for new work.)
Blob Access Tiers: Hot, Cool, Cold, and Archive
Access tiers let you match the storage price of a blob to how often you actually read it. The rule of thumb: the colder the tier, the cheaper it is to store data, but the more you pay (in money and latency) to access it.
| Tier | Best for | Minimum stay | Storage cost | Access cost |
|---|---|---|---|---|
| Hot | Frequently accessed data | None | Highest | Lowest |
| Cool | Infrequently accessed, kept ≥ 30 days | 30 days | Lower | Higher |
| Cold | Rarely accessed, kept ≥ 90 days | 90 days | Lower still | Higher still |
| Archive | Offline, rarely-if-ever accessed, kept ≥ 180 days | 180 days | Lowest | Highest + hours to retrieve |
Two properties trip people up:
- Archive is offline. Data in the Archive tier can’t be read directly — you must first rehydrate it back to an online tier (Hot, Cool, or Cold), which can take hours. That’s why Archive suits compliance data or long-term backups you’re legally required to keep but hope never to open.
- Early deletion penalties. If you delete or move a blob out of Cool, Cold, or Archive before its minimum stay, you’re billed as if it had stayed the full period. Moving a blob to Cool for a day and deleting it still costs 30 days of Cool storage.
Hot and Cool can be set as the account default and overridden per blob; Cold and Archive are set per blob, not as an account default.
Automating tiers with lifecycle management
You rarely move blobs by hand. A lifecycle management policy transitions blobs automatically based on age. A typical rule reads: keep new data Hot, move it to Cool after 30 days, Archive after 90, and delete after a year.
{
"rules": [
{
"name": "tier-and-expire",
"enabled": true,
"type": "Lifecycle",
"definition": {
"filters": { "blobTypes": ["blockBlob"] },
"actions": {
"baseBlob": {
"tierToCool": { "daysAfterModificationGreaterThan": 30 },
"tierToArchive": { "daysAfterModificationGreaterThan": 90 },
"delete": { "daysAfterModificationGreaterThan": 365 }
}
}
}
}
]
}This is a favorite exam theme: “minimize storage cost for data that’s accessed less over time, with no manual effort.” The answer is almost always lifecycle management moving blobs to cooler tiers.
Redundancy: How Azure Keeps Your Data Safe
Redundancy is the single most tested storage topic on AZ-900, and the acronyms are the trap. Every option keeps at least three copies of your data; what differs is where those copies live, which tells you what kind of failure they survive.
| Option | Copies | Where the copies are | Survives | Durability |
|---|---|---|---|---|
| LRS (Locally Redundant) | 3 | One datacenter in the primary region | Disk, rack, and server failure | ≥ 11 nines |
| ZRS (Zone-Redundant) | 3 | Three availability zones in the primary region | A full availability-zone outage | ≥ 12 nines |
| GRS (Geo-Redundant) | 6 | LRS locally (3) + LRS in a paired region (3) | A regional outage | ≥ 16 nines |
| GZRS (Geo-Zone-Redundant) | 6 | ZRS locally (3) + LRS in a paired region (3) | A zone or region outage | ≥ 16 nines |
The two “geo” options have a critical detail: the secondary region’s copy is not readable by default. Your data is replicated there for disaster recovery, but you can only read from it after a failover. If you need to read the secondary copy directly (for example, to serve read traffic closer to another region), you choose the read-access variants:
- RA-GRS — read-access geo-redundant storage (GRS + a readable secondary endpoint).
- RA-GZRS — read-access geo-zone-redundant storage (GZRS + a readable secondary endpoint).
The read-access endpoint uses a -secondary suffix on the URL, and the copy count is the same as GRS/GZRS — read access doesn’t add copies, it just opens the door to the secondary.
The classic exam question
Which redundancy option keeps six copies of your data across two regions?
That’s GRS (or GZRS). LRS and ZRS keep three copies in a single region; the geo options add a second three-copy set in the paired region for six total. This exact phrasing shows up constantly — memorize “geo = two regions = six copies.” This mirrors the walkthrough in our AZ-900 practice questions, where the same GRS scenario appears with a full explanation.
Choosing redundancy by failure domain
Map the worst failure you must survive to the smallest option that covers it:
- Survive a server/rack failure only, cheapest option → LRS.
- Survive an availability-zone outage within the region → ZRS.
- Survive a whole-region disaster → GRS / GZRS.
- Survive a region disaster and read the secondary copy → RA-GRS / RA-GZRS.
Securing and Accessing Storage
The exam also touches on how you reach and protect data. The essentials:
- Access keys — two account-level keys that grant full access. Powerful, and therefore best rotated and kept out of code.
- Shared access signatures (SAS) — time-limited, scoped tokens that grant specific permissions to specific resources without sharing an account key.
- Microsoft Entra ID + Azure RBAC — the recommended approach: authenticate identities and assign data roles like Storage Blob Data Reader or Storage Blob Data Contributor, so no shared secret is needed.
- Secure transfer (HTTPS-only) and encryption at rest — Azure Storage encrypts all data at rest by default, and you can require HTTPS for every request.
If a question asks how to enforce that all storage accounts use HTTPS-only traffic across a subscription, that’s an Azure Policy answer — governance sitting on top of storage.
Moving Data Into Azure Storage
AZ-900 lists several data-movement tools; recognize the right one for the scenario:
| Tool | Use it when |
|---|---|
| AzCopy | Scriptable, high-performance copy of blobs and files from the command line |
| Azure Storage Explorer | A desktop GUI to browse and manage storage visually |
| Azure Data Box | Shipping large datasets (tens of TB or more) offline when bandwidth is limited |
| Azure File Sync | Centralizing on-prem file shares in Azure Files while caching locally |
A quick AzCopy example that uploads a local folder to a container:
azcopy copy "./local-data/*" \
"https://mystorage.blob.core.windows.net/backups?<SAS-token>" \
--recursive=trueAnd creating a Standard, zone-redundant GPv2 account with the Azure CLI:
az storage account create \
--name mystorage \
--resource-group my-rg \
--location eastus \
--sku Standard_ZRS \
--kind StorageV2 \
--access-tier HotNotice how the redundancy is expressed as the SKU (Standard_ZRS, Standard_GRS, Standard_RAGZRS, Premium_LRS, and so on) — a detail worth recognizing even at the fundamentals level.
A Decision Table You Can Take Into the Exam
| Scenario cue | Answer |
|---|---|
| Cheapest redundancy, single datacenter is fine | LRS |
| Protect against an availability-zone failure | ZRS |
| Protect against a full region outage | GRS / GZRS |
| Region protection and read the secondary copy | RA-GRS / RA-GZRS |
| Data accessed constantly | Hot tier |
| Data accessed a few times a year, kept months | Cool / Cold tier |
| Compliance data kept for years, rarely read | Archive tier |
| Automatically lower cost as data ages | Lifecycle management policy |
| One account supporting blobs, files, queues, tables | Standard general-purpose v2 |
| Grant temporary, scoped access without sharing keys | SAS token |
| Access storage with identities, no shared secret | Microsoft Entra ID + Azure RBAC |
Practice Until the Trade-offs Are Automatic
Reading about LRS versus GZRS is enough to answer a clean question, but the real exam mixes cues — a scenario might combine a redundancy requirement, a cost constraint, and an access pattern in one paragraph and expect you to weigh all three under time pressure. That fluency comes from repetition.
That’s where full-length practice pays off. Sailor.sh’s AZ-900: Azure Fundamentals Mock Exam Bundle gives you eight timed, scenario-based mock exams that mirror the real 45-minute window and 700-point passing bar, with a detailed explanation on every question so a wrong answer becomes a lesson. Use the free concepts here to build the model; use timed exams to make the storage decisions reflexive. For the full exam picture and logistics, start with the AZ-900 exam guide for 2026, and if you’re still deciding whether the cert fits your goals, read our honest take on whether AZ-900 is worth it in 2026. Ready to schedule? Pair this with the 30-day AZ-900 study plan.
Frequently Asked Questions
What is the difference between LRS, ZRS, GRS, and GZRS?
All four keep at least three copies of your data. LRS keeps three copies in a single datacenter; ZRS spreads three copies across availability zones in the region; GRS adds a second three-copy set in a paired region (six total) for region-level protection; GZRS combines zone redundancy locally with geo-replication to a paired region. Storage cost rises roughly in that order, as does the breadth of failure you survive.
What is the difference between Hot, Cool, Cold, and Archive tiers?
They trade storage cost against access cost. Hot is cheapest to access but most expensive to store; Cool (≥30 days) and Cold (≥90 days) lower storage cost for data you rarely touch; Archive (≥180 days) is the cheapest to store but is offline and takes hours to rehydrate before you can read it.
Can I read the secondary region copy with GRS?
Not directly. Standard GRS and GZRS keep the secondary copy for disaster recovery only — it’s unreadable until a failover. To read the secondary endpoint directly, choose the read-access variants RA-GRS or RA-GZRS.
Which storage account type should I choose for AZ-900 scenarios?
Standard general-purpose v2 (GPv2) is the default answer for general scenarios because it supports all four services (Blob, File, Queue, Table) at standard cost. Choose a Premium account only when a single service needs SSD-backed low latency and high transaction rates.
How do I automatically move old data to cheaper storage?
Use a lifecycle management policy on the storage account. It transitions blobs between tiers (Hot → Cool → Cold → Archive) and can delete them based on age, with no manual intervention — the standard answer to “minimize cost as data ages.”
Is Azure Storage encrypted by default?
Yes. Azure Storage encrypts all data at rest automatically using Storage Service Encryption, and you can also require secure transfer (HTTPS) for all requests. You can optionally manage your own keys, but encryption at rest is on by default.
Conclusion
Azure Storage looks intimidating because of the acronyms, but it collapses into a few clean decisions. Pick a storage account type (Standard general-purpose v2 unless you need Premium speed for one service), understand the four data services, match your data’s access pattern to an access tier (Hot, Cool, Cold, or Archive, automated with lifecycle policies), and choose redundancy by the worst failure you must survive (LRS → ZRS → GRS/GZRS, with RA variants for a readable secondary). Anchor every question to those trade-offs, remember that geo means two regions and six copies, and Azure Storage becomes one of the most dependable topics on the AZ-900 exam — and one of the most useful things you’ll carry into real Azure work.