In an AZ-305 messaging scenario, first decide whether the payload carries work a service must process or only announces that something happened. Microsoft's Architecture Center draws the line. A command is a high-value message with strict delivery requirements, and duplicate processing can cause erroneous transactions like duplicate orders or double billing. An event announces that something happened, and the publisher has no expectation that anything specific will happen in response. Durable business commands go to a Service Bus queue. Discrete state-change events go to Event Grid. High-volume telemetry and log streams go to Event Hubs. A simple backlog that needs no broker features goes to Azure Queue Storage.
Microsoft's AZ-305 study guide lists "Recommend a messaging architecture," "Recommend an event-driven architecture," and "Recommend a solution for API integration" as tasks under "Design an application architecture," inside the "Design infrastructure solutions" skill area (30-35% of the exam, skills measured as of April 17, 2026). The English version of the AZ-305 exam was updated on April 17, 2026 and has no retirement date; check the page for further updates before you book.
Match the shape of the communication to the service
- 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 ingestion: Event Hubs.
- Simple async backlog at storage-account pricing, 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.
The first five rows are the messaging decisions (Service Bus queues, Service Bus topics, Event Grid, Event Hubs, and Queue Storage). The last four cover scenarios that are really about workflow, code triggers, API exposure, or devices.
The decision flow at a glance
Feature differences between the three services
Microsoft's comparison of the three services (last updated 2026-06-12):
| Attribute | Event Grid | Event Hubs | Service Bus |
|---|---|---|---|
| Primary purpose | Reactive event routing | Big data streaming and ingestion | Enterprise transactional messaging |
| Data model | Events (discrete notifications) | Event streams (time-ordered series) | Messages (high-value payloads) |
| Delivery | At least once | At least once | At least once (optional ordered, exactly once with sessions) |
| Ordering | No guarantee | Per partition | FIFO (sessions) |
| Transactions | No | No | Yes |
| Duplicate detection | No | No | Yes |
| Dead-lettering | Yes | No | Yes |
| Capture and replay | No | Yes (Event Hubs Capture) | No |
| Pick when the stem says | a state change happened and something should react | a high-volume stream that consumers replay or analyze | a high-value command that must not be lost or doubled |
If the stem lists sessions, transactions, duplicate detection, or topics, Microsoft's direct comparison of the two queue services points up to Service Bus.
Service Bus carries the command
The cue in the stem is a business consequence: "submit order," "reserve inventory," "process payment," "fan out to fulfillment and billing." When the payload is a command, the service must guarantee the work happens, and the question starts asking for broker behavior. Microsoft describes Service Bus as a fully managed enterprise message broker with message queues and publish-subscribe topics, used to decouple applications and coordinate transactional work (Service Bus overview).
A queue holds the command for competing consumers. A topic with subscriptions copies the message to each subscriber, which is the one-to-many business case where fulfillment and billing each need their own durable copy. Sessions give FIFO processing for a conversation, and the same documentation lists duplicate detection (the queue or topic discards duplicate copies when a client resends after a doubtful send), transactions, and a dead-letter queue that holds what consumers cannot process.
The trap is the word "event" inside a command scenario. If the producer only announces a state change and the consumer can tolerate a duplicate, Event Grid is the simpler answer. If duplicate processing would create a bad transaction, the command belongs on Service Bus.
Event Grid delivers the notification
Event Grid is a push service. A publisher announces a system state change, and Event Grid delivers that event to subscribed endpoints over HTTP, with MQTT support for device data. It is a highly scalable, fully managed publish-subscribe service for message distribution, and it supports the CloudEvents 1.0 specification so events interoperate across systems (Event Grid overview).
The cue is a discrete event: blob created, resource changed, file uploaded, item shipped. Azure Resource Manager raises events when it creates, modifies, or deletes resources, and a Logic App or Function can subscribe and act. The push model is what fits designs that must stop polling.
Delivery is at least once per subscription. Event Grid retries on an exponential backoff schedule, and if you configure a dead-letter destination it sends undelivered events to a storage account. Without that configuration it drops them (Event Grid message delivery and retry).
That retry-and-dead-letter behavior is what makes Event Grid look like a queue. It is still the wrong home for a high-value command. When the stem needs sessions, transactions, duplicate detection, or a dead-letter queue for business commands, Event Grid's push-and-retry model is not enough, and the command belongs on Service Bus.
Event Hubs moves the stream
When the stem is about volume, Event Hubs is the service. It is a fully managed, real-time data streaming platform that can ingest millions of events per second with low latency, and it natively supports Apache Kafka, AMQP 1.0, and HTTPS, so existing Kafka workloads run without code changes (Event Hubs overview).
The semantics are partitions and consumer groups. Producers append events to partitions, and consumer applications read from partitions through consumer groups, each tracking its own offset. Events stay durably with configurable retention, 1-90 days depending on tier, so a consumer can restart from an earlier point in time. Event Hubs Capture writes the stream to Azure Blob Storage or Azure Data Lake Storage in near real time for long-term retention or batch analytics.
High throughput alone does not make a stream a command pipeline.
Queue Storage covers the simple backlog
In Microsoft's direct comparison of the two queue services, storage queues are designed to support standard queuing scenarios, such as decoupling application components, load leveling, and building process workflows.
The cue is simplicity. A web app places work on a queue, workers drain it, and the stem asks for no sessions, transactions, duplicate detection, topics, or subscriptions. You also get storage-account pricing.
If the scenario adds high-value business commands, ordered message groups, duplicate detection, or durable publish-subscribe, move from Queue Storage to Service Bus.
The adjacent services for non-messaging parts of the scenario
Azure Functions is the code side of the integration. A trigger defines when a function runs, and a binding connects it to a queue, Event Grid, or another service. If the question asks what code runs when a message or event arrives, the answer is a function.
Logic Apps is the workflow layer. It is built for managed workflows, connectors, B2B and EDI integration, and low-code orchestration with services such as Service Bus and Functions. It is the answer when the stem emphasizes connectors, approvals, or long-running coordination.
API Management governs synchronous API exposure. It publishes, protects, observes, and governs APIs for applications and partners. A partner order-status lookup goes through API Management in front of the API, not through an event broker.
IoT Hub covers the scenarios where devices are first-class citizens. It pairs high-volume telemetry ingestion with device identity, bidirectional cloud-to-device communication, and device management. A stem that names device registration, firmware updates, or cloud-to-device commands is pointing at IoT Hub.
One retail scenario uses all four
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.
Checkout submission is a high-value command, so it goes to a Service Bus queue for the initial order-processing step. If multiple business teams need durable copies of the order event, a Service Bus topic with subscriptions feeds each of them rather than trying to make one queue serve every team. The product-image upload is a discrete state change, so Event Grid notifies a Function or Logic App to start the thumbnail work. Mobile telemetry is a stream, so Event Hubs ingests it for real-time and later analytics. The admin report backlog stays simple, so Queue Storage handles it. The partner order-status lookup is synchronous, so API Management sits in front of the API.
What a wrong answer tells you
- If you choose Event Hubs for order processing, you over-weighted throughput and missed command reliability.
- If you choose Event Grid for a payment workflow, you confused a notification with a business command.
- If you choose Service Bus for every Azure service notification, you ignored Event Grid's distribution role.
- If you choose Queue Storage for ordered business processing, you missed sessions, duplicate detection, and dead-letter needs.
- If you choose API Management for background work, you treated a synchronous API and asynchronous messaging as the same pattern.
After each wrong answer, write one sentence that names the boundary you missed. "I picked the wrong service because I missed the difference between ____ and ____." That is faster than rereading every messaging page.
Check the boundary with the free assessment
Take the free AZ-305 assessment. It returns a Readiness Report and your top gaps, so you can see whether the integration questions you miss cluster on one boundary, like command versus event. Then label the boundary on each missed question and retest with a similar scenario before moving on.