Domain 3 · Connect to and consume Azure services
AI workloads are rarely a single request-response call. Documents arrive and need processing, inference runs long enough that you would rather not block on it, and results have to reach several downstream systems. This domain covers the plumbing: two messaging services with genuinely different purposes, and the serverless compute that reacts to both. Nearly every question reduces to picking the right one of the three for a described flow.
Azure Service Bus
Service Bus is the enterprise message broker — built for reliable, ordered, transactional messaging where consumers typically pull work when they are ready for it. Think of it as carrying commands that must each be processed exactly once, rather than announcements.
The two topologies are queues, where one message goes to one competing consumer, and topics with subscriptions, where each subscription receives its own copy of the message. Topics are how you fan one message out to several independent consumers without them interfering with each other, and filters on those subscriptions — SQL filters or correlation filters — route each message only to the subscribers that care about it.
The reliability features are where the exam concentrates:
- Dead-letter queue (DLQ) — messages that exceed MaxDeliveryCount or expire are moved aside, so a single poison message cannot block the queue behind it.
- Sessions — setting a
SessionIdguarantees FIFO ordering for that group and locks it to a single receiver, which is also what makes stateful processing possible. - Duplicate detection — messages whose
MessageIdwas already seen inside the detection window are discarded, giving you idempotent enqueue without writing the deduplication yourself.
A scenario that says "messages for one customer must be processed in order" is asking for sessions; one that says "the same order was submitted twice" is asking for duplicate detection.
Azure Event Grid
Event Grid solves a different problem. It is lightweight, reactive event routing that pushes discrete notifications to subscribers — announcements that something happened, not instructions to do work. Its sources include Blob Storage, resource groups, custom topics, and more.
Delivery is shaped by filtering: subject prefix and suffix matching (subjectBeginsWith / subjectEndsWith) plus advanced filters on fields inside the event data, so subscribers receive only what is relevant to them. For reliability, failed deliveries are retried with exponential backoff across the retry window, and you configure dead-lettering to a storage account to capture events that exhaust those retries.
Service Bus vs Event Grid
Because the two are so easily confused, it is worth holding the contrast explicitly:
| Service Bus | Event Grid | |
|---|---|---|
| Purpose | Reliable commands / messages | Reactive event notifications |
| Delivery | Pull (and push via subscriptions) | Push |
| Strengths | Ordering, sessions, transactions, DLQ | Fan-out, filtering, retries, low cost |
| Use when | A workflow must process each message reliably/in order | Many subscribers react to discrete events |
The shortcut: if losing or reordering an item would break a business process, it is Service Bus. If many consumers simply need to know an event occurred, it is Event Grid.
Azure Functions
Functions is the event-driven serverless compute that sits on the receiving end of both services above.
Each function has exactly one trigger — HTTP, timer, queue, Service Bus, Cosmos DB change feed, Event Grid, Event Hubs, Blob, and others — and that trigger defines what causes it to run. The Cosmos DB trigger is built on the change feed processor from Domain 2, which is why the "does it see deletes?" question follows you here.
Alongside the trigger come bindings, of which there may be zero or many: input bindings supply data to the function and output bindings send data out, both declaratively and with very little SDK code. A typical AI pipeline stage is a Service Bus trigger paired with a Cosmos DB output binding to persist the result — no client library, no connection management.
Hosting plans are a recurring exam topic because they encode a cost-versus-latency trade-off. Consumption is cheapest but can cold-start; Premium keeps pre-warmed instances so there is no cold start, and adds elastic scale and VNet integration; Dedicated runs on an App Service plan you already own. A scenario complaining about first-request latency on an inference endpoint is pointing at Premium.
Finally, secure configuration: use Key Vault references in app settings, resolved through a managed identity, so secrets are never hard-coded. local.settings.json exists for local development only and should never be the mechanism in a deployed environment — a theme Domain 4 takes up in full.
Quiz · Domain 3
A message in an Azure Service Bus queue repeatedly fails processing and exceeds its maximum delivery count. Where does it go, and why does this matter?