4.3 Azure Files, Queue, and Table Storage
Key Takeaways
- Azure Files provides fully managed cloud file shares accessible over SMB and NFS, mountable from Windows, Linux, and macOS, and cacheable on-prem via Azure File Sync.
- Azure Queue storage stores up to millions of small messages (max 64 KB each) to decouple and buffer work between application components.
- Azure Table storage is a NoSQL key-value/wide-column store where every entity is addressed by a PartitionKey plus a RowKey and can have a flexible set of properties.
- Table storage entities in the same partition can be updated in a batch transaction; cross-partition transactions are not supported.
- Azure Cosmos DB for Table is the premium, globally distributed alternative to Table storage with guaranteed low latency, automatic indexing, and SLAs.
Azure Files, Queue, and Table Storage
Blob storage gets most of the attention, but the same storage account offers three more services. DP-900 expects you to recognize the right one from a one-line scenario.
Quick Answer: Azure Files is a managed network file share (SMB/NFS) you can mount like a drive. Azure Queue storage holds small messages to buffer and decouple application components. Azure Table storage is a NoSQL key-value store where each row is found by a PartitionKey + RowKey and can carry a flexible set of columns.
Azure Files
Azure Files provides fully managed file shares in the cloud, accessible through the industry-standard SMB and NFS protocols. Because it speaks SMB, you can mount a share as a network drive on Windows, Linux, or macOS with the same UNC path semantics as an on-premises file server.
Key points:
- Lift-and-shift. Replace an aging on-prem file server with no application changes — the app still sees a
\\server\sharepath. - Shared access. Many VMs or containers can mount the same share simultaneously, useful for shared configuration, tools, or application content.
- Azure File Sync. Caches frequently used files on a local Windows Server while keeping the authoritative copy in Azure, giving branch offices fast local access with cloud durability.
- Identity-based auth. Supports Microsoft Entra / Active Directory authentication so existing NTFS permissions carry over.
Use Azure Files when an application or user expects a file system; use Blob when it expects objects accessed by REST or SDK.
Azure Queue Storage
Azure Queue storage is a simple, durable message queue for asynchronous communication. A producer puts a message on the queue and a consumer pulls it off later, so the two never have to be online at the same time.
| Property | Detail |
|---|---|
| Max message size | 64 KB |
| Queue capacity | Millions of messages, up to the storage account limit (500 TB) |
| Retention | Up to 7 days by default (configurable) |
| Delivery | At-least-once; consumer reads, processes, then deletes the message |
The classic pattern is load leveling: a web front end drops work items on a queue, and a pool of worker VMs or functions drains the queue at its own pace, smoothing traffic spikes. Note that for richer messaging (ordering, pub/sub, larger messages, sessions) Azure offers Service Bus — but plain Queue storage is the storage-account option DP-900 covers.
Azure Table Storage
Azure Table storage is a NoSQL key-value / wide-column store for massive amounts of semi-structured data that does not need relational joins or server-side stored procedures. It is cheap and scales to terabytes.
Every row is an entity identified by two values that together form the primary key:
- PartitionKey — groups related entities into a partition; the unit of scale-out and the scope of transactions.
- RowKey — uniquely identifies the entity within its partition.
Together, PartitionKey + RowKey is unique across the table and is the fastest possible lookup. Other properties are schemaless: two entities in the same table can have entirely different columns.
| Concept | Relational equivalent | Table storage |
|---|---|---|
| Table | Table | Table |
| Row | Row (fixed columns) | Entity (flexible properties) |
| Primary key | Single/compound key | PartitionKey + RowKey |
| Transactions | Across the database | Only within one PartitionKey (entity group transaction) |
Design rule: choose a PartitionKey that spreads load evenly but still groups data you query together. All entities sharing a PartitionKey can be updated in a single batch transaction; you cannot transact across partitions.
Table Storage versus Cosmos DB for Table
The exam frequently contrasts the two. Azure Cosmos DB for Table offers the same Table API but adds turnkey global distribution, guaranteed single-digit-millisecond latency, automatic indexing of every property, and financially backed SLAs. Plain Table storage is cheaper and simpler; Cosmos DB for Table is the premium choice when you need global reach, predictable performance, or rich querying. Code written against the Table API can often move from one to the other with only a connection-string change.
Picking Among the Four Storage Services
- Need to store any file/object by name? → Blob.
- Need a mounted network drive / SMB share? → Files.
- Need to buffer work between components asynchronously? → Queue.
- Need a cheap, flexible-schema key-value store? → Table (or Cosmos DB for Table for global, low-latency).
Azure Files Tiers and Protocols
Azure Files comes in performance tiers that mirror the blob idea: premium (SSD-backed, in a FileStorage account) for latency-sensitive workloads, and standard tiers (transaction optimized, hot, cool) on general-purpose v2 for general file shares. Shares support SMB (the Windows/Linux file-sharing protocol, with optional Entra/AD authentication so NTFS ACLs apply) and NFS (for Linux workloads, on premium shares). The exam tell for Azure Files is any mention of mounting a drive, UNC paths, SMB, NFS, or replacing a file server.
Queue Patterns in Practice
Queue storage enables three classic patterns. Load leveling smooths spikes: a front end enqueues work and a back-end pool drains it steadily. Load balancing lets multiple workers pull from one queue, each taking the next available message so work spreads automatically. Decoupling means producer and consumer need not be online simultaneously, improving resilience. Remember the at-least-once model: a consumer peeks/receives a message (making it invisible for a visibility timeout), processes it, then deletes it; if processing fails before deletion, the message reappears for retry.
Service Bus vs Queue Storage
The exam sometimes contrasts the two messaging options. Queue storage is simple, cheap, and part of the storage account — good for basic, high-volume buffering. Azure Service Bus is a separate enterprise messaging service adding FIFO ordering, topics/subscriptions (publish-subscribe), sessions, dead-letter queues, transactions, and larger messages. If a scenario needs ordering, pub/sub fan-out, or transactional messaging, the answer is Service Bus; if it just needs a cheap buffer, Queue storage suffices.
Table Storage Design and Query Cost
Queries against Table storage have a clear performance hierarchy that the exam may probe. The fastest query is a point query that supplies both PartitionKey and RowKey (an exact-match lookup). A partition scan (PartitionKey plus a filter on other properties) is slower. A table scan (no PartitionKey) is slowest because it touches every partition, so the partition-key design must group the data you most often query together while still spreading load.
Table storage has no joins, foreign keys, stored procedures, or server-side computation — those needs push you toward a relational database or, for global low-latency key-value, Cosmos DB for Table.
A development team is migrating an on-premises application that reads and writes shared documents from a Windows file server using UNC paths (\server\share). They want the cloud equivalent with no code changes. Which Azure Storage service should they use?
In Azure Table storage, how is each entity uniquely identified, and what is the scope of a batch transaction?