2.4.6. 💡 First Principle: Storage Accounts and the Four Data Services

First Principle: A storage account is the container that gives your data a unique namespace in Azure. Its core purpose is to be the single billing, security and redundancy boundary inside which four different data services live — so the question at exam time is rarely "which storage account?" but "which service inside it?".

What It Is: One storage account can hold four distinct kinds of data, each with its own shape and its own reason to exist:

• Blob storage — unstructured objects: images, video, backups, logs, anything you would think of as a file you never open with a database. Priced across Hot, Cool, Cold and Archive access tiers.
• Azure Files — a fully managed file share you mount over SMB or NFS, so an application that expects a drive letter or a mount point keeps working unchanged.
• Queue storage — a simple, durable message queue. One component drops a message in, another picks it up later. This is what decouples the parts of an application so a slow or failed consumer does not take the producer down with it.
• Table storage — a NoSQL key/value store for large volumes of structured but non-relational data, with no fixed schema and no joins. Cheap, fast lookups by key; not a relational database.

Key Concepts:

• Redundancy is set on the account, not per blob or per share — LRS, ZRS, GRS, GZRS and the read-access variants (see 2.4.4).
• Performance tiers: Standard accounts are backed by HDD and suit most workloads; Premium accounts are SSD-backed and are chosen per service (block blob, file share, or page blob) for low-latency needs.
• The account name is globally unique because it forms the service endpoint, for example mystorageacct.blob.core.windows.net.
• Disks are the exception: managed disks for virtual machines are their own resource type and are not created inside a general-purpose storage account.

Scenario: A retail application stores product photographs, needs a legacy reporting tool to read a mounted share, must absorb order submissions during a flash sale faster than the fulfilment service can process them, and keeps a large catalogue of product attributes that never needs a join.

Reflection Question: Four requirements, four different services in the same storage account. Which is which, and what would go wrong if you tried to serve the flash-sale spike out of Blob storage instead?

💡 Tip: Match on the shape of the data, not the size. Unstructured objects → Blob. Something that must be mounted → Files. Messages waiting to be processed → Queue. Schemaless structured rows looked up by key → Table.