A moose-wallow reminder should stay invisible to workers for 24 hours. How should the developer delay the Service Bus message?
Select an answer to reveal the explanation.
Short Explanation
Do not babysit the clock in a Function. Schedule the Service Bus message with an enqueue time and let the broker hold it until tomorrow.
Full Explanation
Service Bus scheduled messages let a moose-wallow reminder stay invisible to workers until a scheduled enqueue time. The broker holds the message and makes it available later—here, after 24 hours—without a worker process sleeping on the message. That delayed-visibility feature is the managed way to defer a single reminder while keeping the queue free for current work.
Running a Domain 1 timer Function that busy-waits for 24 hours holding the message fails because long busy-waits waste compute, risk timeouts, and are not how Service Bus delayed delivery works. Storing the reminder only in Redis with no messaging schedule fails conceptually: Redis may hold a value, but it is not Service Bus scheduled enqueue. Using Event Hubs Capture delay minutes as a reminder clock fails because Capture windowing controls archive batching, not Service Bus message visibility.
Exam caveat: scheduled time is when the message becomes eligible to receive—not a guarantee a worker is online at that instant—so pair scheduling with available consumers. Operational check: schedule a message a few minutes ahead, verify it is absent from active receives until the enqueue time, then confirm it appears for a normal peek-lock receive.