4.1. Azure Storage Accounts: The Universal Container
💡 First Principle: Azure Storage Accounts are the foundation layer for storing "everything else"—data that doesn't belong in a database. Think of a Storage Account as a warehouse with different types of storage bays: blob containers for objects (like boxes stacked high), file shares for documents (like filing cabinets), and tables for simple lookups (like a card catalog). The Storage Account provides the address; the service type within it determines how you interact with the data.
What happens without understanding these distinctions? You might try to mount Blob Storage as a network drive (it won't work—that requires Azure Files). Or you might store application logs in Azure Files (expensive and unnecessary when Blob Storage is 10x cheaper for that use case). Choosing the right storage type within your account is as important as choosing the account itself.
Scenario: A media company needs to store millions of images, provide file shares for content creators, and maintain simple configuration data. A database would be overkill and expensive. Azure Storage offers cost-effective alternatives.
Azure Storage Accounts are the foundation for multiple storage services, each optimized for different access patterns.
⚠️ Exam Trap: answering with the Storage Account itself. The account is only the address — nearly every question in this section is really asking which service inside it you need. Find the verb: served over HTTP → Blob, mounted as a share → Files, looked up by key → Table, passed between components → Queue.
Storage Redundancy: How Many Copies, and Where
💡 First Principle: Azure always keeps multiple copies of your data. The redundancy option decides how far apart those copies sit — and distance is what buys you protection against bigger failures.
| Option | Copies | Survives | Reads from the secondary? |
|---|---|---|---|
| LRS — Locally redundant | 3 copies in a single datacentre | A disk or rack failure | n/a |
| ZRS — Zone redundant | 3 copies across separate availability zones in one region | A whole datacentre going down | n/a |
| GRS — Geo-redundant | LRS in the primary + 3 more in a paired region hundreds of miles away | Losing the entire region | No — the secondary is for failover only |
| RA-GRS — Read-access geo-redundant | Same copies as GRS | Losing the entire region | Yes — you can read the secondary at any time |
| GZRS | ZRS in the primary + LRS in the paired region | A zone failure and a regional failure | No (RA-GZRS adds read access) |
Two traps the exam leans on:
- Geo-replication is asynchronous. Writes land in the primary region first and reach the paired region moments later. If a question demands synchronous copies across regions, no Azure Storage redundancy option provides that.
- GRS does not let you read the second copy. If the requirement is "keep serving reads from another region", the answer is RA-GRS, not GRS. Choosing GRS gives you the durability but not the access.
Reasoning Tool: cheapest and the data is reproducible → LRS. Must survive a datacentre outage → ZRS. Must survive losing the region → GRS. Must also read from elsewhere → RA-GRS.
