This post is a part of the AI-200: Developing AI Cloud Solutions on Azure  Exam Prep Hub.
This topic falls under these sections:
Connect to and consume Azure services (20–25%)
   --> Develop event- and message-based AI solutions
      --> Implement event-driven workflows by using Azure Event Grid, including filters, custom events, and retries

Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.

Overview

Modern AI applications frequently need to react to events rather than continuously poll systems for changes. For example:

• A document is uploaded and needs to be processed.
• A new customer record is created and should trigger enrichment.
• An AI model finishes processing a request.
• A database record changes and downstream systems need to respond.
• A custom application event needs to trigger a serverless workflow.

Azure Event Grid is an event-routing service designed to connect event producers with event handlers. It can receive events from Azure services, custom applications, and partner sources and route matching events to subscribers.

For the AI-200 exam, you should understand how to:

1. Design event-driven workflows with Event Grid.
2. Create and use custom events and custom topics.
3. Configure event subscriptions.
4. Filter events.
5. Understand Event Grid delivery and retry behavior.
6. Configure retry policies and dead-lettering.
7. Design consumers to tolerate duplicate or out-of-order events.

Event Grid is particularly useful when an application needs to react to something that has happened rather than explicitly requesting something to happen.

1. What Is Azure Event Grid?

Azure Event Grid is a managed event-routing service.

At a high level, the architecture looks like this:

Event source → Event Grid → Event subscription → Event handler

For example:

Blob Storage → Event Grid → Azure Function

A file upload can generate an event. Event Grid receives that event and routes it to an Azure Function, which processes the file.

Another example might be:

Application → Custom Event Grid Topic → Event Grid Subscription → AI Processing Service

The application publishes an event such as:

DocumentUploaded

Event Grid determines which subscriptions are interested in the event and delivers it to the appropriate handlers.

Event Grid supports system events from Azure services, custom application events, and partner events. It also provides filtering so subscribers receive only the events they need.

2. Event-Driven Architecture

An event-driven architecture separates the component that produces an event from the components that consume the event.

Consider an AI document-processing application.

A user uploads a document:

User
  |
  v
Blob Storage
  |
  | BlobCreated event
  v
Event Grid
  |
  +----> Document Processing Function
  |
  +----> Audit Function
  |
  +----> Notification Service

The Blob Storage service doesn’t need to know how each consumer processes the event.

This provides several advantages:

• Loose coupling
• Independent scaling
• Easier integration
• Asynchronous processing
• Multiple consumers
• Reduced polling
• Easier addition of new workflows

This is especially valuable for AI workloads because AI processing can be computationally expensive or time-consuming.

Instead of having an application constantly check whether something changed, an event can initiate processing only when necessary.

3. Important Event Grid Concepts

Several Event Grid terms are important for the AI-200 exam.

Event

An event describes something that happened.

Examples include:

ImageUploaded
DocumentCreated
OrderCompleted
ModelTrainingCompleted
CustomerCreated

An event generally contains information about the occurrence rather than instructions for what the receiver must do.

For example:

{
  "eventType": "DocumentUploaded",
  "subject": "/documents/invoice-123.pdf",
  "data": {
    "documentType": "invoice",
    "customerId": "C1001"
  }
}

Event Source

The event source is the system that generates the event.

Examples include:

• Azure Storage
• Azure resources
• Custom applications
• Partner services

Topic

A topic provides an endpoint through which events can be published.

For custom applications, you can create a custom topic and publish application-specific events to it.

For example:

OrderEvents

could receive:

OrderCreated
OrderUpdated
OrderCancelled
OrderCompleted

A custom topic allows an application to publish its own events without having to use an Azure service’s built-in event source.

Event Subscription

An event subscription tells Event Grid:

“Send matching events to this destination.”

A subscription connects an event source or topic to an event handler.

A subscription can define:

• Destination
• Event type filters
• Subject filters
• Advanced filters
• Retry behavior
• Dead-letter configuration

For example:

Custom Topic
     |
     +---- Subscription A → Azure Function
     |
     +---- Subscription B → Webhook
     |
     +---- Subscription C → Service Bus

Each subscription can independently determine which events it wants.

4. Event Handlers

The event handler is the destination that processes the event.

Depending on the Event Grid scenario, event handlers can include services such as:

• Azure Functions
• Azure Logic Apps
• Webhooks
• Azure Service Bus
• Azure Event Hubs
• Other supported Azure destinations

For AI applications, Azure Functions are particularly useful for lightweight event processing.

For example:

BlobCreated
     |
     v
Event Grid
     |
     v
Azure Function
     |
     +---- Extract text
     +---- Generate embedding
     +---- Store metadata
     +---- Update search index

5. Event Grid vs. Message Queues

A common exam distinction is between events and messages/commands.

Event Grid is primarily an event-routing service.

It is appropriate when you want to communicate:

“Something happened.”

For example:

DocumentUploaded

A messaging service such as Azure Service Bus is more appropriate when you need durable message processing, commands, queues, transactions, sessions, or more sophisticated competing-consumer patterns.

For example:

ProcessThisDocument

is more command-like.

A useful rule is:

The services can also be combined.

For example:

Blob Storage
     |
     v
Event Grid
     |
     v
Service Bus Queue
     |
     v
AI Worker

Event Grid detects the event, while Service Bus provides durable message-processing capabilities.

6. Custom Events

A custom event is an event generated by your own application rather than an Azure service.

For example, an AI application might generate:

DocumentClassificationCompleted

with data such as:

{
  "eventType": "DocumentClassificationCompleted",
  "subject": "/documents/12345",
  "data": {
    "documentId": "12345",
    "classification": "Invoice",
    "confidence": 0.97
  }
}

The application publishes the event to a custom Event Grid topic.

Other applications can subscribe to that topic.

For example:

AI Processing Application
          |
          | DocumentClassificationCompleted
          v
     Event Grid Topic
          |
          +------> Billing System
          |
          +------> Audit System
          |
          +------> Notification System

This provides a loosely coupled architecture.

The AI processing application doesn’t need to know which systems are consuming the event.

7. Custom Topics

A custom topic provides a user-defined Event Grid endpoint for publishing application events.

For example:

CustomerEvents

The application publishes events to the topic, and subscribers consume matching events.

A custom topic is appropriate when:

• Your application generates its own events.
• You need an application-specific event endpoint.
• You want multiple applications to subscribe to your events.
• You want Event Grid to perform routing and filtering.

The topic can support Event Grid or CloudEvents schemas depending on the configuration. Event Grid supports multiple event schemas, including Event Grid schema and CloudEvents schema.

8. Event Types

Event types identify what happened.

For example:

DocumentCreated
DocumentDeleted
DocumentProcessed
DocumentFailed

A single topic can publish multiple event types.

A subscriber may only be interested in one or two.

For example:

Topic
 |
 +-- DocumentCreated
 +-- DocumentUpdated
 +-- DocumentDeleted
 +-- DocumentProcessed

A subscription could specify:

Included event types:
DocumentProcessed
DocumentFailed

The subscriber would not receive the other event types.

Event type filtering is one of the simplest and most important forms of Event Grid filtering.

9. Event Filtering

Event filtering is one of the most important AI-200 concepts.

Suppose a topic receives thousands of events:

DocumentCreated
DocumentUpdated
DocumentDeleted
ImageUploaded
VideoUploaded

A particular Function might only care about:

DocumentCreated

Instead of sending every event to the Function and filtering them in application code, Event Grid can filter the events before delivery.

This reduces:

• Unnecessary network traffic
• Function executions
• Processing
• Cost
• Application complexity

Event Grid supports several filtering approaches.

10. Event Type Filtering

Event type filtering allows a subscription to receive only specific event types.

For example:

Included event types:
DocumentCreated
DocumentUpdated

Events such as:

DocumentDeleted

would not be delivered to that subscription.

This is appropriate when the routing decision is based primarily on the type of event.

11. Subject Filtering

Events have a subject that identifies the resource or object associated with the event.

For example:

/documents/invoices/2026/invoice-123.pdf

A subscription can filter based on whether the subject:

• Begins with a specified value
• Ends with a specified value

For example:

Subject begins with:
/documents/invoices/

would select events associated with invoice documents.

Another example:

Subject ends with:
.pdf

could be used to select PDF-related events.

Subject filtering is useful when the event type is the same but the resource or path differs.

12. Advanced Filtering

Advanced filtering provides more precise filtering based on event properties.

For example:

{
  "data": {
    "department": "finance",
    "priority": 5,
    "environment": "production"
  }
}

A subscription could filter on:

data.department = "finance"

or:

data.priority > 3

or:

data.environment = "production"

Advanced filters support different data types and operators, including string, numeric, Boolean, and array-based filtering.

13. Common Advanced Filter Operators

Important operators include:

String operators

Examples include:

StringIn
StringNotIn
StringContains
StringNotContains
StringBeginsWith
StringNotBeginsWith
StringEndsWith
StringNotEndsWith

Numeric operators

Examples include:

NumberIn
NumberNotIn
NumberLessThan
NumberLessThanOrEquals
NumberGreaterThan
NumberGreaterThanOrEquals

Boolean

BoolEquals

There are also operators for null/undefined values and range-based comparisons.

For the exam, focus on understanding why you would use advanced filtering rather than memorizing every operator.

14. Example: Advanced Filtering

Imagine the application publishes:

{
  "eventType": "DocumentUploaded",
  "data": {
    "documentType": "invoice",
    "priority": 8,
    "environment": "production"
  }
}

A subscription might filter for:

data.documentType = invoice

This means the subscriber only receives invoice events.

Another subscription might use:

data.priority >= 7

to receive only high-priority documents.

This is much more efficient than delivering every event and performing the filtering inside the application.

15. Combining Filters

You can use multiple filters to create more selective subscriptions.

For example:

Event Type = DocumentUploaded
AND
data.documentType = invoice
AND
data.environment = production

This creates a narrowly targeted event stream.

A good event design therefore includes meaningful event metadata.

For example:

{
  "eventType": "DocumentUploaded",
  "subject": "/documents/12345",
  "data": {
    "documentType": "invoice",
    "environment": "production",
    "priority": 8
  }
}

Good event metadata makes downstream routing much easier.

16. Designing Event Subjects

When designing custom events, don’t treat the subject as an arbitrary string.

A meaningful subject can make filtering easier.

For example:

/documents/invoices/2026/12345

is much more useful for routing than:

12345

A hierarchical subject can allow subscriptions to target broad or narrow groups of events.

For example:

/documents/invoices/

could represent all invoice documents.

A more specific path could identify:

/documents/invoices/2026/12345

This is particularly useful in large event-driven systems.

17. Event Delivery

Event Grid uses a push delivery model for many common Event Grid workflows.

When an event matches a subscription, Event Grid attempts to deliver it to the destination.

A successful HTTP response indicates successful delivery.

Event Grid considers HTTP status codes in the 200–204 range successful for delivery. Other responses are treated as failures and may result in retries or dead-lettering depending on the error and configuration.

18. At-Least-Once Delivery

One of the most important concepts for the exam is that Event Grid uses an at-least-once delivery model.

This means an event can potentially be delivered more than once.

For example:

Event published
     |
     v
Event Grid
     |
     +----> Consumer
              |
              +---- Processing succeeds
              |
              +---- Response delayed

If Event Grid cannot determine that delivery succeeded, it may retry.

The consumer could therefore receive the same event again.

Design implication

Event handlers should be idempotent whenever possible.

For example, instead of blindly performing:

Insert record

the consumer could use the event ID to determine whether it has already processed the event.

19. Event Ordering

Event Grid does not guarantee event ordering.

For example, an application might publish:

Event A
Event B
Event C

but the consumer could receive:

Event B
Event A
Event C

Therefore, applications that require strict ordering should not assume that Event Grid delivery preserves publication order.

If ordering is a hard requirement, another messaging design may be more appropriate.

20. Retry Behavior

If Event Grid cannot successfully deliver an event, it can retry delivery.

Event Grid uses an exponential-backoff-based retry schedule.

The current documented retry schedule includes progressively longer delays, beginning with short delays and eventually extending to hours. Event Grid may also delay or skip certain retries when an endpoint remains unhealthy.

The important exam concept is:

Event Grid does not immediately give up when an endpoint fails.

Instead, it attempts delivery again according to its retry behavior and configured retry policy.

21. Configurable Retry Policy

Event Grid allows you to configure two important retry limits:

1. Maximum delivery attempts
2. Event time-to-live (TTL)

The documented limits are:

If both are configured, whichever limit is reached first determines when Event Grid stops attempting delivery.

Example

Suppose you configure:

Maximum attempts = 5
TTL = 30 minutes

If the event reaches five attempts before 30 minutes:

Stop retrying

If 30 minutes expires before five attempts occur:

Stop retrying

The retry schedule itself is not directly configurable. You configure the limits, not the individual retry intervals.

22. Dead-Lettering

When an event can no longer be delivered within the configured retry policy, you may want to preserve it instead of losing it.

This is where dead-lettering comes into play.

Event Grid can send undeliverable events to an Azure Storage Blob container.

Conceptually:

Event Grid
    |
    | delivery failures
    v
Retry
    |
    | retry limit reached
    v
Dead-letter storage

Dead-lettering is not enabled automatically for every subscription. You configure a storage account/container as the dead-letter destination.

23. Why Dead-Lettering Matters

Dead-lettering is particularly important when events represent business-critical operations.

Suppose an AI application generates:

DocumentProcessingCompleted

and the downstream billing system is temporarily unavailable.

Without a dead-letter destination, an event that ultimately cannot be delivered may be dropped.

With dead-lettering:

DocumentProcessingCompleted
             |
             v
         Event Grid
             |
             v
       Billing System
             |
        delivery fails
             |
             v
          retries
             |
             v
      Dead-letter Blob

An operations team or automated process can later inspect and reconcile those events.

24. Important HTTP Failure Behaviors

Not all HTTP errors are treated identically.

For example, certain configuration-related errors such as:

400 Bad Request
403 Forbidden
413 Request Entity Too Large

can cause Event Grid to stop retrying rather than repeatedly attempting an endpoint that is unlikely to succeed.

Other failures can result in retries.

For example:

503 Service Unavailable

is a typical transient failure for which retry behavior is appropriate.

Exam takeaway

Do not assume:

“Every failed HTTP request is retried forever.”

Event Grid distinguishes between failures and applies its delivery and retry rules accordingly.

25. Dead-Lettering vs. Retry

These concepts should not be confused.

Retry

Retry means:

“Try delivering the event again.”

Dead-letter

Dead-letter means:

“The event could not be successfully delivered within the applicable delivery policy, so preserve it for later investigation or processing.”

The general workflow is:

Publish
   |
   v
Deliver
   |
   +---- Success → Done
   |
   +---- Failure
           |
           v
         Retry
           |
           +---- Success → Done
           |
           +---- Limits reached
                    |
                    v
              Dead-letter

26. Delayed Delivery

Event Grid also protects unhealthy endpoints through delayed delivery.

If an endpoint repeatedly fails, Event Grid can delay subsequent deliveries to avoid overwhelming an already unhealthy system.

This is important in high-volume AI workloads.

Imagine an AI endpoint can process only 100 requests per second but suddenly receives thousands of events.

Repeatedly retrying failures immediately could make the problem worse.

Event Grid’s retry and delayed-delivery behavior helps prevent this type of cascading overload.

27. Event Grid and Azure Functions

A common AI-200 scenario is:

Event Source
     |
     v
Event Grid
     |
     v
Azure Function

For example:

Blob uploaded
     |
     v
Event Grid
     |
     v
Function
     |
     +---- Extract text
     +---- Generate embedding
     +---- Store vector

This architecture provides several advantages:

• Serverless execution
• Automatic scaling
• Event-driven processing
• Loose coupling
• Reduced polling
• Integration with other Azure services

However, the Function should still be designed for retries and duplicate events.

28. Event Grid and AI Workloads

Event-driven architectures are particularly useful for AI applications.

Consider a document ingestion pipeline:

Blob Storage
      |
      | BlobCreated
      v
 Event Grid
      |
      v
Azure Function
      |
      +---- Extract content
      |
      +---- Generate embedding
      |
      +---- Store in PostgreSQL
      |
      +---- Publish DocumentIndexed
                       |
                       v
                  Event Grid
                       |
                       +---- Notify application
                       +---- Update analytics

This creates a pipeline in which each stage can react to the completion of another stage.

29. Example: AI Image Processing

Suppose an application receives images.

When an image is uploaded:

Image Upload
     |
     v
Blob Storage
     |
     v
Event Grid
     |
     v
Azure Function
     |
     +---- Computer vision analysis
     |
     +---- Store results
     |
     +---- Publish ImageAnalyzed

Another subscriber might listen for:

ImageAnalyzed

and update a search index.

A third subscriber might send a notification.

The original uploader does not need to know about these downstream processes.

30. Designing Reliable Event Handlers

Because Event Grid can deliver events more than once, consumers should be designed appropriately.

Make operations idempotent

An operation is idempotent when executing it multiple times produces the same intended result as executing it once.

For example:

Set document status = "Processed"

is naturally more idempotent than:

Increment processed-count

If an event is delivered twice, an increment operation could incorrectly increase the count twice.

Track Event IDs

Consumers can maintain a record of processed event IDs.

For example:

Event ID: 8f72...
Status: Processed

When the same event arrives again:

Event already processed

The consumer can safely ignore it.

31. Avoiding Long-Running Event Handlers

Event handlers should generally acknowledge events promptly when possible.

A common architecture for longer AI operations is:

Event Grid
     |
     v
Function
     |
     v
Service Bus
     |
     v
Long-running AI Worker

The Function receives the event and places a durable work item into Service Bus.

The worker can then perform the longer operation.

This separates event notification from workload processing.

32. Event Grid Filtering vs. Application Filtering

Consider two designs.

Design A

Event Grid
     |
     v
Function
     |
     +---- Check event type
     +---- Check priority
     +---- Check environment

Design B

Event Grid
     |
     | Filter
     v
Function

When the filtering criteria can be expressed through Event Grid subscription filters, Design B is generally preferable.

Benefits include:

• Less unnecessary invocation
• Lower processing overhead
• Less network traffic
• Lower cost
• Simpler application code

This is an important architectural principle.

33. Multiple Subscribers

One of Event Grid’s strengths is that multiple subscriptions can consume the same event stream independently.

For example:

CustomerCreated
       |
       v
   Event Grid
       |
       +---- Subscription 1 → CRM Function
       |
       +---- Subscription 2 → Analytics Function
       |
       +---- Subscription 3 → Notification Function

Each subscription can have its own:

• Destination
• Filter
• Retry configuration
• Dead-letter configuration

This allows one event to initiate multiple independent workflows.

34. Event Grid Delivery Batching

Event Grid normally delivers events individually.

For high-throughput scenarios, batching can be enabled.

Batching can improve HTTP efficiency by delivering multiple events in one request.

Current Event Grid push delivery supports configurable batch settings, including maximum events per batch and preferred batch size. Batching uses all-or-none semantics for a delivery request, so consumers must be able to process the entire delivered batch appropriately.

Exam consideration

If a question says:

“The application receives a very high volume of events and HTTP overhead is becoming significant.”

Consider event batching as a possible optimization.

35. Common Exam Scenario

Scenario

An AI application receives thousands of document events.

A Function should process only:

DocumentUploaded

events for:

/finance/

documents.

The best solution is to configure the Event Grid subscription with:

• Event type filtering
• Subject filtering

rather than sending every event to the Function.

The conceptual design is:

Event Grid
    |
    | Event Type = DocumentUploaded
    | Subject begins with /finance/
    v
Azure Function

This is more efficient than filtering inside the Function.

36. Common Exam Scenario: Custom Events

Scenario

A custom AI application needs to notify multiple independent applications whenever a document classification operation completes.

The application generates:

DocumentClassificationCompleted

Which Azure service should provide the event-routing mechanism?

Azure Event Grid is a natural choice.

A custom topic can receive the application’s events, and multiple subscriptions can route them to different handlers.

37. Common Exam Scenario: Temporary Endpoint Failure

Scenario

An Event Grid subscriber temporarily returns HTTP 503.

What should you expect?

Event Grid treats the delivery as unsuccessful and can retry according to its retry behavior.

This is different from simply assuming that the event is permanently lost.

38. Common Exam Scenario: Duplicate Events

Scenario

A Function processes an event successfully, but the response isn’t successfully acknowledged by Event Grid.

Event Grid may deliver the event again.

What should the Function do?

The Function should be designed to handle duplicate events safely.

Possible techniques include:

• Event ID tracking
• Idempotent writes
• Upsert operations
• Deduplication records
• Transactional processing where appropriate

The key concept is:

Do not assume exactly-once delivery.

39. Common Exam Scenario: Event Loss

Scenario

A critical event must not simply disappear if the subscriber remains unavailable.

What should you configure?

Dead-lettering should be considered.

Configure an Azure Storage Blob container as the dead-letter destination so undeliverable events can be preserved for later reconciliation.

40. Common Exam Scenario: Retry Configuration

Scenario

An application should stop trying to deliver an event after either:

• 10 delivery attempts, or
• 60 minutes.

The Event Grid subscription can be configured with:

Maximum delivery attempts = 10
TTL = 60 minutes

Whichever limit is reached first stops the delivery attempts.

41. Key Distinctions to Remember

For the AI-200 exam, remember these distinctions:

42. AI-200 Exam Tips

Tip 1: Event Grid is about events

If the question says:

“Something happened, and another service should react.”

Think:

Event Grid

Tip 2: Service Bus is different

If the scenario emphasizes:

• Commands
• Queues
• Durable messaging
• Competing consumers
• Sessions
• Transactional messaging

think:

Azure Service Bus

Tip 3: Filter before invoking

If Event Grid can filter an event, don’t automatically filter it in application code.

Event subscription filtering can reduce unnecessary processing.

Tip 4: Expect duplicates

Event Grid delivery should be treated as at least once.

Design consumers accordingly.

Tip 5: Don’t assume ordering

Event Grid does not guarantee event ordering.

Tip 6: Know retry limits

Remember:

Maximum delivery attempts
+
Event TTL

Whichever limit is reached first stops delivery attempts.

Tip 7: Know dead-lettering

Dead-lettering provides a place to preserve events that could not be delivered.

For Event Grid, the dead-letter destination uses Azure Blob Storage.

Tip 8: Understand the three major filter types

Remember:

Event type
Subject
Advanced properties

43. Summary

Azure Event Grid provides a managed mechanism for building event-driven applications by routing events from producers to subscribers.

For AI-200, the most important concepts are:

• Event sources produce events.
• Topics provide event publishing endpoints.
• Custom topics support application-generated events.
• Event subscriptions define routing.
• Event handlers process events.
• Event type filters select specific types of events.
• Subject filters select events based on their subjects.
• Advanced filters can evaluate event properties.
• Event Grid provides retry behavior for failed deliveries.
• Retry limits can be configured using maximum attempts and TTL.
• Dead-lettering can preserve events that cannot be delivered.
• Event delivery should be treated as at least once.
• Consumers should be designed to tolerate duplicates.
• Event ordering should not be assumed.
• Event Grid and Service Bus solve different messaging problems.
• Event Grid is particularly useful for loosely coupled, event-driven AI workflows.

The most important mental model is:

Something happens → Event is generated → Event Grid routes it → Matching subscription receives it → Handler processes it → Retry/dead-letter mechanisms provide resilience.

Practice Exam Questions

Question 1

An AI application publishes a DocumentProcessed event whenever document processing finishes. Several independent applications need to react to this event, and the producing application should not need to know which applications consume it.

Which Azure service is the best fit for routing these events?

A. Azure Event Grid

B. Azure Key Vault

C. Azure App Configuration

D. Azure Container Registry

Answer: A

Explanation

Azure Event Grid is designed for event routing and pub/sub scenarios. A custom topic can receive application-generated events, while multiple event subscriptions can independently route those events to different handlers.

Azure Key Vault manages secrets, App Configuration manages application configuration, and Container Registry stores container images.

Question 2

An Event Grid subscription should receive only events whose subject begins with:

/documents/invoices/

Which filtering mechanism should be used?

A. Advanced numeric filtering

B. Subject filtering

C. Event TTL

D. Maximum delivery attempts

Answer: B

Explanation

Subject filtering is specifically designed to select events based on the beginning or ending of an event’s subject.

TTL and maximum delivery attempts control delivery behavior rather than which events are selected.

Question 3

An application publishes the following event:

{
  "eventType": "DocumentUploaded",
  "data": {
    "department": "finance",
    "priority": 8
  }
}

A subscriber should receive only events where data.priority is greater than or equal to 7.

Which Event Grid capability should be used?

A. Subject filtering

B. Event TTL

C. Advanced filtering

D. Dead-lettering

Answer: C

Explanation

Advanced filtering allows subscriptions to evaluate properties within the event data using operators such as NumberGreaterThanOrEquals.

Subject filtering is appropriate for the event subject, while TTL and dead-lettering concern delivery reliability.

Question 4

An Event Grid subscriber temporarily returns HTTP 503 responses because the application is unavailable. What should you expect Event Grid to do?

A. Immediately delete all affected events

B. Permanently disable the subscription

C. Retry delivery according to its retry behavior and configured limits

D. Convert the events into Service Bus messages automatically

Answer: C

Explanation

HTTP 503 represents a service-unavailable condition. Event Grid can retry failed delivery using its retry behavior. Delivery continues until successful delivery or the applicable retry policy limits are reached.

Event Grid does not automatically convert the events into Service Bus messages or permanently disable the subscription.

Question 5

A critical Event Grid event cannot be delivered after the configured retry policy is exhausted. The organization needs to preserve the event for later investigation.

What should you configure?

A. A dead-letter destination in Azure Blob Storage

B. An Azure Container Registry

C. An Azure App Configuration store

D. An Azure Key Vault secret

Answer: A

Explanation

Event Grid supports dead-lettering to an Azure Storage Blob container. Undeliverable events can be stored there for later inspection and reconciliation.

The other services do not provide Event Grid dead-letter storage.

Question 6

An Event Grid subscription is configured with:

Maximum delivery attempts = 5
TTL = 60 minutes

The event reaches five delivery attempts after only 12 minutes. What happens next?

A. Event Grid continues retrying until 60 minutes have elapsed

B. Event Grid stops delivery attempts because the maximum attempt limit was reached

C. Event Grid automatically changes the maximum attempts to 30

D. Event Grid immediately sends the event to every other subscription

Answer: B

Explanation

When both maximum delivery attempts and TTL are configured, the first limit reached determines when Event Grid stops delivery attempts.

Because five attempts have occurred before the 60-minute TTL expires, the maximum-attempt limit is reached first.

If dead-lettering is configured, the event can then be dead-lettered.

Question 7

An AI application processes DocumentProcessed events. Occasionally, the same event is delivered twice. The application currently increments a counter every time it receives the event, causing inaccurate results.

What is the best design improvement?

A. Increase the event TTL

B. Disable event filtering

C. Make the event-processing operation idempotent

D. Increase the number of Event Grid subscriptions

Answer: C

Explanation

Event Grid uses at-least-once delivery semantics, so consumers must be prepared for duplicate events.

An idempotent operation can safely process the same event multiple times without producing an incorrect result. Event IDs can also be tracked to implement deduplication.

Changing TTL, filtering, or subscription count does not solve the fundamental duplicate-processing problem.

Question 8

An application generates its own events and needs an Event Grid endpoint to which it can publish those events.

Which resource should the application use?

A. Azure Service Bus session

B. Azure Event Hubs consumer group

C. Azure Storage queue

D. An Azure Event Grid custom topic

Answer: D

Explanation

A custom Event Grid topic provides a user-defined endpoint for applications to publish their own events.

Service Bus, Event Hubs, and Storage queues have different messaging purposes and do not represent the Event Grid custom-topic publishing model.

Question 9

An Event Grid subscription should receive only events of these types:

DocumentCreated
DocumentUpdated

It should not receive:

DocumentDeleted

Which configuration should be used?

A. Included event type filtering

B. Dead-lettering

C. Event TTL

D. Maximum delivery attempts

Answer: A

Explanation

Event type filtering allows a subscription to specify which event types it should receive.

The other options control delivery reliability rather than event selection.

Question 10

An AI application receives a very high volume of Event Grid events. HTTP request overhead is becoming significant, and the event-processing service can efficiently process multiple events in a single request.

Which Event Grid capability should be considered?

A. Dead-lettering

B. Event delivery batching

C. Subject filtering

D. Event TTL reduction

Answer: B

Explanation

Event Grid supports batching for push delivery. Instead of sending every event in an individual delivery request, multiple events can be delivered together.

Batching can improve HTTP efficiency in high-throughput scenarios. The consumer must be designed to process the batch appropriately because Event Grid uses all-or-none semantics for a batch delivery request.

Final Exam Takeaways

Before taking the AI-200 exam, make sure you can confidently answer these questions:

1. When should I use Event Grid?
   For event-driven routing and reacting to things that happened.
2. When should I consider Service Bus instead?
   When the scenario calls for durable messaging, queues, commands, sessions, or sophisticated message-processing patterns.
3. How do I create application-generated events?
   Publish them to an Event Grid custom topic.
4. How do I control which events a subscriber receives?
   Use event type, subject, and advanced filters.
5. What happens when delivery fails?
   Event Grid can retry according to its retry behavior.
6. What controls how long Event Grid retries?
   Event TTL and maximum delivery attempts.
7. What happens when delivery ultimately fails?
   With dead-lettering configured, the event can be stored in Azure Blob Storage.
8. Can an event be delivered more than once?
   Yes. Design consumers to tolerate duplicates.
9. Does Event Grid guarantee event ordering?
   No.
10. How can high-volume delivery be optimized?
    Consider event batching where the consumer supports it.

If you understand those ten points—and especially the distinctions between event filtering, retry, TTL, dead-lettering, and idempotent processing—you’ll have a strong foundation for the Event Grid portion of AI-200.

Go to the AI-200 Exam Prep Hub main page