This chapter covers Azure Queue Storage, a service for storing large numbers of messages that can be accessed from anywhere via authenticated HTTP/HTTPS calls. Queue Storage is a core part of Azure’s messaging and integration services, often used to decouple application components and build resilient, scalable systems. For the AZ-900 exam, this topic falls under Domain 2 (Azure Architecture and Services), Objective 2.4 (Describe Azure storage services). This objective area typically accounts for about 10-15% of the exam questions. Understanding Queue Storage helps you answer questions about asynchronous messaging, decoupling, and storage options.
Jump to a section
Imagine a busy online bakery that receives hundreds of orders per minute. The bakery can only bake 10 cakes at a time, but orders arrive much faster. Without a system, the baker would be overwhelmed, dropping orders or baking the wrong items. The solution is a digital order queue: each order is placed on a numbered ticket and stored in a first-in, first-out (FIFO) line. The baker picks one ticket at a time, bakes that cake, and marks it complete. If the oven breaks, orders pile up safely in the queue until the oven is fixed; no order is lost. The queue decouples the arrival of orders from the baking process. In Azure Queue Storage, messages (orders) are stored in a queue, and a worker (the baker) retrieves them one by one. The worker can process at its own pace, and the queue automatically handles spikes. If the worker crashes mid-bake, the message becomes visible again after a timeout, ensuring no task is lost. This is exactly how Azure Queue Storage works: it buffers messages between producers and consumers, providing reliable, asynchronous communication.
What is Azure Queue Storage and What Business Problem Does It Solve?
Azure Queue Storage is a cloud-based message queuing service that enables asynchronous communication between application components. It stores large numbers of messages—up to 500 TB per storage account—that can be accessed from anywhere via HTTP/HTTPS. Each message can be up to 64 KB in size.
The primary business problem it solves is decoupling. In a tightly coupled system, if one component (e.g., a web front-end) directly calls another component (e.g., a backend processor) and the backend is slow or unavailable, the front-end blocks or fails. This leads to poor user experience and scaling difficulties. Queue Storage introduces a buffer: the front-end places a message (e.g., 'process order #123') into a queue, and the backend retrieves messages at its own pace. If the backend goes down, messages accumulate safely in the queue. When it comes back up, it processes the backlog. This pattern is essential for building resilient, scalable cloud applications.
How Queue Storage Works – Step by Step
Create a Queue: You create a queue within an Azure Storage account. The queue is a simple container for messages. You can have many queues per storage account.
Add Messages: A producer component (e.g., a web app) adds a message to the queue using a PUT request. The message is stored as a base64-encoded string (up to 64 KB). Azure assigns a unique ID and a visibility timeout.
Retrieve Messages: A consumer component (e.g., a worker role) retrieves messages from the queue using a GET request. By default, messages are returned in FIFO order, but Azure does not guarantee strict FIFO in all scenarios (best-effort ordering). The consumer can request up to 32 messages at once.
Process and Delete: The consumer processes the message (e.g., resizes an image, sends an email). After processing, it sends a DELETE request to remove the message from the queue. This is crucial: if the consumer crashes before deleting, the message becomes visible again after the visibility timeout expires.
Visibility Timeout: When a message is retrieved, it becomes invisible to other consumers for a specified period (default 30 seconds, configurable up to 7 days). This prevents multiple consumers from processing the same message. If the consumer does not delete the message within the timeout, it reappears in the queue.
Key Components
Storage Account: The Azure resource that holds all storage objects (blobs, queues, tables, files). Queue Storage lives inside a storage account.
Queue: A container for messages. Queues are named with lowercase letters, numbers, and hyphens, starting with a letter or number.
Message: A unit of data (up to 64 KB) stored in the queue. Messages can be text or binary (base64-encoded).
Visibility Timeout: The period during which a retrieved message is hidden from other consumers.
Time-to-Live (TTL): The maximum time a message can stay in the queue before being automatically deleted. Default is 7 days, but can be set up to 7 days or infinite.
SAS (Shared Access Signature): A token that provides delegated access to the queue without exposing the account key.
Tiers and Pricing
Queue Storage is available in two performance tiers:
Standard: General-purpose storage with lower cost and moderate throughput. Suitable for most applications.
Premium: Higher throughput and lower latency, but more expensive. Premium queue storage is part of Azure Premium Blob Storage (Block Blobs). For queue scenarios, Standard is typically sufficient.
Pricing is based on: - Storage: Cost per GB of data stored in queues (including messages). - Operations: Cost per 10,000 transactions (e.g., PUT, GET, DELETE). - Data Transfer: Outbound data transfer costs apply.
On-Premises Equivalent
Before cloud, organizations used message queuing systems like IBM MQ, RabbitMQ, or MSMQ (Microsoft Message Queuing). These required dedicated servers, complex configuration, and manual scaling. Azure Queue Storage eliminates infrastructure management: you pay only for what you use, and Azure handles scaling, replication, and high availability. It's a fully managed service.
Azure Portal and CLI Touchpoints
Azure Portal:
Navigate to a Storage account → 'Queues' blade → 'Add queue' → give it a name.
Add a message: Click on the queue → 'Add message' → enter text (will be base64-encoded automatically).
View messages: Use 'Peek messages' to see the next messages without dequeuing.
Dequeue messages: Use 'Get messages' to retrieve and then delete.
Azure CLI:
# Create a storage account (if not exists)
az storage account create --name mystorageaccount --resource-group myRG --location eastus --sku Standard_LRS
# Get connection string
az storage account show-connection-string --name mystorageaccount --resource-group myRG
# Create a queue
az storage queue create --name myqueue --connection-string "<connection-string>"
# Add a message
az storage message put --queue-name myqueue --content "Hello, World!" --connection-string "<connection-string>"
# Peek at messages (without dequeuing)
az storage message peek --queue-name myqueue --connection-string "<connection-string>"
# Get and delete a message
az storage message get --queue-name myqueue --connection-string "<connection-string>"
az storage message delete --queue-name myqueue --id "<message-id>" --pop-receipt "<pop-receipt>" --connection-string "<connection-string>"Create a Storage Account
First, you need an Azure Storage account. In the Azure portal, click 'Create a resource' → 'Storage account'. Choose a subscription, resource group, and a globally unique name (only lowercase letters and numbers). Select performance tier (Standard is fine for queues) and replication (e.g., LRS for local redundancy). Review and create. Behind the scenes, Azure provisions the account and replicates it according to your chosen redundancy. This account will hold all your queues (and other storage types).
Create a Queue
Inside the storage account, navigate to the 'Queues' blade and click '+ Queue'. Enter a name (e.g., 'orderqueue'). Queue names must be lowercase, start with a letter or number, and can contain hyphens. Azure creates an empty queue container. No storage is consumed until messages are added. You can create multiple queues to separate different message types (e.g., orders, notifications).
Add Messages to the Queue
A producer application sends a message to the queue. In the portal, you can click 'Add message' and type text. The message is base64-encoded automatically. In code, you use the Azure Storage SDK to call `PutMessage`. The message is stored in the queue with a unique ID and a visibility timeout (default 30 seconds). The producer can set a custom visibility timeout or time-to-live. If the queue doesn't exist, the operation fails.
Retrieve and Process Messages
A consumer application retrieves messages. In the portal, click 'Get messages' to dequeue one or more messages (up to 32). The messages become invisible to other consumers for the visibility timeout period. The consumer processes the message (e.g., inserts data into a database). While processing, the consumer should not delete the message until processing is successful. If the consumer crashes, the message reappears after the timeout.
Delete the Message After Processing
After successful processing, the consumer sends a DELETE request with the message ID and pop receipt. In the portal, you can delete a message manually. This permanently removes the message from the queue. If you forget to delete, the message will reappear and be processed again (idempotency is important). Deleting ensures the message is not processed twice. The queue count decreases.
Scenario 1: E-commerce Order Processing
An online store receives thousands of orders per minute. The web front-end cannot directly process each order (validate payment, update inventory, send confirmation) because it would slow down the user experience. Instead, the front-end places an order message (containing order ID, customer info, items) into an Azure Queue. A backend worker (Azure Function or WebJob) retrieves messages one by one, processes the order, and deletes the message. If the backend scales up or down, the queue absorbs the load. If the payment gateway is slow, orders pile up safely. The team configures the visibility timeout to 5 minutes to allow for processing. They set TTL to 7 days to avoid stale orders. Cost is minimal: storage for messages and transactions per retrieval.
Scenario 2: Image Processing Pipeline
A photo-sharing app allows users to upload high-resolution images. The upload endpoint stores the image in Azure Blob Storage and adds a message to a queue with the blob URL. A separate worker (e.g., a VM running a batch job) polls the queue, retrieves the message, downloads the image, resizes it to thumbnails, uploads the thumbnails, and deletes the message. If the worker crashes, the message becomes visible again after the timeout, ensuring no image is missed. The team uses multiple workers to scale horizontally. They monitor queue length via Azure Metrics to trigger auto-scaling. Common mistake: not setting an appropriate visibility timeout, causing duplicate processing. Another mistake: forgetting to delete the message, leading to infinite loops.
Scenario 3: IoT Device Telemetry
A fleet of IoT sensors sends temperature readings every second. Each reading is a small JSON message. The sensors cannot connect directly to the database because of intermittent connectivity. They send messages to an Azure Queue. A backend service (running on Azure Container Instances) pulls messages in batches, aggregates them, and writes to Azure SQL Database. The queue decouples the sensors from the database, handling bursts. If the database is down, messages queue up. The team configures TTL to 24 hours because old data is irrelevant. They use SAS tokens for secure access from devices. Incorrect setup: using a single queue for all sensor types, making it hard to prioritize critical alerts.
What AZ-900 Tests on Queue Storage
AZ-900 tests your understanding of Azure Queue Storage as part of Objective 2.4: Describe Azure storage services. Specifically, you need to know:
The purpose of Queue Storage: to store large numbers of messages for asynchronous processing.
Common use cases: decoupling application components, building resilient systems, load leveling.
Key features: messages up to 64 KB, FIFO (best-effort) ordering, visibility timeout, TTL.
How it differs from other storage options (Blob, Table, Files).
Common Wrong Answers and Why
"Queue Storage guarantees FIFO delivery." – Wrong. Azure Queue Storage provides best-effort ordering, but not strict FIFO. The exam may present this as a true statement. The correct answer is that it does not guarantee FIFO; for strict ordering, consider Azure Service Bus.
"Messages can be up to 1 MB." – Wrong. The maximum message size is 64 KB. Candidates often confuse this with other services. If you see 1 MB, it's likely a trap.
"Queue Storage can be used for real-time messaging." – Wrong. Queue Storage is for asynchronous, decoupled communication, not real-time. For real-time, use Azure SignalR Service or Event Grid.
"Messages are automatically deleted after processing." – Wrong. The consumer must explicitly delete the message. If not deleted, the message reappears after the visibility timeout.
Specific Terms and Values
Maximum message size: 64 KB
Default visibility timeout: 30 seconds (can be set up to 7 days)
Default TTL: 7 days (can be set to infinite)
Maximum number of messages per retrieve: 32
Queue name rules: lowercase, start with letter/number, hyphens allowed
Storage account types: Standard (general-purpose) and Premium (for blobs, not queues)
Edge Cases and Tricky Distinctions
Queue Storage vs. Service Bus: Azure Service Bus is a more advanced messaging service with features like FIFO, topics, and dead-letter queues. Queue Storage is simpler and cheaper. The exam may ask which service to use for simple decoupling vs. enterprise messaging.
Visibility timeout vs. TTL: Visibility timeout controls how long a message is hidden after retrieval. TTL controls how long the message exists in the queue before being deleted automatically. Candidates often mix them up.
Idempotency: Because messages can be processed more than once (if the consumer crashes before deleting), your application should handle duplicates. The exam may ask about this design consideration.
Memory Trick: "QUED"
Q: Queue (store messages)
U: Up to 64 KB
E: Explicit delete required
D: Decouple components
When you see a question about decoupling application components, think Queue Storage. If the question mentions FIFO or larger messages, think Service Bus.
Azure Queue Storage stores large numbers of messages (up to 64 KB each) for asynchronous communication between application components.
Messages are retrieved by consumers; after processing, the consumer must explicitly delete the message to avoid reprocessing.
Default visibility timeout is 30 seconds; default TTL is 7 days.
Queue Storage provides best-effort FIFO ordering, not strict FIFO.
Use Queue Storage to decouple components, handle traffic spikes, and build resilient applications.
Queue Storage is part of Azure Storage; you need a storage account to create queues.
For advanced messaging features (FIFO, topics, dead-letter), use Azure Service Bus instead.
These come up on the exam all the time. Here's how to tell them apart.
Azure Queue Storage
Simple, lightweight message queuing.
Maximum message size: 64 KB.
Best-effort FIFO ordering.
No advanced features like topics or dead-letter queues.
Lower cost per transaction, suitable for high-volume simple messaging.
Azure Service Bus
Enterprise-grade messaging with advanced features.
Maximum message size: 256 KB (Standard tier) or 1 MB (Premium).
Guaranteed FIFO ordering (using Sessions).
Supports topics, subscriptions, dead-letter queues, and duplicate detection.
Higher cost, but includes features for complex integration scenarios.
Azure Queue Storage
Stores messages (up to 64 KB) in a queue for asynchronous processing.
Designed for decoupling application components.
Messages are temporary and deleted after processing.
Accessed via HTTP/HTTPS, supports REST API.
Pricing based on storage and transactions.
Azure Blob Storage
Stores large unstructured data (up to 8 TB per blob).
Designed for storing files, images, videos, backups.
Data persists until explicitly deleted.
Accessed via HTTP/HTTPS, supports REST API and SDKs.
Pricing based on storage capacity, access tiers, and transactions.
Mistake
Queue Storage guarantees first-in-first-out (FIFO) order.
Correct
Azure Queue Storage provides best-effort FIFO ordering, but does not guarantee strict FIFO. For guaranteed FIFO, use Azure Service Bus queues.
Mistake
Messages are automatically deleted after a consumer retrieves them.
Correct
Messages must be explicitly deleted by the consumer after successful processing. If not deleted, they become visible again after the visibility timeout.
Mistake
Queue Storage can store messages up to 1 MB in size.
Correct
The maximum message size is 64 KB. For larger payloads, store the data in Blob Storage and pass a reference in the queue message.
Mistake
Queue Storage is suitable for real-time messaging and event broadcasting.
Correct
Queue Storage is designed for asynchronous, decoupled communication. For real-time scenarios, use Azure SignalR Service or Event Grid.
Mistake
You can use Queue Storage without a storage account.
Correct
Queue Storage is part of Azure Storage. You must create a storage account before you can create queues. Each queue is scoped to a storage account.
The maximum message size is 64 KB. If you need to pass larger data, store the data in Azure Blob Storage and include the blob URL in the queue message. The exam often tests this value, so remember 64 KB.
Azure Queue Storage uses a visibility timeout mechanism. When a consumer retrieves a message, it becomes invisible to others. If the consumer deletes the message after processing, it is permanently removed. If the consumer fails before deleting, the message reappears after the timeout, ensuring it will be processed (at-least-once delivery). This makes the system reliable but requires idempotent consumers.
No. Queue Storage is designed for asynchronous, decoupled communication. It introduces latency because messages are stored and then polled. For real-time scenarios, use Azure SignalR Service or Event Grid. The exam may ask you to choose the correct service for a given requirement.
Queue Storage is simpler and cheaper, with messages up to 64 KB and best-effort FIFO. Service Bus is an enterprise messaging service with features like guaranteed FIFO, topics, dead-letter queues, and larger message sizes (256 KB Standard, 1 MB Premium). Choose Queue Storage for simple decoupling; choose Service Bus for complex integration.
Access can be secured using Azure AD (recommended), account keys, or Shared Access Signatures (SAS). SAS tokens provide delegated, time-limited access without exposing the account key. For production, use Azure AD with managed identities to avoid storing credentials in code.
The message remains invisible until the visibility timeout expires. Then it becomes visible again and can be retrieved by another consumer. This ensures the message is eventually processed (at-least-once delivery). To avoid duplicate processing, design your application to be idempotent.
Yes. When you add or retrieve a message, you can specify a visibility timeout from 1 second to 7 days. The default is 30 seconds. Setting a longer timeout gives the consumer more time to process, but if the consumer crashes, the message stays hidden longer.
You've just covered Azure Queue Storage — now see how well it sticks with free AZ-900 practice questions. Full explanations included, no account needed.
Done with this chapter?