This chapter covers Azure Queue Storage and Azure Table Storage, two core Azure Storage services under the 'Storage' domain of the AZ-104 exam. These services provide scalable, serverless message queuing and NoSQL key-value storage, respectively. While not as heavily tested as Blob or Disk Storage, they appear in roughly 5-10% of exam questions, often in scenarios involving decoupling application components or storing semi-structured data. Understanding their limits, pricing models, and security settings is critical for the exam.
Jump to a section
Imagine a large warehouse serving an e-commerce company. The warehouse has a conveyor belt system (Queue Storage) and a giant ledger book (Table Storage). The conveyor belt is used for moving items between different workstations—for example, from receiving to packing to shipping. Each item placed on the belt has a ticket with instructions. Workers can add items to the belt at any time, and other workers pick them up when ready. The belt is first-in-first-out, but items can be set aside (peeked) without removal. The ledger book, on the other hand, stores detailed records of every item: its ID, description, location, and status. Each record is a row in the ledger, and the ledger is organized by a partition key (like warehouse zone) and a row key (like shelf number). You can look up any item quickly if you know its zone and shelf. The ledger can hold billions of records. The conveyor belt handles transient messages (like 'pick item X from shelf Y'), while the ledger holds persistent structured data. If the belt gets too full, you add more belts (scale out). If the ledger gets too large, you split it into more volumes (partitions). Both are accessible via REST APIs, just like Azure Queue and Table Storage.
What Are Azure Queue and Table Storage?
Azure Queue Storage is a service for storing large numbers of messages that can be accessed from anywhere via authenticated HTTP/HTTPS calls. A single queue message can be up to 64 KB in size, and a queue can contain millions of messages. The primary purpose is to decouple application components, allowing asynchronous communication between them. For example, a web front-end can enqueue a message requesting a background job, and a worker role can dequeue and process it.
Azure Table Storage is a NoSQL key-value store that holds structured, non-relational data. It is schema-less, meaning each row (entity) can have different properties. Tables are partitioned automatically, and data is indexed by two keys: PartitionKey and RowKey. The maximum size of a table is 500 TB, and each entity can be up to 1 MB. Table Storage is ideal for storing massive amounts of data that require fast lookups by key, such as user profiles, device logs, or metadata.
How They Work Internally
Queue Storage:
- A message is added to a queue using the Put Message operation. The service assigns a unique ID and a visibility timeout (default 30 seconds).
- When a consumer retrieves a message via Get Messages, the message becomes invisible to other consumers for the visibility timeout period. The consumer must delete the message using Delete Message after processing. If not deleted within the timeout, the message becomes visible again (poison message handling).
- Messages can be peeked (without removal) using Peek Messages.
- Queue storage guarantees at-least-once delivery, but not exactly-once. Duplicate processing is possible if a consumer fails after retrieving but before deleting.
- The queue can be configured to store logs and metrics, and can be accessed via REST, .NET, Java, Python, etc.
Table Storage: - Entities are stored in a table and are identified by a composite key: PartitionKey + RowKey. The PartitionKey determines the partition (physical storage node), while RowKey is unique within that partition. - Table Storage supports queries by PartitionKey (fast), or PartitionKey + RowKey (very fast). Queries without PartitionKey are full table scans and should be avoided. - Data is stored in rows, and each row can have up to 252 custom properties plus three system properties: PartitionKey, RowKey, and Timestamp. - The service supports optimistic concurrency using ETags. When you update an entity, you must provide the original ETag; if it has changed, the update fails. - Table Storage is accessed via the Table REST API or Azure Storage SDKs.
Key Components, Values, Defaults, and Timers
Queue Storage: - Message size: max 64 KB (base64-encoded size is larger). For larger payloads, use a reference to a blob. - Queue name: 3-63 characters, lowercase letters, numbers, and hyphens. Must start with letter or number. - Visibility timeout: default 30 seconds, range 1 second to 7 days. - Time-to-live (TTL): default 7 days, max 7 days (can be set to -1 for no expiration). - Max queue size: 500 TB (total across all messages). - Max number of messages: unlimited. - Storage account type: must be General-purpose v2 or Blob storage (for queue storage, GPv2 is recommended). - Access: via shared key, shared access signature (SAS), or Azure AD (with appropriate role assignments).
Table Storage: - Table name: 3-63 characters, alphanumeric and hyphens, must start with letter or number. - Entity size: max 1 MB (including PartitionKey, RowKey, Timestamp, and properties). - PartitionKey: string up to 1 KB. - RowKey: string up to 1 KB. - Total table size: 500 TB per table. - Max entities per table: unlimited. - Query timeout: default 30 seconds. - Max results per query: 1,000 entities (unless using continuation tokens). - Indexes: only on PartitionKey and RowKey. No secondary indexes. - Storage account type: GPv2 or Blob storage (Table Storage is available in GPv2).
Configuration and Verification Commands
Using Azure Portal: - Navigate to your storage account, then under 'Data storage', click 'Queues' or 'Tables'. - Create a new queue/table, manage access policies, and view messages/entities.
Using Azure CLI:
- Create a queue: az storage queue create --name myqueue --account-name mystorageaccount --account-key <key>
- Add message: az storage message put --queue-name myqueue --content "Hello" --account-name mystorageaccount --account-key <key>
- Peek messages: az storage message peek --queue-name myqueue --account-name mystorageaccount --account-key <key>
- Create a table: az storage table create --name mytable --account-name mystorageaccount --account-key <key>
- Insert entity: az storage entity insert --table-name mytable --entity PartitionKey=PK1 RowKey=RK1 Name=John --account-name mystorageaccount --account-key <key>
- Query entities: az storage entity query --table-name mytable --partition-key PK1 --account-name mystorageaccount --account-key <key>
Using PowerShell:
- New-AzStorageQueue -Name myqueue -Context $ctx
- Add-AzStorageQueueMessage -Queue $queue -MessageText "Hello"
- Get-AzStorageQueueMessage -Queue $queue
- New-AzStorageTable -Name mytable -Context $ctx
- Add-AzStorageTableRow -Table $table -PartitionKey PK1 -RowKey RK1 -Property @{"Name"="John"}
- Get-AzStorageTableRow -Table $table -PartitionKey PK1
Interaction with Related Technologies
Azure Functions: Queue Storage is a common trigger for Azure Functions. When a message arrives, the function runs. This is a core pattern for serverless computing.
Logic Apps: Can read/write queues and tables as connectors.
Event Grid: Queue Storage can be used as a dead-letter destination for Event Grid events.
Blob Storage: Queue messages often reference blobs for large payloads.
Cosmos DB: Table Storage is an alternative to Cosmos DB's Table API. Cosmos DB offers global distribution, lower latency, and secondary indexes, but at higher cost. The exam may ask when to choose Table Storage vs. Cosmos DB Table API.
Performance and Scaling
Queue Storage: A single queue can handle up to 2,000 messages per second (assuming 1 KB messages). To scale beyond, use multiple queues or increase the number of workers.
Table Storage: A single partition can handle up to 2,000 entities per second. To scale, design with many partitions (high cardinality of PartitionKey). The target throughput for a storage account is 20,000 entities per second.
Latency: Queue and Table Storage typically have single-digit millisecond latency for reads/writes within the same region.
Security
Authentication: Shared key (account key), shared access signature (SAS), or Azure AD (RBAC). For Table Storage, Azure AD is supported but not for all operations (e.g., table creation still requires account key).
Encryption: Data is encrypted at rest by default (Azure Storage Service Encryption). In transit via HTTPS.
Firewall and Virtual Networks: Can restrict access to specific IP addresses or VNets.
Soft delete: Not available for queues or tables (only for blobs).
Create Storage Account
First, create a General-purpose v2 (GPv2) storage account in Azure. This is required because Queue and Table Storage are not available in Blob-only accounts. Choose a unique name (3-24 lowercase letters/numbers), select performance tier (Standard or Premium), and replication (LRS, GRS, etc.). Enable hierarchical namespace for Data Lake Storage if needed, but for queues/tables, leave it disabled. Once created, note the account name and key.
Create Queue or Table
In the Azure portal, navigate to the storage account, then under 'Data storage', click 'Queues' or 'Tables'. Click '+ Queue' or '+ Table' and enter a name. Queue names must be 3-63 characters, lowercase letters, numbers, and hyphens, starting with letter/number. Table names follow same rules. Alternatively, use Azure CLI or PowerShell. For example: `az storage queue create --name myqueue --account-name mystorageaccount --account-key <key>`.
Add Messages or Entities
For Queue Storage, add a message using `Put Message` REST API or SDK. The message can be up to 64 KB. Set visibility timeout (default 30s) and TTL (default 7 days). For Table Storage, insert an entity with PartitionKey and RowKey. The entity is a set of properties (name-value pairs). Use `Insert Entity` operation. For example, using CLI: `az storage entity insert --table-name mytable --entity PartitionKey=PK1 RowKey=RK1 Name=John --account-name mystorageaccount --account-key <key>`.
Retrieve and Process Messages
For Queue Storage, a consumer retrieves messages using `Get Messages` (default 1 message, max 32). The message becomes invisible for the visibility timeout. Process the message (e.g., decode, perform work), then call `Delete Message` to remove it. If processing fails, do not delete; the message will reappear after timeout. For Table Storage, query entities using PartitionKey and RowKey. Use `Query Entities` operation. Example: `az storage entity query --table-name mytable --partition-key PK1 --account-name mystorageaccount --account-key <key>`. Use continuation tokens if more than 1000 results.
Monitor and Scale
Monitor queue length and table throughput using Azure Monitor metrics (e.g., QueueMessageCount, TableEntityCount). If queue length grows, add more workers or increase the number of queues. For tables, ensure PartitionKey cardinality is high to distribute load. Use storage account metrics to check throttling (ServerBusyError). If throttled, consider splitting into multiple storage accounts or using Premium storage. Enable logging to diagnose issues.
Scenario 1: E-commerce Order Processing An online retailer uses Queue Storage to decouple order placement from fulfillment. When a customer places an order, the web front-end enqueues a message containing order ID and item details. A set of worker roles (Azure Cloud Services or Functions) dequeue messages, process payments, update inventory, and trigger shipping. This architecture ensures the web front-end remains responsive even during flash sales. In production, the queue handles thousands of messages per second. A common misconfiguration is setting the visibility timeout too low (e.g., 5 seconds), causing workers to compete for messages and duplicate processing. Best practice is to set timeout based on expected processing time plus buffer (e.g., 5 minutes).
Scenario 2: IoT Device Telemetry A manufacturing company collects sensor data from thousands of IoT devices. Each device sends a JSON payload (temperature, pressure, etc.) to an Azure Function that stores the data in Table Storage. The PartitionKey is the device ID, and RowKey is the timestamp (reverse chronological for latest-first queries). This allows fast lookups of a device's recent telemetry. The table stores billions of entities. A problem arises when queries are performed without PartitionKey, causing full table scans and high latency. The solution is to enforce PartitionKey in queries and use secondary indexes via Cosmos DB Table API if needed.
Scenario 3: Job Scheduling A media processing company uses Queue Storage to manage encoding jobs. Each message contains a reference to a source video blob and encoding parameters. Workers pick up messages and process videos. If a worker crashes, the message becomes visible again after timeout, ensuring no job is lost. They also use Table Storage to track job status (pending, running, completed, failed). The PartitionKey is the job type, and RowKey is the job ID. This allows easy monitoring and reporting. A common pitfall is not handling poison messages: if a message repeatedly fails, it will keep reappearing. They implement a dead-letter queue (another queue) by moving messages after a certain number of retries.
Performance Considerations: - Queue: For high throughput, use multiple queues and distribute messages. Each queue can handle 2,000 messages/sec. Use a queue per worker or per priority level. - Table: Design PartitionKey to distribute load. Avoid using a single PartitionKey for all entities. Target 2,000 entities/sec per partition. Use Premium Storage (Azure Files Premium or Blob Premium) for lower latency, but Table Storage on Premium is not available; use Cosmos DB instead. - Cost: Queue and Table Storage are cheap. Queue storage costs per message (e.g., $0.00005 per 10,000 messages) and storage ($0.02/GB). Table storage costs per GB and per transaction (e.g., $0.00036 per 10,000 transactions).
AZ-104 Objective Codes: This topic falls under 'Configure and manage storage' (2.2). Specifically, the exam tests: - 'Configure Azure Storage account settings' (including creating queues and tables) - 'Configure Azure Storage security' (SAS tokens, access policies) - 'Manage Azure Storage data' (adding, retrieving, deleting messages/entities)
Most Common Wrong Answers: 1. 'Queue Storage guarantees exactly-once delivery.' Reality: It guarantees at-least-once. Duplicates can occur if a consumer retrieves a message but fails to delete it before the visibility timeout expires. 2. 'Table Storage supports secondary indexes.' Reality: Only PartitionKey and RowKey are indexed. Queries on other properties require full table scans. 3. 'Queue messages can be up to 1 MB.' Reality: Max 64 KB. For larger payloads, store in Blob and reference via message. 4. 'Table Storage is a relational database.' Reality: It is a NoSQL key-value store with no joins, foreign keys, or stored procedures.
Specific Numbers and Values: - Queue message max size: 64 KB - Queue visibility timeout default: 30 seconds (range 1 sec to 7 days) - Queue TTL default: 7 days (max 7 days, or -1 for no expiry) - Table entity max size: 1 MB (including system properties) - Table max size: 500 TB - Table query max results: 1,000 (use continuation tokens) - Storage account type for queues/tables: General-purpose v2 (GPv2)
Edge Cases and Exceptions: - Queue Storage does not support ordering guarantees beyond FIFO (best-effort). For strict ordering, use Azure Service Bus. - Table Storage does not support transactions across partitions. Use Entity Group Transactions within the same partition. - When using Azure AD authentication with Table Storage, some operations (like creating a table) still require account key. - Soft delete is not available for queues or tables; only for blobs.
How to Eliminate Wrong Answers: - If a question mentions 'exactly-once delivery' for queues, eliminate it immediately. - If a question says 'secondary index' for tables, eliminate it. - If a question mentions 'relational queries' or 'SQL' for tables, eliminate it. - For queue limits, remember 64 KB. For table limits, remember 1 MB entity, 500 TB table. - When choosing between Queue Storage and Service Bus, Queue Storage is for simple message queuing; Service Bus supports topics, subscriptions, and advanced messaging patterns.
Queue Storage messages are limited to 64 KB; use Blob Storage for larger payloads.
Queue Storage provides at-least-once delivery, not exactly-once.
Default visibility timeout for queue messages is 30 seconds; can be set up to 7 days.
Default TTL for queue messages is 7 days; can be set to -1 for no expiration.
Table Storage entities are limited to 1 MB total, including PartitionKey and RowKey.
Table Storage indexes only PartitionKey and RowKey; queries on other properties are full table scans.
Table Storage supports Entity Group Transactions (batch) within the same partition.
Queue and Table Storage require a General-purpose v2 storage account.
Soft delete is not available for queues or tables.
For high throughput, design PartitionKey with high cardinality in Table Storage.
These come up on the exam all the time. Here's how to tell them apart.
Azure Queue Storage
Message size limit: 64 KB
Simple FIFO (best-effort) ordering
No support for topics/subscriptions
Max queue size: 500 TB
Lower cost per message
Azure Service Bus Queues
Message size limit: 256 KB (Standard) or 1 MB (Premium)
Guaranteed FIFO with sessions
Supports topics and subscriptions (pub/sub)
Max queue size: 80 GB (Standard) or unlimited (Premium)
Higher cost but richer features (dead-lettering, duplicate detection)
Azure Table Storage
No secondary indexes
Max entity size: 1 MB
Throughput: 2,000 entities/sec per partition
No global distribution (only RA-GRS)
Lower cost per GB
Azure Cosmos DB Table API
Supports secondary indexes
Max entity size: 2 MB
Throughput: virtually unlimited with partitions
Global distribution with multi-master
Higher cost but lower latency and SLA
Mistake
Queue Storage guarantees FIFO (first-in-first-out) order.
Correct
Azure Queue Storage does not guarantee strict FIFO. Messages are typically processed in order, but due to visibility timeout and parallel consumers, ordering can be disrupted. For strict FIFO, use Azure Service Bus with sessions.
Mistake
Table Storage is a fully relational database with SQL support.
Correct
Table Storage is a NoSQL key-value store. It does not support SQL queries, joins, foreign keys, or stored procedures. Queries are limited to PartitionKey and RowKey, with optional filtering on other properties.
Mistake
Queue messages can be up to 1 MB in size.
Correct
The maximum message size is 64 KB. For larger payloads, store the data in a blob and include the blob URL in the message.
Mistake
Table Storage automatically indexes all properties.
Correct
Only PartitionKey and RowKey are indexed. Queries on other properties require a full table scan, which is inefficient for large tables.
Mistake
Queue Storage provides exactly-once delivery.
Correct
Queue Storage provides at-least-once delivery. Messages can be delivered more than once if a consumer fails to delete them before the visibility timeout expires.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Since queue messages are limited to 64 KB, for larger payloads you should store the data in Azure Blob Storage and include the blob URL in the queue message. The consumer retrieves the message, reads the blob URL, and processes the data. This pattern is common for passing large files or binary data.
Yes, Azure AD authentication is supported for both Queue and Table Storage (with some limitations). For Queue Storage, you can assign RBAC roles like 'Storage Queue Data Contributor' to users or managed identities. For Table Storage, Azure AD is supported for data operations (e.g., query, insert) but not for management operations (e.g., create table) which still require the account key.
Queue Storage is a simple, cost-effective message queue with best-effort FIFO, 64 KB message limit, and large capacity (500 TB). Service Bus queues offer guaranteed FIFO (with sessions), larger messages (256 KB Standard, 1 MB Premium), dead-lettering, duplicate detection, and pub/sub via topics. Service Bus is more expensive but richer. Choose Queue Storage for high-volume, simple decoupling; choose Service Bus for enterprise messaging needs.
Always include PartitionKey in your queries to avoid full table scans. For point lookups, use both PartitionKey and RowKey. If you need to query on other properties, consider using Cosmos DB Table API (which supports secondary indexes) or maintain a separate index table. Use continuation tokens to paginate through results if more than 1,000 entities match.
No, you must read the entity first to obtain its ETag (for optimistic concurrency). When you update, you provide the ETag. If the entity was modified by another process, the update fails with a 412 (Precondition Failed). You can force an update by using '*' as ETag, but that bypasses concurrency checks.
The message becomes visible again in the queue and can be retrieved by another consumer. This is how poison messages are handled: if a consumer crashes, the message reappears. To avoid infinite loops, track the number of times a message has been dequeued and move it to a dead-letter queue after a threshold.
Table Storage is not available in Premium storage accounts (BlobStorage or FileStorage). It is only available in Standard General-purpose v2 (GPv2) accounts. For low-latency NoSQL, use Cosmos DB Table API instead.
You've just covered Azure Queue and Table Storage — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?