A university already runs a dashboard that will poll an API for assurance data. Which handoff matches that design?
Select an answer to reveal the explanation.
Short Explanation
If the scoreboard is built to phone a clerk for the numbers, installing a loudspeaker is a different project. You offer an API the university dashboard can poll, because that is the handoff the dashboard already uses. An ITSM queue, an OpenTelemetry stream, or an alert-threshold page would make that dashboard consume something it is not built to poll.
Full Explanation
The university dashboard is already built to poll an API. The handoff that matches is an API the dashboard can call for assurance data on the schedule it already uses. An ITSM ticket puts the same facts into a service-desk queue. The dashboard team would have to abandon polling and read tickets, which is not the design they described. OpenTelemetry pushes a telemetry stream. Requiring the dashboard to consume that stream replaces a working poller with a different integration the current board does not use. An alert-threshold page notifies on-call and leaves the dashboard without a feed. On-call paging can exist for other audiences, but it does not fill a board that expects to poll. The receiving system's interface decides the handoff. Here that interface is a poll. Exam caveat: an API, OpenTelemetry, an alert threshold, and ITSM are not interchangeable just because they can all carry news of a condition. Operational check: point the existing dashboard at the API and confirm the board populates by polling, with no new ticket queue required for that view.