An egret-pool intern waits for Event Hubs to POST each event to a webhook the way Event Grid does. How should events actually be consumed?
Select an answer to reveal the explanation.
Short Explanation
Event Grid pushes; Event Hubs waits for you to read. Spin up an SDK consumer, Kafka client, or Functions Event Hub trigger and pull from the log.
Full Explanation
Event Hubs is a partitioned log that consumers read (pull) from; it does not, by default, POST every event to arbitrary HTTP webhooks the way Event Grid pushes subscriptions. For an egret-pool workload, the developer writes a consumer—official SDKs, a Kafka client against the Kafka endpoint, or an Azure Functions Event Hub trigger—that reads partitions, processes events, and checkpoints progress. That pull model is how telemetry fans out to many independent readers without the hub owning webhook delivery.
Configuring Event Hubs to push every event as an HTTP webhook by default fails because that confuses Event Hubs with Event Grid's push delivery model. Replacing Event Hubs with Microsoft Graph change notifications for all telemetry fails conceptually: Graph notifications cover Graph resources, not high-throughput custom telemetry streams. Enabling only an APIM CORS policy so the hub pushes to browsers fails because CORS governs browser cross-origin HTTP access; it neither turns Event Hubs into a push bus nor is a consumption pattern for the log.
Exam caveat: Functions Event Hub triggers still checkpoint and scale out by partition ownership—understand lease/checkpoint behavior so multiple instances do not duplicate work unintentionally. Operational check: run a minimal SDK or Functions consumer against a test hub, publish events, and verify they are read and checkpointed without any webhook subscription on the hub.