An IoT vendor exposes a custom events service to partners. Partners provide HTTPS webhook endpoints that may be intermittently offline. You must publish events using a standard cross-language schema, filter events by eventType prefix, retry for up to 24 hours with exponential backoff, and if delivery ultimately fails, store undelivered events in a storage account for audit. What should you implement?

The correct option leverages Azure Event Grid's capabilities perfectly. Event Grid custom topics support the CloudEvents v1.0 schema, meeting the standard cross-language schema requirement. Event subscriptions allow advanced filtering by eventType prefix. Event Grid natively supports configurable retry policies, including exponential backoff for up to 24 hours, and dead-lettering to an Azure Storage account for undeliverable events, fulfilling all specified requirements for intermittent partner endpoints and auditing. Azure Service Bus Topics are messaging queues, not primarily eventing services, and lack direct support for CloudEvents or granular eventType filtering. Azure Event Hubs are designed for high-throughput streaming, not event distribution to webhooks, and their capture feature is for all events, not just failed ones. Event Grid domains are for managing multiple topics, not the core eventing logic, and disabling retries contradicts the requirement. Azure Logic Apps are orchestration tools; polling partner endpoints is inefficient and doesn't provide the robust retry/dead-lettering of Event Grid.