Study guide

9.3 Event Grid: Custom Events & Filters

Exam AI-200: Developing AI Cloud Solutions on Azure Exam

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 Audience Profile & Study Path

2 Chapter 1: Container Registry & App Service Hosting

1.1 ACR: Build, Store, Version & Manage Images 1.2 ACR Tasks: Build & Run Images 1.3 Deploy Containers to Azure App Service

3 Chapter 2: Azure Container Apps & KEDA Scaling

2.1 Azure Container Apps: Environments, Config & Revisions 2.2 KEDA Event-Driven Scaling in Container Apps

4 Chapter 3: AKS Manifests & Container Troubleshooting

3.1 Deploy & Manage Apps on AKS with Manifests 3.2 Monitor & Troubleshoot AKS and Container Apps

5 Chapter 4: Cosmos DB for NoSQL Fundamentals

4.1 Cosmos DB for NoSQL: SDK Connect & Queries 4.2 Optimize RUs: Indexing Policies & Consistency Levels

6 Chapter 5: Cosmos DB Vectors & Change Feed

5.1 Embeddings & Vector Similarity Search in Cosmos DB 5.2 Change Feed Processor for New/Updated Items

7 Chapter 6: Azure PostgreSQL Foundations for AI

6.1 Azure Database for PostgreSQL: Connect & Query with SDKs 6.2 Schema Design, Data Types & Indexing Strategies 6.3 pgvector Indexing: Latency & Compute Overhead

8 Chapter 7: PostgreSQL Vector Workloads & RAG

7.1 Configure Compute, Memory & Storage for Vector Workloads 7.2 Vector Search, Semantic Retrieval & RAG with Metadata Filters 7.3 Connection Optimization for Throughput & Latency

9 Chapter 8: Azure Managed Redis for AI Solutions

8.1 Azure Managed Redis: Caching, Expiration & Invalidation 8.2 Redis Vector Indexing for Similarity Search

10 Chapter 9: Service Bus & Event Grid for AI Pipelines

9.1 Service Bus Queues & Message Processing 9.2 Topics, Subscriptions & Dead-Letter Queues 9.3 Event Grid: Custom Events & Filters 9.4 Event Grid Retries & Event-Driven Workflows

11 Chapter 10: Azure Functions for Serverless AI Back Ends

10.1 Azure Functions: Triggers & Bindings 10.2 Build Serverless APIs with Functions 10.3 Configure & Deploy Function Apps

12 Chapter 11: Key Vault & App Configuration

11.1 Azure Key Vault: Secret Storage & Retrieval 11.2 Key Vault Secret Rotation Patterns 11.3 Azure App Configuration for App Settings

13 Chapter 12: OpenTelemetry & KQL Observability

12.1 Distributed Tracing with OpenTelemetry SDKs 12.2 Correlating Traces into Azure Monitoring 12.3 Write KQL Queries to Analyze Logs 12.4 KQL for Metrics & Troubleshooting Scenarios

9.3 Event Grid: Custom Events & Filters

Key Takeaways Explain This Topic AI

Azure Event Grid is a reactive event routing service: publishers emit events, Event Grid pushes them to subscribed handlers based on filters

Custom topics (and partner/system topics) let your AI application publish domain events such as JobCompleted or SafetyFlagRaised

CloudEvents schema is the recommended interoperable event format alongside Event Grid’s native schema

Subscriptions use subject begins-with/ends-with, event types, and advanced filters on data fields to deliver only relevant events

Event Grid complements Service Bus: Event Grid for reactions to facts that occurred; Service Bus for durable command/work processing

Last updated: July 2026

Event-Driven AI with Azure Event Grid

Azure Event Grid delivers events from publishers to subscribers using a push model. Unlike a queue that workers poll, Event Grid invokes your endpoint (Azure Function, webhook, Logic App, Service Bus, Event Hubs, and more) when something happens. That makes it ideal for wiring AI platforms together: blob created → start ingestion; model deployment succeeded → refresh configuration; human review approved → resume generation.

The AI-200 skill calls out filters, custom events, and retries . This section focuses on custom events and filters; the next section covers retries and end-to-end workflows.

System Topics vs Custom Topics

Topic kind Source of events AI example

System topic Azure resource emits built-in events Storage account Microsoft.Storage.BlobCreated starts document intelligence

Custom topic Your application publishes events After embedding completes, publish Document.Embedded for search + UX

Partner topic SaaS partner integrates with Event Grid Third-party labeling tool signals dataset ready

Custom topics are first-class on the exam. You create a topic, obtain an endpoint and access keys (or use Microsoft Entra ID auth), and publish JSON events from your AI orchestration code. Subscribers never poll your database for status changes—they react to events.

Event Schemas: Event Grid Schema and CloudEvents

Event Grid accepts events in the Event Grid schema or CloudEvents (JSON) schema. CloudEvents is a CNCF standard widely used for interoperable event-driven systems and is the schema you should prefer for new AI solutions that may span tools and clouds.

  • A CloudEvents-style payload for an AI job might look like: {
  • "specversion": "1.0",
  • "type": "com.ExamFinch.ai.document.embedded",
  • "source": "/pipelines/embedding",
  • "id": "evt-3c91",
  • "time": "2026-07-19T18:04:00Z",
  • "subject": "documents/tenant-42/doc-7841",
  • "dataschema": "https://example.com/schemas/document-embedded.json",
  • "data": {
  • "documentId": "doc-7841",
  • "indexName": "kb-prod",
  • "chunkCount": 128,
  • "model": "text-embedding-3-large"
  • }
  • }

Key fields subscribers and filters rely on:

type / eventType — what happened.

source — which system produced it.

subject — path-like identifier of the affected entity (excellent for prefix filters).

id — unique event id for deduplication at the edge.

data — business payload (keep it small; link to blobs for large artifacts).

When publishing arrays, Event Grid accepts batches of events to a custom topic endpoint—useful when a batch embedding job completes many documents.

Event Subscriptions and Delivery Destinations

An event subscription attaches to a topic and defines:

Which events to receive (filters).

The destination (handler).

Retry and dead-letter settings (next section).

Common destinations in AI architectures:

Azure Functions (Event Grid trigger) — run lightweight glue: enqueue Service Bus work, update Cosmos DB status, call a Logic App.

Webhooks — notify an external SaaS or custom API.

Service Bus queue/topic — bridge from reactive events into durable competing consumers for heavy AI compute.

Event Hubs — stream events into analytics.

A frequent pattern: Storage BlobCreated (system topic) → Function validates MIME type → sends Service Bus message for OCR → on completion publishes custom Document.Embedded → multiple subscriptions update search and notify UI.

Filters: Deliver Only What Subscribers Need

Without filters, every subscriber receives every event on the topic—wasteful and risky. Event Grid filtering includes:

1. Event type filters — subscribe only to Microsoft.Storage.BlobCreated or your custom com.contoso.ai.job.failed .

2. Subject filters — subject begins with /documents/tenant-42/ and optional ends with .pdf so a tenant-specific pipeline ignores others.

3. Advanced filters — operators on event fields, including data payload keys:

StringContains , StringBeginsWith , StringEndsWith , StringIn

NumberGreaterThan , NumberInRange , etc.

  • BoolEquals
  • IsNull / IsNotNull

Example advanced filter ideas for AI:

data.chunkCount NumberGreaterThan 0 — skip empty documents.

data.model StringIn [ gpt-4o-mini , gpt-4o ] — route only certain model events to cost-control handlers.

data.safetySeverity StringIn [ high , critical ] — compliance Function only.

You can combine multiple advanced filters with AND semantics (all must match). Plan subjects and data properties up front so filters stay simple and indexed-friendly.

Custom Events from AI Application Code

Publishing custom events is typically:

Construct CloudEvents (or Event Grid schema) objects after a domain state change.

POST to the custom topic endpoint with the topic key or token.

Rely on Event Grid to authenticate delivery to subscribers (validation handshake for webhooks).

Webhook endpoint validation : Event Grid sends a subscription validation event; your endpoint must echo the validation code. Functions with Event Grid triggers handle this automatically—raw webhooks must implement it or the subscription never activates.

Event Grid vs Service Bus (Decide Deliberately)

Choose Event Grid when many independent handlers should react to a fact ( BlobCreated , EvaluationFinished ) with filters and push delivery.

Choose Service Bus when you need long-running competing consumers, sessions, transactions, or explicit command queues.

Choose both when Event Grid reacts instantly and then enqueues durable work onto Service Bus for the heavy AI lifting.

Exam Watch-Outs

Custom topics = your app publishes AI domain events.

CloudEvents fields ( type , subject , data ) are what filters and subscribers key off.

Advanced filters inspect event properties/data—know operators exist beyond simple subject prefix.

Event Grid pushes; it is not a durable work queue replacement for multi-minute GPU jobs by itself—bridge to Service Bus/Functions with async patterns when work is heavy.