This chapter covers Azure Event Grid, a fully managed event routing service that enables event-driven architectures in Azure. For the AZ-900 exam, Event Grid falls under Domain 2: Azure Architecture and Services, Objective 2.2: Describe core Azure compute and networking services, but specifically it is part of the broader event-based messaging services. Understanding Event Grid is critical because it is a key differentiator for building reactive, serverless applications. This objective area carries approximately 15-20% of the exam weight, and Event Grid questions often appear as part of scenario-based items that test your ability to choose the right messaging service for a given requirement.
Jump to a section
Imagine you run a large office building with dozens of departments. You need to notify certain teams when specific events happen: mail arrives (reception), a package is delivered (shipping), a visitor signs in (security), or a meeting room is cleaned (facilities). Instead of having each department constantly check the front desk or call around, you install a central switchboard. The switchboard is Event Grid. Each event—like 'mail arrived'—is published to the switchboard. The switchboard has a list of subscribers: for 'mail arrived,' it might notify the mailroom and the recipient's assistant. The switchboard doesn't deliver the mail itself; it just sends a notification that mail is ready. The recipient then decides what to do (e.g., pick up the mail or have it forwarded). This is exactly how Event Grid works: it's a fully managed event routing service that takes events from publishers (like a storage account when a blob is created) and delivers them to subscribers (like an Azure Function or webhook) based on topic subscriptions. The switchboard mechanism is 'push'—Event Grid pushes the event to the subscriber as soon as it happens, unlike polling where the subscriber would have to keep asking 'Any mail yet?' Every event has a schema (like a standardized form) that includes the event type, subject, data, and time. Event Grid guarantees at-least-once delivery, meaning the switchboard will retry if a subscriber doesn't acknowledge receipt. This ensures no event is lost, just like a reliable receptionist who keeps trying until the department confirms they got the message.
What is Azure Event Grid and What Business Problem Does It Solve?
Azure Event Grid is a highly scalable, serverless event routing service that connects event sources (publishers) to event handlers (subscribers). It solves the problem of building reactive applications that need to respond to changes in state or actions occurring within Azure services, custom applications, or external systems. Without Event Grid, developers would have to build custom polling loops or message queues to detect events, leading to increased complexity, latency, and cost. Event Grid eliminates the need for constant polling by using a push model: as soon as an event occurs, Event Grid immediately delivers a notification to all interested subscribers. This enables real-time event-driven architectures where, for example, an image upload to Blob Storage can automatically trigger a thumbnail generation function, or a new resource group creation can trigger a compliance audit.
How Event Grid Works – Step by Step Mechanism
Event Grid operates on a publish-subscribe (pub/sub) model. The workflow is:
Event Sources (Publishers): An event source is any Azure service or custom application that generates events. Examples include Azure Blob Storage (when a blob is created or deleted), Azure Resource Manager (when a resource is created or modified), Azure IoT Hub (when a device sends telemetry), or a custom application that publishes events via HTTP. The publisher does not need to know who the subscribers are; it only sends the event to Event Grid.
Topics: Events are sent to a topic. A topic is an endpoint within Event Grid that collects related events. There are two types: system topics (automatically created by Azure services like Storage or Resource Manager) and custom topics (created by users for their own events). Each topic has a unique URL (e.g., https://<topic-name>.eastus-1.eventgrid.azure.net/api/events).
Event Subscriptions: A subscription defines which events from a topic should be delivered to which handler. It includes filters (e.g., only events where the subject starts with 'images/') and a destination endpoint (e.g., an Azure Function, a webhook, a queue, or a hybrid connection). Multiple subscriptions can exist on the same topic, allowing one event to trigger multiple actions.
Event Delivery: When an event occurs, the publisher sends an HTTP POST request to the topic endpoint with a JSON payload containing the event schema. Event Grid then evaluates all subscriptions on that topic, applies filters, and pushes the event to each matching subscriber endpoint. Delivery is at-least-once, meaning Event Grid will retry delivery if the subscriber does not return a success status code (200-299) within a timeout period. Retry policies include exponential backoff and a configurable maximum retry count (default 30, max 1 hour).
Event Schema: Every event includes standard fields: id (unique identifier), subject (path to the event subject), eventType (e.g., 'Microsoft.Storage.BlobCreated'), eventTime (timestamp), data (object with event-specific details), dataVersion, metadataVersion, and topic. The schema is documented and versioned.
Key Components, Tiers, and Pricing
Components: - Topics: System topics (automatically created by Azure services) and custom topics (created by users). - Event Subscriptions: Define filtering and delivery endpoints. - Event Handlers: Supported handlers include Azure Functions, Logic Apps, Webhooks, Azure Automation, Azure Queue Storage, Azure Service Bus, Event Hubs, and Hybrid Connections. - Event Domains: A management construct for grouping topics that belong to the same tenant or application, allowing centralized management and authentication.
Pricing: Event Grid uses a consumption-based model. You pay per million events published (including system events that originate from Azure services) and per million events delivered to subscribers. There is no upfront cost or reserved capacity. The first 100,000 operations per month are free. For example, publishing 10 million events per month would cost approximately $10 (at $1 per million operations) plus delivery costs. Filtering and retries do not incur additional charges beyond the initial publish/delivery.
Limits: Event Grid can handle millions of events per second with low latency (sub-second). Each topic can support up to 500 subscriptions. Event size is limited to 1 MB per event. For larger payloads, you should store the data in Blob Storage and include a reference URL in the event.
Comparison to On-Premises Equivalent
In an on-premises environment, building a similar event-driven system would require setting up a message broker like RabbitMQ or Apache Kafka, managing clusters, handling high availability, and writing custom code for filtering and retries. Developers would need to provision servers, configure networking, and monitor the broker's health. This introduces significant operational overhead. With Event Grid, Azure handles all infrastructure, scaling, and reliability. Additionally, Event Grid integrates natively with other Azure services, so you can subscribe to events from Blob Storage, Resource Manager, and many others without writing any custom integration code. The on-premises equivalent would require custom adapters for each event source.
Azure Portal and CLI Touchpoints
In the Azure Portal, you can create a custom topic under 'Event Grid Topics' and then create subscriptions. For system topics, they are often automatically created when you enable event notifications on a resource (e.g., Blob Storage 'Events' blade). The CLI provides full control:
Create a custom topic:
az eventgrid topic create --name myTopic --resource-group myRG --location eastusCreate a subscription to an Azure Function:
az eventgrid event-subscription create --name mySub --source-resource-id /subscriptions/.../resourceGroups/myRG/providers/Microsoft.EventGrid/topics/myTopic --endpoint-type azurefunction --endpoint /subscriptions/.../resourceGroups/myRG/providers/Microsoft.Web/sites/myFunctionApp/functions/myFunctionCreate a subscription with subject filtering:
az eventgrid event-subscription create --name filteredSub --source-resource-id /subscriptions/.../resourceGroups/myRG/providers/Microsoft.EventGrid/topics/myTopic --endpoint https://mywebhook.azurewebsites.net/api/events --subject-begins-with /images/You can also manage Event Grid with PowerShell, ARM templates, Bicep, and Terraform.
Concrete Business Scenarios
E-commerce order processing: When a new order is placed (event from an app), Event Grid triggers a Logic App that sends a confirmation email, updates inventory in a database, and creates a shipping label. This happens in real-time without polling.
Automated backup after resource creation: A subscription on Resource Manager events (system topic) triggers an Azure Automation runbook whenever a new VM is created, automatically adding it to a backup policy.
Serverless image processing: An image uploaded to Blob Storage triggers an Azure Function via Event Grid that resizes the image and stores thumbnails in another container. The subscriber (function) is invoked only when needed, reducing cost.
Edge Cases and Limitations
Ordering: Event Grid does not guarantee order of delivery for events from the same publisher. If order matters, use Service Bus or Event Hubs with partitions.
Exactly-once delivery: Event Grid guarantees at-least-once but not exactly-once. Subscribers must be idempotent to handle duplicate events.
Event size: Maximum 1 MB. For larger payloads, use a reference pattern.
Availability: SLA of 99.99% for publishing and 99.9% for delivery (for premium tier, but standard is same).
Differences from Other Azure Messaging Services
Event Grid vs. Event Hubs: Event Hubs is for massive data ingestion (telemetry, logs) with ordered streams and replay capabilities. Event Grid is for discrete event notifications with routing to multiple subscribers.
Event Grid vs. Service Bus: Service Bus is a message broker for reliable, ordered, and transactional messaging, often for command-based patterns. Event Grid is for event-driven reactive patterns with pub/sub.
Event Grid vs. Queue Storage: Queue Storage is a simple FIFO queue for decoupling components. Event Grid provides push delivery and multiple subscribers.
Identify Event Sources
First, determine which Azure services or custom applications will generate events. Common sources include Azure Blob Storage (blob created/deleted), Azure Resource Manager (resource write, delete, change), Azure IoT Hub (device telemetry), and custom applications. Each source has a set of event types it can emit. For example, Blob Storage emits 'Microsoft.Storage.BlobCreated' and 'Microsoft.Storage.BlobDeleted'. You need to know the exact event types because they are used in filtering. In the portal, you can view available event types from a resource's 'Events' blade. For custom sources, you define your own event types.
Create a Topic
A topic is an endpoint that receives events from publishers. For system events (e.g., from Azure services), a system topic is automatically created when you create an event subscription on that resource. For custom events, you must create a custom topic. In the portal, go to 'Event Grid Topics' and click 'Create'. Provide a name, resource group, and location. The location determines the regional endpoint. The topic's endpoint URL and access key are generated. You can also use CLI: `az eventgrid topic create --name myTopic --resource-group myRG --location eastus`. The topic is the central hub where events are collected before being routed to subscribers.
Create Event Subscriptions
A subscription defines which events to listen for and where to send them. You can filter by event type, subject (prefix or suffix), and advanced fields. The destination can be an Azure Function, Logic App, webhook, queue, Service Bus, Event Hubs, or Hybrid Connection. For example, if you want to trigger a function whenever a blob is created in a specific container, you set subject filter to '/blobServices/default/containers/mycontainer/'. You can also set a filter for event types. In the portal, from the topic or resource, click 'Event Subscription' and fill in the details. CLI example: `az eventgrid event-subscription create --name mySub --source-resource-id <topic-id> --endpoint-type webhook --endpoint https://mywebhook.azurewebsites.net/api/events`.
Publish Events
Publishers send events to the topic endpoint via HTTPS POST with a JSON array of event objects. Each event must conform to the Event Grid schema. For Azure services, this happens automatically when the event occurs. For custom applications, you need to write code that constructs the event payload and sends it to the topic URL using the access key for authentication. The key is provided in the topic's 'Access Keys' blade. Example payload: `[{"id": "1", "eventType": "myApp.OrderCreated", "subject": "orders/123", "eventTime": "2024-01-01T00:00:00Z", "data": {"orderId": 123}, "dataVersion": "1.0"}]`. The publish operation is synchronous and returns a success status if the event is accepted.
Monitor and Handle Delivery
Event Grid attempts to deliver events to each subscriber endpoint. If the subscriber returns an HTTP 200-299 status, delivery is considered successful. If it returns an error or times out, Event Grid retries using exponential backoff (default 30 retries over 24 hours). You can configure retry policy (max retries, event time-to-live). Dead-lettering can be set up to send undeliverable events to a Blob Storage container for later analysis. Monitoring is available via Azure Monitor metrics (e.g., 'Published Events', 'Delivery Failed') and diagnostic logs. You can also set up alerts for delivery failures. In the portal, from the topic, view 'Metrics' and 'Activity Log'. CLI: `az monitor metrics list --resource <topic-id> --metric 'PublishSuccessCount'`.
Scenario 1: Automated Image Processing Pipeline
A media company uploads thousands of images daily to Azure Blob Storage for a website. They need to automatically generate thumbnails, apply watermarks, and store metadata in a database. Without Event Grid, they would have to run a scheduled job that polls for new blobs, causing latency and unnecessary compute costs. With Event Grid, they create a system topic on the storage account and a subscription that triggers an Azure Function whenever a blob is created (event type 'Microsoft.Storage.BlobCreated'). The function reads the blob, processes it, and writes thumbnails to another container. The team configures subject filtering to only trigger for blobs in the 'uploads/' container. They also set a retry policy of 10 retries to handle transient failures. Cost is minimal: only pay for events (pennies per thousand) and function executions. If misconfigured (e.g., wrong endpoint URL), events would be retried and eventually dead-lettered, causing processing delays. Monitoring metrics like 'DeliveryFailedCount' helps them detect issues quickly.
Scenario 2: Real-Time Resource Compliance Auditing
A large enterprise needs to ensure that any Azure resource creation meets internal compliance rules (e.g., tags must be present, certain regions are allowed). They use Azure Policy for enforcement, but also want real-time notifications for non-compliant deployments. They subscribe to the Azure Resource Manager system topic (which emits events like 'Microsoft.Resources.ResourceWriteSuccess'). An Azure Logic App subscription filters for write events and then runs a compliance check using Azure Policy REST API. If a resource is non-compliant, the Logic App sends a notification to the security team via email and also logs the event to a Log Analytics workspace. The team uses Event Domains to organize topics for different departments. Cost is low, but they must ensure the Logic App is idempotent because Event Grid delivers at-least-once. If the Logic App fails to handle duplicates, it might send multiple alerts. They also set up dead-lettering to capture events that fail after retries, allowing manual review.
Scenario 3: IoT Device Telemetry Routing
A smart building company uses Azure IoT Hub to collect data from thousands of sensors (temperature, humidity, occupancy). They need to route specific events to different downstream services: temperature alerts go to an Azure Function that adjusts HVAC, occupancy data goes to a Service Bus queue for analytics, and device lifecycle events (device connected/disconnected) go to a webhook for inventory tracking. Event Grid integrates with IoT Hub via system topics. They create multiple subscriptions on the IoT Hub system topic with filters on event types and subject (device ID prefix). This decouples the event sources from handlers, allowing independent scaling. They also use dead-lettering to capture events that fail to deliver to the webhook. A common mistake is forgetting to configure authentication for the webhook endpoint, causing delivery failures. Monitoring metrics like 'MatchingEventsCount' helps verify that filters are working correctly.
What AZ-900 Tests on This Objective
AZ-900 Objective 2.2 (Describe core Azure compute and networking services) includes messaging and event services. Event Grid is specifically tested under the 'event-based messaging' category. The exam expects you to:
Identify the purpose of Event Grid: reactive event routing with push delivery.
Differentiate Event Grid from other messaging services (Event Hubs, Service Bus, Queue Storage).
Understand common use cases: reacting to state changes in Azure services, serverless event-driven applications.
Know the basic components: topics, subscriptions, event handlers.
Recognize that Event Grid supports both Azure service events and custom events.
Common Wrong Answers and Why Candidates Choose Them
'Event Grid is a message queue' – Candidates confuse Event Grid with Queue Storage or Service Bus. Event Grid does not store messages; it pushes them to subscribers and retries if delivery fails. It is not a queue; it's a pub/sub router.
'Event Grid guarantees ordered delivery' – Event Grid does not guarantee order. Candidates assume all messaging services provide ordering. The exam may present a scenario requiring ordered events, and the correct answer would be Event Hubs or Service Bus, not Event Grid.
'Event Grid is best for streaming large volumes of telemetry' – This is Event Hubs' job. Event Grid is for discrete events, not high-throughput streaming. Candidates may think 'events' means streaming data.
'Event Grid requires you to write code to poll for events' – The opposite is true. Event Grid uses push delivery; subscribers don't poll. This misconception arises from experience with queue-based systems.
Specific Terms and Values That Appear Verbatim
Event types: 'Microsoft.Storage.BlobCreated', 'Microsoft.Resources.ResourceWriteSuccess'
Delivery guarantee: at-least-once
Retry policy: default 30 retries, exponential backoff, max 24 hours
Event size limit: 1 MB
SLA: 99.99% for publishing, 99.9% for delivery (standard tier)
Supported handlers: Azure Functions, Logic Apps, Webhooks, Automation, Queue Storage, Service Bus, Event Hubs, Hybrid Connections
Edge Cases and Tricky Distinctions
Event Grid vs. Event Hubs: Both handle events, but Event Hubs is for big data streaming (events are stored and can be replayed), while Event Grid is for reactive notifications (events are transient). If the scenario mentions 'order of events' or 'replay', choose Event Hubs.
Event Grid vs. Service Bus: Service Bus is for reliable, transactional messaging with features like sessions and dead-lettering for business logic. Event Grid is for simple event notifications. If the scenario requires 'commands' or 'request/reply', choose Service Bus.
Event Grid vs. Logic Apps: Logic Apps can be both an event handler (triggered by Event Grid) and an event publisher (via custom connector). The exam may ask which service is used to react to an Azure event – the answer is Event Grid, not Logic Apps directly.
Memory Trick: 'Grid = Push, Not Poll'
When you see a question about reacting to an Azure service event (like blob creation), remember: 'Grid pushes, not polls.' If the question mentions 'react in real-time' or 'trigger a function when a blob is uploaded', choose Event Grid. If it mentions 'process a stream of millions of events per second' or 'ordered events', choose Event Hubs. If it mentions 'reliable messaging with transactions' or 'commands', choose Service Bus. This decision tree helps eliminate wrong answers quickly.
Exam Tip
Always read the scenario carefully for keywords: 'react to', 'trigger', 'notification', 'event-driven' point to Event Grid. 'Ingest', 'stream', 'telemetry', 'ordered' point to Event Hubs. 'Queue', 'command', 'reliable', 'transactions' point to Service Bus or Queue Storage.
Azure Event Grid is a fully managed event routing service that uses a publish-subscribe model with push delivery.
Event Grid supports both system topics (Azure services) and custom topics (your own events).
Delivery is at-least-once with automatic retry (default 30 attempts, exponential backoff).
Maximum event size is 1 MB; larger payloads should use a reference pattern with Blob Storage.
Common use cases: reacting to blob storage events, resource group changes, and IoT device events.
Event Grid is distinct from Event Hubs (streaming) and Service Bus (messaging) – choose based on scenario.
SLA: 99.99% for event publishing, 99.9% for delivery in standard tier.
These come up on the exam all the time. Here's how to tell them apart.
Azure Event Grid
Push-based event delivery to subscribers
Designed for discrete event notifications (e.g., blob created)
Does not guarantee order of events
Events are transient (not stored after delivery)
Ideal for reactive serverless architectures
Azure Event Hubs
Pull-based ingestion from producers, consumers pull
Designed for high-throughput data streaming (e.g., telemetry)
Guarantees order within a partition
Events are stored and can be replayed (retention up to 7 days)
Ideal for big data analytics and stream processing
Mistake
Event Grid is a message queue that stores events until they are consumed.
Correct
Event Grid does not store events; it delivers them immediately to subscribers and retries if delivery fails. It is a pub/sub router, not a queue. For persistent storage, use Queue Storage or Service Bus.
Mistake
Event Grid guarantees exactly-once delivery.
Correct
Event Grid guarantees at-least-once delivery, meaning duplicates are possible. Subscribers must be idempotent to handle duplicate events. Exactly-once delivery is not supported.
Mistake
Event Grid can only be used with Azure services.
Correct
Event Grid supports custom topics, allowing any application (on-premises or other clouds) to publish events via HTTPS. It is not limited to Azure services.
Mistake
Event Grid is the best choice for streaming high-throughput telemetry data.
Correct
Event Grid is designed for discrete events, not high-throughput streams. For streaming millions of events per second, use Azure Event Hubs.
Mistake
Event Grid events are delivered in the order they were published.
Correct
Event Grid does not guarantee order. If order matters, use Event Hubs with partitions or Service Bus with sessions.
Event Grid is a push-based event routing service for discrete events (e.g., blob created). It delivers events to subscribers in real-time without storing them. Event Hubs is a pull-based big data streaming platform for high-throughput telemetry (e.g., millions of sensor readings per second). It stores events for a configurable retention period and allows replay. Use Event Grid for reactive triggers; use Event Hubs for stream processing.
Event Grid guarantees at-least-once delivery. It retries delivery if the subscriber does not return a success status (200-299) within a timeout. Retries use exponential backoff up to a maximum of 30 retries over 24 hours by default. You can configure retry policy and dead-lettering for failed events. However, duplicates are possible, so subscribers should be idempotent.
Yes. You can create a custom topic in Azure and publish events from on-premises applications via HTTPS. Additionally, you can use Event Grid's Hybrid Connections or Azure Relay to route events to on-premises endpoints. However, the subscriber endpoint must be reachable from the internet or via a hybrid connection.
A system topic is a topic automatically created by Azure for an Azure service (e.g., Blob Storage, Resource Manager, IoT Hub). It exposes events that the service generates. You cannot delete a system topic directly; it is managed by Azure. You create event subscriptions on system topics to receive those events.
You can filter events by event type, subject (prefix or suffix), and advanced fields (e.g., data properties). Filters are defined in the event subscription. For example, to only receive events for blobs created in a specific container, set subject filter to '/blobServices/default/containers/mycontainer/'. This reduces unnecessary invocations and cost.
Supported event handlers include Azure Functions, Logic Apps, Webhooks, Azure Automation, Azure Queue Storage, Azure Service Bus, Azure Event Hubs, and Hybrid Connections. The handler must be able to receive HTTP POST requests with the event schema. For Azure Functions, you can use the Event Grid trigger binding.
Event Grid has a consumption-based pricing model. The first 100,000 operations (publish + delivery) per month are free. After that, you pay per million operations. For example, publishing 10 million events costs approximately $10. There is no upfront cost or reserved capacity. Dead-letter storage incurs standard Blob Storage costs.
You've just covered Azure Event Grid — now see how well it sticks with free AZ-900 practice questions. Full explanations included, no account needed.
Done with this chapter?