Sequence 1 — Foundations & Architecture of Azure Storage

Prerequisites: None — this is the entry point. · What you'll be able to do: name the four core data services and position the related ones · explain the account → service → container/share → object hierarchy · parse and construct any storage endpoint URL · state the headline scalability limits and why they matter. · Est. time: ~12 min

1. The big picture: what Azure Storage is

Azure Storage is Microsoft's cloud storage platform. Everything you store lives in a storage account, is reachable from anywhere over HTTP/HTTPS via a REST API (plus client libraries for .NET, Java, Python, JavaScript, Go, C++), and inherits five platform guarantees worth memorizing:

• Durable & highly available — multiple copies are kept; you choose how widely they replicate (redundancy is Sequence 3).
• Secure — all data is encrypted at rest by the service, automatically (encryption is Sequence 4); access is finely controlled (auth is Sequences 6–9).
• Scalable — designed for massive capacity and throughput.
• Managed — Microsoft handles hardware, patching, and failures.
• Accessible — reachable via portal, Azure CLI, Az PowerShell, AzCopy, Storage Explorer, REST, and SDKs.

Mnemonic: D-S-S-M-A (Durable, Secure, Scalable, Managed, Accessible).

2. The data services (and the related ones)

The Azure Storage platform hosts four core data services, all addressed through a storage account. Memorize these four cold — they are the spine of the whole module.

Correction / clarification: older material lumps everything as "Azure AD" or "blob storage." Current terminology is Microsoft Entra ID for identity and the four blob tiers are Hot / Cool / Cold / Archive. Azure Table Storage is now documented under Azure Cosmos DB, but the classic Table service in a storage account still exists and is what AZ-104 means by "Table".

Related storage services — know what they are, not how to run them. They are not general data services inside a standard account:

Memory hook — the four core services are B-F-Q-T (Blob, Files, Queue, Table). Disks, Elastic SAN, Container Storage, and NetApp Files sit around the platform, not inside the standard account.

3. The storage account: namespace + management boundary

A storage account is the top-level container for all your Blob, Files, Queue, and Table data. Two ideas to lock in:

1. It is a unique namespace. Every object gets a URL built from your globally unique account name. Because the name becomes a DNS subdomain, it must be unique across all of Azure.
2. It is the management/billing boundary. Redundancy, default encryption, networking, and billing are configured per account, and all objects in an account are billed together.

Account naming rules (commonly tested):

• 3–24 characters, lowercase letters and numbers only (no hyphens, no uppercase).
• Globally unique across Azure.

The recommended account type for almost everything is Standard general-purpose v2 (GPv2) — it supports all four services. Premium tiers (block blob, file shares, page blob) are SSD-backed and service-specific. You cannot change an account's type after creation — to switch, you create a new account and copy the data. (Account creation and type selection are Sequence 2.)

4. The resource hierarchy

Each service nests objects inside a per-service container, all under the one account. Internalize this chain — it explains every URL and every permission scope later in the module.

The pattern is always: account → service → container → object. The middle "container" word just changes per service:

5. Service endpoints & URL structure

Because the account name is a DNS subdomain, each service has its own endpoint. A standard endpoint = https:// + account name + a fixed per-service domain. Memorize the four core service subdomains:

To address an object, append its path to the service endpoint:

https://<account>.blob.core.windows.net/<container>/<blob>
https://<account>.file.core.windows.net/<share>/<directory>/<file>

Build-an-endpoint drill (B-F-Q-T → blob, file, queue, table): given account salesdata, its Files endpoint is https://salesdata.file.core.windows.net.

Practical notes: Prefer HTTPS. Treat the endpoint hostname as stable, but never hard-code the resolved IP address — the underlying DNS CNAME/A records can change without notice; honor the DNS TTL. (Azure DNS zone endpoints — the …z<N>.<service>.storage.azure.net form — are (Preview) and slated for retirement, so use standard endpoints.)

6. Blob storage — the conceptual minimum

Blob = Binary Large OBject = Microsoft's object store for unstructured data. Three resource levels: storage account → container → blob. A container groups blobs like a directory; its name must be a valid DNS name (3–63 chars, lowercase letters/numbers/hyphens, no consecutive hyphens). One account can hold unlimited containers; one container, unlimited blobs.

Three blob types — know which is which:

Mnemonic: BAP — Block (general), Append (logs), Page (disks). Deeper blob topics — access tiers (Hot/Cool/Cold/Archive), data protection, lifecycle — are Sequences 10–12.

7. Azure Files — the conceptual minimum

Azure Files = fully managed file shares in the cloud. Unlike blobs, it speaks real file-share protocols, so apps and OSes mount it like a network drive with no code change:

• SMB — mountable from Windows, Linux, macOS.
• NFS — mountable from Linux (requires a premium file shares account).
• Azure Files REST API — programmatic access.

Key value: many machines share the same files concurrently (read/write); shares can be cached on-prem with Azure File Sync; you can reach a file via URL plus a shared access signature (SAS) token (auth in Sequence 6). Detailed planning, tiers, File Sync, and protection are Sequence 13.

8. Scalability & performance targets — "limits exist, plan around them"

Azure Storage is massive but not infinite. A single standard GPv2 account has published scale targets; design so a hot account doesn't hit a ceiling. The headline figures (current typical values — always confirm against current Azure limits):

Why it matters: these are per account. The standard mitigation is to spread very high-throughput workloads across multiple storage accounts (a "scale-out" / partitioning strategy) rather than overloading one. Ingress/egress vary by region and redundancy, so treat the numbers as planning guidance, not contractual maximums.

Key takeaways

• D-S-S-M-A: Durable, Secure, Scalable, Managed, Accessible — the five platform promises.
• Four core data services = B-F-Q-T: Blob, Files, Queue, Table. Disks, Elastic SAN, Container Storage, NetApp Files sit around the platform.
• The storage account is both a globally unique namespace and the management/billing boundary; name = 3–24 chars, lowercase + digits, globally unique. Type can't be changed after creation.
• Hierarchy is always account → service → container/share/queue/table → object.
• Endpoint = https://<account>.<service>.core.windows.net; the four subdomains are blob / file / queue / table. Don't cache the IP.
• Blob types = BAP: Block (general), Append (logs), Page (disks).
• Azure Files speaks SMB/NFS so it mounts like a network drive.
• Scale targets are per account (~5 PiB, ~20k req/s); scale out across accounts when a single one isn't enough.

Exercises

1. Recall. List the four core Azure Storage data services and the kind of data each holds.
2. Recall. What are the three naming constraints for a storage account name?
3. Applied. An account is named contosologs. Write the full standard endpoint URL for a queue named events, and for a blob named 2026/app.log inside container app.
4. Applied. A team needs append-only storage for VM log lines, and separately a VHD that backs an Azure VM disk. Which blob type fits each, and why?
5. Scenario. An analytics pipeline pushes data so hard that one storage account is hitting its request-rate ceiling, and uploads are throttling. Without changing the workload's logic, what is the standard architectural fix, and why does it work?
6. Concept. A teammate says "let's just change this Standard GPv2 account to a Premium block blob account to get lower latency." What's wrong with that plan, and what must you do instead?

Coming up next

Sequence 2 — Create & Configure Storage Accounts: turning this architecture into a real account — choosing the type/performance/redundancy, naming, and the portal/CLI/PowerShell creation workflow.