AZ-305 Messaging and Event Architecture: Service Bus, Event Grid, Event Hubs, or Storage Queues?

For AZ-305 messaging scenarios, start with the shape of the communication, not the product name. Use Azure Service Bus when a business command must be processed reliably, such as order fulfillment, payment workflow, or work that needs queues, topics, dead-lettering, duplicate detection, transactions, or sessions. Use Azure Event Grid for discrete event notifications such as "blob created" or "resource changed." Use Azure Event Hubs for high-throughput telemetry or log streams that consumers read with their own offsets. Use Azure Queue Storage for simple, low-friction queue backlogs when enterprise broker features are not required.

That boundary is exam-relevant: Microsoft's AZ-305 study guide lists "Recommend a messaging architecture," "Recommend an event-driven architecture," and "Recommend a solution for API integration" under application architecture (AZ-305 study guide). Microsoft's Azure Architecture Center also separates commands, events, and broker technology choices across Service Bus, Event Grid, and Event Hubs (Azure asynchronous messaging options). The English AZ-305 exam page says the exam was updated on April 17, 2026 and has no retirement date (AZ-305 exam page).

Compact decision shortcut

• Business command or workflow step: Service Bus queue.
• One message copied to multiple durable business consumers: Service Bus topic and subscriptions.
• Discrete state-change notification: Event Grid.
• Telemetry, clickstream, logs, or Kafka-like ingestion: Event Hubs.
• Simple async backlog with storage-account economics and no broker features: Queue Storage.
• Human or SaaS workflow orchestration: Logic Apps.
• Code that reacts to a trigger: Azure Functions.
• Synchronous API exposure, governance, or partner onboarding: API Management.
• Device identity, device management, and cloud-to-device commands: IoT Hub, not raw Event Hubs.

Decision-flow diagram

This diagram is intentionally small: it is not a full Azure integration architecture. It is a pressure-test for AZ-305 answer choices.

Service Bus: reliable business messaging

Choose Service Bus when the message represents work that a consumer must process, not just a fact that happened. Microsoft describes Service Bus as a fully managed enterprise message broker with queues and publish-subscribe topics, used to decouple applications and coordinate reliable work (Service Bus overview).

The exam clue is usually business consequence: "submit order," "reserve inventory," "process payment," "fan out to fulfillment and billing," or "retry failed work." Service Bus queues support competing consumers and durable buffering. Service Bus topics and subscriptions fit one-to-many business processing where each subscriber needs its own durable copy; Microsoft describes topics and subscriptions as one-to-many publish-subscribe where each subscription receives a copy of the message (Service Bus queues, topics, and subscriptions). Microsoft also documents sessions for FIFO-style processing, duplicate detection, transactions, scheduled delivery, and dead-letter queues, which are strong signals that the scenario needs Service Bus rather than a simpler event notification service.

Boundary: do not use Service Bus only because the word "event" appears. If the producer is only announcing a state change and does not require durable business-command processing, compare Event Grid.

Event Grid: discrete event distribution

Choose Event Grid when the publisher announces that something happened and subscribers decide what to do. Microsoft describes Event Grid as a highly scalable, fully managed publish-subscribe service for message distribution over HTTP and MQTT, used for data pipelines, application integration, and event-driven serverless architectures (Event Grid overview).

The AZ-305 clue is a discrete event: blob created, resource changed, file uploaded, item shipped, or subscription event received from an Azure service or partner. Event Grid is especially useful when the design should avoid constant polling and push events to Azure Functions, Logic Apps, webhooks, or other subscribers.

Boundary: Event Grid is not a queue replacement for high-value commands. Event Grid can retry delivery and can dead-letter undelivered events to storage when dead-lettering is configured, but that is different from choosing a broker for command processing (Event Grid message delivery and retry). If duplicate processing would create a bad transaction, or if the consumer needs broker features such as sessions, transactions, duplicate detection, and a command-oriented dead-letter queue, use Service Bus.

Event Hubs: streaming ingestion and replay

Choose Event Hubs when the requirement is ingesting a stream at scale. Microsoft describes Event Hubs as a fully managed real-time data streaming platform that can ingest millions of events per second and supports Kafka-compatible clients (Event Hubs overview).

The exam clue is volume plus stream semantics: telemetry, clickstream analytics, application logs, financial transaction streams, or many producers sending continuously. Consumers read from partitions through consumer groups and maintain their own position. Event Hubs Capture can write stream data to Blob Storage or Azure Data Lake Storage for later batch analysis (Event Hubs Capture).

Boundary: Event Hubs is not the default for every event-driven app. If the event is a single state-change notification, Event Grid is usually simpler. If the message is a high-value command in a business workflow, Service Bus is usually stronger.

Queue Storage: simple async backlog

Choose Azure Queue Storage when the design needs a simple queue to decouple components, create a backlog of work, or support a web-queue-worker pattern without enterprise broker features. Microsoft describes Queue Storage as a service for storing large numbers of messages, accessible over authenticated HTTP or HTTPS, with messages commonly used for asynchronous backlogs (Queue Storage overview).

The AZ-305 clue is simplicity: a web app places work onto a queue, workers drain it, and the scenario does not ask for sessions, transactions, duplicate detection, topics, subscriptions, or advanced broker behavior. Microsoft directly compares Storage queues and Service Bus queues and notes that Storage queues are designed for standard queuing scenarios such as decoupling components, load leveling, and workflows, while Service Bus adds stronger broker capabilities (Storage queues vs Service Bus queues).

Boundary: if the answer choice includes high-value business commands, ordered groups, duplicate detection, or durable publish-subscribe, move from Queue Storage to Service Bus.

Related integration boundaries

Azure Functions is usually a handler, not the broker. Microsoft Functions triggers define how a function runs, and bindings connect functions to services such as queues, Event Grid, and other resources (Functions triggers and bindings). Choose it when the question asks what code runs after a message or event arrives.

Logic Apps is the workflow boundary. Microsoft positions Logic Apps for managed workflows, connectors, B2B integration, and enterprise integration with services such as Service Bus, Functions, and API Management (Logic Apps overview). Choose it when the scenario emphasizes low-code orchestration, SaaS connectors, approvals, EDI, or long-running workflow coordination.

API Management is the synchronous API boundary. Microsoft describes API Management as a hybrid, multicloud API management platform that supports the full API lifecycle and helps expose, protect, observe, and govern APIs (API Management overview). Choose it when the design is about publishing APIs to apps or partners, not about asynchronous messaging.

IoT Hub matters when devices are first-class. Microsoft recommends IoT Hub for connecting IoT devices to Azure because it adds device identity, bidirectional communication, and device-management capabilities beyond Event Hubs-style ingestion (IoT Hub vs Event Hubs).

Worked scenario: retail order and telemetry platform

A retailer is modernizing order processing:

• Web checkout must submit orders without blocking the user interface.
• Payment, inventory, fulfillment, and email teams each need independent processing.
• A product-image upload should trigger thumbnail generation.
• The mobile app sends clickstream events and performance telemetry.
• A small admin tool needs a simple background queue for report export jobs.
• Partners need a governed API for order-status lookup.

Split the architecture before choosing services. The checkout submission is a high-value command, so use a Service Bus queue for the initial order-processing step. If multiple business teams need durable copies of the order event, use a Service Bus topic with subscriptions rather than trying to make one queue feed every team. The product-image upload is a discrete state-change event, so Event Grid can notify a Function or Logic App to start thumbnail work. The mobile telemetry is a stream, so Event Hubs fits ingestion and later analytics. The admin report backlog can use Queue Storage if it stays simple and does not need Service Bus features. The partner order-status lookup is synchronous API exposure, so place API Management in front of the API rather than forcing it through an event broker.

Exam-ready answer: one solution can use all four messaging services, but each component must earn its service. AZ-305 rewards the boundary, not a favorite product.

What wrong answers reveal

If you choose Event Hubs for order processing, you may be over-weighting throughput and missing command reliability. If you choose Event Grid for payment workflow, you may be confusing notifications with business commands. If you choose Service Bus for every Azure service notification, you may be ignoring Event Grid's event distribution role. If you choose Queue Storage for ordered business processing, you may be missing sessions, duplicate detection, and dead-letter needs. If you choose API Management for background work, you may be treating synchronous APIs and asynchronous messaging as the same integration pattern.

Turn each miss into one remediation sentence: "I picked the wrong service because I missed the difference between ____ and ____." That is faster than rereading every messaging page.

Where CramHQ fits

CramHQ is not a Microsoft product and does not guarantee a pass. For this topic, CramHQ can help turn missed AZ-305 integration questions into a targeted loop: identify whether the gap was command vs event, event distribution vs event streaming, simple queue vs enterprise broker, handler vs workflow, or async broker vs API gateway, then route practice and remediation around that boundary.

When you are ready, take the AZ-305 assessment. After each missed integration question, label the decision boundary first, then retest with a similar scenario before moving on.

Quick recap

Use Service Bus for reliable business commands and durable publish-subscribe. Use Event Grid for discrete event notifications. Use Event Hubs for high-throughput streams and replay-oriented analytics. Use Queue Storage for simple asynchronous backlogs. Keep Functions, Logic Apps, API Management, and IoT Hub in their own lanes: handlers, workflows, API governance, and device communication.