AI-200 connect to Azure services explained
Connect to and consume Azure services is worth 20–25% of AI-200. It has two parts: event- and message-based solutions with Azure Service Bus and Azure Event Grid, and serverless code with Azure Functions. The skill being tested is moving slow work — embedding documents, calling models, writing to databases — off the request path, and handling it reliably when something fails.
Service Bus or Event Grid?
The first decision in almost every messaging question.
| Service Bus | Event Grid | |
|---|---|---|
| Carries | Messages: a command or piece of work someone must process | Events: a notification that something happened |
| Delivery | Receiver pulls | Pushed to subscribers |
| Ordering | FIFO available with sessions | Not guaranteed |
| Failure handling | Retries, max delivery count, dead-letter queue | Retry policy with TTL, dead-letter to Blob Storage |
| Typical use | Order processing, background jobs, workload levelling | Reacting to a blob upload, a resource change, a custom app event |
If the scenario says “must be processed exactly once, in order” or “must survive the consumer being offline for hours”, think Service Bus. If it says “notify several independent handlers when a file lands”, think Event Grid.
Azure Service Bus
Queues, topics and subscriptions
A queue delivers each message to one competing consumer. A topic delivers a copy to each subscription, and each subscription can have filters — SQL filters on message properties, or cheaper correlation filters on fixed values — so that, for example, only high-priority orders reach one handler.
Receiving
- Peek-lock (the default for reliable processing): the message is locked, and you complete it on success or abandon it on failure. If the lock expires, it reappears.
- Receive-and-delete: removed on read. Fast, but a crash loses the message.
Dead-letter handling
Each queue and subscription has a dead-letter subqueue. Messages land there when:
- they exceed the maximum delivery count (10 by default), usually because processing keeps failing;
- their time-to-live expires, if dead-lettering on expiration is enabled;
- your code dead-letters them explicitly, with a reason, because it knows they can never succeed.
Nothing processes the dead-letter queue for you. A question describing messages that “disappear” after repeated failures is pointing at it, and the fix is a process that reads it, logs the reason and decides whether to repair, resubmit or discard.
Azure Event Grid
Custom events and filters
You publish your own events to a custom topic and create event subscriptions that deliver them to handlers such as a Function, a webhook or a Service Bus queue. Events use the Event Grid schema or the CloudEvents 1.0 schema.
Filters narrow what each subscription receives:
- Event type filters, such as only
Document.Created. - Subject filters with begins-with or ends-with, such as only subjects ending in
.pdf. - Advanced filters on values inside the event data.
Retries
Event Grid retries delivery with exponential backoff when a handler fails or is unreachable. The retry policy sets the maximum delivery attempts and the event time-to-live. When both run out, the event is dropped unless you configured dead-lettering to a storage container. Questions about events that were “lost” while a handler was down usually want dead-lettering enabled.
Azure Functions
Triggers and bindings
A trigger starts the function; there is exactly one. Bindings connect it declaratively to other services, as input or output, without writing client code.
| Need | Trigger or binding |
|---|---|
| A serverless REST endpoint | HTTP trigger |
| Process each queued message | Service Bus trigger |
| React to a published event | Event Grid trigger |
| React to new or changed documents | Cosmos DB trigger |
| Write a result without SDK code | Output binding, such as Cosmos DB or Service Bus |
In the Python v2 programming model, triggers and bindings are decorators on the function rather than entries in a separate function.json file. HTTP triggers carry an authorisation level — anonymous, function or admin — that decides whether a key is required.
Configure and deploy
- Hosting plans decide scaling and cold starts. Flex Consumption scales to zero and bills per use; Premium keeps pre-warmed instances; a Dedicated plan runs on App Service capacity you already pay for.
- App settings hold configuration and connection details. Binding connections should use managed identity-based connections rather than connection strings where supported.
- Deployment from the Core Tools with
func azure functionapp publish, or zip deploy from a pipeline.
Sample questions
Question 1. An order service publishes each order once. The billing, shipping and analytics services must each receive every order, and shipping must only receive orders where region equals EU. What should you implement?
- A. A single Service Bus queue read by all three services
- B. A Service Bus topic with three subscriptions and a filter on the shipping subscription
- C. Three Service Bus queues, with the publisher sending to each
- D. A Service Bus queue with its dead-letter queue used for EU orders
Show answer
Answer: B
A Service Bus topic delivers a copy of each message to every subscription, and a filter on the shipping subscription restricts it to EU orders. A single queue delivers each message to only one consumer. Three queues would require the publisher to send three times. A dead-letter queue is for failed messages, not routing.
Want more questions like this? Full AI-200 practice tests →
Question 2. An Event Grid subscription delivers events to a webhook. During a four-hour outage of the webhook, some events were lost after retries were exhausted. The team must be able to recover such events in future. What should you configure?
- A. Disable the retry policy so events fail fast
- B. Add an advanced filter on the event subscription
- C. Switch the topic to the CloudEvents 1.0 schema
- D. Enable dead-lettering to a Blob Storage container on the event subscription
Show answer
Answer: D
Dead-lettering on the event subscription writes undeliverable events to a storage container once retries and TTL are exhausted, so they can be replayed later. Turning retries off loses events sooner. An advanced filter changes which events are delivered, not what happens to failed ones. Switching schema does not affect delivery.
Want more questions like this? Full AI-200 practice tests →
Question 3. A Python Azure Function processes messages from a Service Bus queue and must write each result to Cosmos DB. The team wants no Cosmos DB client code in the function. What should you use?
- A. A Service Bus trigger and a Cosmos DB output binding
- B. A timer trigger that polls the queue and a Cosmos DB input binding
- C. An HTTP trigger and a Cosmos DB input binding
- D. An Event Grid trigger and a Service Bus output binding
Show answer
Answer: A
A Service Bus trigger starts the function for each message, and a Cosmos DB output binding writes the returned document without any SDK code. A timer trigger polls rather than reacting to messages. An HTTP trigger requires something to call it. An Event Grid trigger does not receive Service Bus queue messages directly.
Want more questions like this? Full AI-200 practice tests →
What to practise
Build one pipeline end to end: an HTTP-triggered Function that publishes to a Service Bus topic, two subscriptions with different filters, and a queue-triggered Function that throws on bad input. Send a bad message and watch it reach the dead-letter queue after ten attempts. Then publish a custom event to Event Grid, point it at an unreachable endpoint with dead-lettering on, and find the event in storage. After that, most questions in this domain describe something you have already seen.