A junco-thicket customer's create, update, and cancel messages must run in order while other customers may interleave. What Service Bus feature should be enabled?
Select an answer to reveal the explanation.
Short Explanation
Need FIFO for one customer without freezing everyone else? Turn on sessions and set session id to the customer — ordering is per session, not global.
Full Explanation
Service Bus sessions give a junco-thicket customer FIFO ordering for messages that share a session id while other customers' sessions proceed in parallel. Setting the session id to the customer groups create, update, and cancel into one ordered sequence without freezing the entire queue behind a single global lock. Session-aware receivers accept a session, process its messages in order, then move on.
Azure Queue Storage visibility timeout keyed by customer id fails because visibility timeout only hides an in-flight message; it does not provide per-customer FIFO sessions on Storage queues. Event Grid subject filters named after each customer fail conceptually: they filter which events a subscription receives, not Service Bus ordered session processing. Cosmos DB ETag concurrency on the Service Bus namespace fails because ETags govern optimistic concurrency on documents—they are not a Service Bus session feature.
Exam caveat: enabling sessions changes receiver APIs—non-session receivers cannot consume a session-enabled entity, so clients and Functions bindings must be session-aware. Operational check: send ordered messages for two customer session ids, run session processors, and verify per-customer order while the two sessions interleave freely.