A dock-weed order workflow needs peek-lock, sessions, and a dead-letter queue, but a teammate opens Event Hubs. Which service should the developer choose instead?
Select an answer to reveal the explanation.
Short Explanation
Peek-lock, sessions, and a DLQ scream Service Bus, not a telemetry firehose. Use Event Hubs for streams; park business orders on Service Bus.
Full Explanation
Peek-lock delivery, sessions, and a dead-letter queue are first-class Azure Service Bus messaging features for durable business workflows such as a dock-weed order pipeline. Service Bus holds commands until workers complete them, supports ordered session processing, and parks poison or explicitly dead-lettered messages for inspection—capabilities that match transactional order handling far better than a telemetry stream platform.
Event Hubs Capture so orders become Avro lake files only fails because Capture archives streams for analytics; it does not provide peek-lock command processing, sessions, or a business DLQ. Event Grid MQTT as the primary order command bus fails conceptually: Event Grid excels at discrete event distribution and MQTT scenarios, not Service Bus-style durable command semantics with sessions and DLQ. Azure Redis with a custom peek-lock wrapper fails because inventing lock/DLQ behavior in Redis abandons the managed messaging guarantees AZ-204 expects you to select as a service.
Exam caveat: Service Bus Standard/Premium feature sets differ (for example Premium adds richer isolation and higher scale); choose the tier that matches throughput and feature needs without assuming every SKU behaves identically. Operational check: create a queue or topic with sessions and duplicate detection as required, send a test message, receive with peek-lock, abandon once to prove redelivery, then dead-letter and confirm it lands on the dead-letter subqueue.