An xeric-ridge archive job and a live-alerting job must both read the same Event Hub without sharing a cursor. What should the developer create?
Select an answer to reveal the explanation.
Short Explanation
Independent jobs need independent cursors. Spin up two consumer groups (you already have $Default) so archive and alerting each track their own progress.
Full Explanation
Consumer groups give each reading application its own independent offsets on an Event Hub. For an xeric-ridge archive job and a live-alerting job that must both read the same hub without sharing a cursor, create two consumer groups (beyond the built-in $Default if you prefer dedicated names) so each job tracks its own progress and can scale its own readers.
One shared offset stored in a public Blob so both jobs fight over it fails isolation: concurrent writers corrupt the cursor, and a public blob is an unsafe coordination store for offsets Event Hubs already scopes per consumer group.
A single consumer that fans JSON out over email only fails independent processing: archive and alerting become one brittle pipeline, and email is not dual streaming consumption.
Two Storage queues that mirror the hub and delete messages competitively fails the Event Hubs model: you reintroduce competing-consumer queues and lose the append-only independent-read views consumer groups provide.
Exam caveat: within one consumer group, only one active reader epoch should own a given partition—scale readers with partition count, and use separate groups for separate applications. Operational check: create two consumer groups, run archive and alerting against each, pause one job, and confirm the other continues from its own checkpoint without stalling.