Event Grid delivery schema

Understand the concept

Why it matters

Event Grid delivery schema matters because Event Grid workflows fail in ways that are easy to misread: a publisher can succeed while a handler never receives the event, a filter can exclude the right payload, or an identity change can turn delivery into repeated failures. Clear vocabulary keeps architects, developers, operators, security reviewers, and business owners aligned on the exact routing behavior. It also improves change review because teams can ask who owns the setting, which events are affected, which handler depends on it, and what evidence proves the current state before a release, incident, audit, or cost review. This keeps ownership, evidence, change control, and customer impact visible before the next production decision.

Technical context

Technically, Event Grid delivery schema sits inside the Azure Event Grid control plane and runtime delivery path. The main moving parts are event subscription, event schema, CloudEvents fields, Event Grid schema fields, custom input schema, handler code, filters, and test payloads. It is usually created or inspected through the Azure portal, ARM or Bicep, REST, and Azure CLI. Production teams should connect the configured resource ID, schema choice, endpoint behavior, identity, logs, and metrics so troubleshooting can move from an architecture diagram to verifiable Azure evidence.

Exam context

Compare with

Where it is used

Where you see it

1. Event subscription creation commands and portal settings expose the event delivery schema value, which tells handlers whether to parse Event Grid schema or CloudEvents during production review.
2. Function triggers, webhook code, and integration tests reveal schema assumptions through field names such as subject, eventType, source, type, data, and dataVersion during production review.
3. Failed deliveries, deserialization errors, filter mismatches, and malformed payload alerts often point to delivery schema drift between the publisher and subscriber during production review with support evidence.

Common situations

• Confirm which payload format the handler receives.
• Compare subscription configuration with function or webhook parser expectations.
• Detect schema drift before a publisher or handler deployment.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Azure CLI

Azure CLI is useful for Event Grid delivery schema because it gives operators reproducible evidence for the source, subscription, handler, schema, filter, retry, identity, and metrics before any mutating change is approved.

az eventgrid event-subscription list --source-resource-id <source-resource-id> --output table

az eventgrid event-subscription show --name <subscription-name> --source-resource-id <source-resource-id>

az eventgrid event-subscription create --name <subscription-name> --source-resource-id <source-resource-id> --endpoint <endpoint>

az eventgrid event-subscription update --name <subscription-name> --source-resource-id <source-resource-id> --event-ttl <minutes> --max-delivery-attempts <count>

az monitor metrics list --resource <event-grid-resource-id> --interval PT1H

Architecture context

Event Grid delivery schema belongs in the Event Grid routing architecture with explicit publishers, subscriptions, handlers, filters, schemas, retry policy, dead-lettering, identity, monitoring, and rollback ownership.

Security

Security for Event Grid delivery schema starts with knowing which identity, key, role assignment, endpoint, or storage resource can publish, configure, receive, or recover events. Avoid anonymous delivery paths where a managed identity, Microsoft Entra protected endpoint, or least-privilege Azure RBAC role is appropriate. Protect event payloads because metadata and data fields can expose tenant IDs, object names, user activity, or business workflow details. Review Activity Log changes, role assignments, private endpoint requirements, and diagnostic settings before production updates. For regulated data, document who can view dead-letter payloads and who may replay or reprocess them. This keeps ownership, evidence, change control, and customer impact visible before the next production decision.

Cost

Cost for Event Grid delivery schema usually comes from event operations, handler executions, downstream queue or stream processing, storage for dead-letter payloads, logging, alerting, and repeated retry activity. A small event route can become expensive when noisy publishers, broad filters, duplicate subscriptions, or failing handlers multiply delivery attempts. Review expected event rate, matched event count, failed delivery count, log retention, and downstream execution cost together. Use tags, budgets, and ownership labels so cost analysis can distinguish planned integration volume from accidental fan-out or retry storms. Retire unused subscriptions and test topics before they become permanent background spend. This keeps ownership, evidence, change control, and customer impact visible before the next production decision.

Reliability

Reliability for Event Grid delivery schema depends on accurate source routing, compatible event schema, healthy handlers, retry behavior, dead-letter handling, and clear monitoring. Event Grid can accept an event while downstream processing still fails, so success must be measured across publish, match, delivery, and handler processing stages. Test endpoint outage, authorization failure, malformed payload, noisy publisher, and filter drift scenarios before relying on the workflow. Keep replay and cleanup procedures documented. During incidents, compare recent Activity Log entries, handler logs, Event Grid metrics, and dead-letter contents before changing routing or retry settings. This keeps ownership, evidence, change control, and customer impact visible before the next production decision.

Performance

Performance for Event Grid delivery schema is about how quickly relevant events move from publisher to handler without creating avoidable fan-out, parsing, or retry delay. Broad filters, slow endpoints, oversized payloads, schema mismatches, cold-starting functions, or throttled downstream services can turn near-real-time routing into delayed processing. Measure publish latency, matched event rate, delivery success, handler duration, and retry patterns together. Design handlers to acknowledge events quickly, offload long work where needed, and scale independently. Use Event Hubs, Service Bus, or queues when buffering is more important than immediate handler execution. This keeps ownership, evidence, change control, and customer impact visible before the next production decision.

Operations

Operations for Event Grid delivery schema should be runbook-driven. The runbook needs the resource ID, owner, environment, publisher, handler, schema, filter, retry policy, dead-letter location, dashboards, and first read-only CLI commands. Operators should know which metric proves publish volume, which metric proves matching, and which log proves delivery failure. Change tickets should include expected event types, sample payloads, rollback instructions, and who can approve mutating commands. When support receives an alert, the first task is to locate the exact subscription or topic, not to restart every dependent service. This keeps ownership, evidence, change control, and customer impact visible before the next production decision.

Common mistakes

• Treating Event Grid delivery schema as a diagram label instead of checking the exact source resource ID, handler, identity, and event subscription.
• Changing filters, retry, schema, or destination settings before saving read-only evidence and confirming the approved rollback path.
• Assuming publisher success means end-to-end success even when the handler is failing, throttled, unauthorized, or receiving the wrong schema.