A GET of UCS inventory for the city's data-center audit dies on a read timeout. Which consumer behavior is the robust next step for that idempotent read?
Select an answer to reveal the explanation.
Short Explanation
A timed-out inventory GET is like asking the clerk again after they catch their breath—not shouting the question fifty times at once. Delayed retry fits a safe, idempotent read.
Full Explanation
A GET of UCS inventory for a data-center audit is an idempotent read: repeating it should not create side effects. After a read timeout, the robust next step is to retry later with delay (backoff), giving the server or path time to recover instead of hammering it. That preserves audit progress without assuming the failure is permanent.
Never retrying any GET treats all read timeouts as terminal and abandons a recoverable audit path. Immediately firing dozens of identical GETs in a tight loop creates a stampede that deepens overload. Converting the GET into a POST create changes semantics—allocating new objects—when the goal was a safe inventory read, not mutation.
Exam caveat: retries still need a max-attempt or deadline so a permanently down host does not loop forever; backoff without a cap is incomplete. Operational check: on UCS inventory timeout, schedule a delayed retry, verify the same GET remains side-effect free, and alert if attempts exhaust the budget so the city’s audit job surfaces failure. Prefer capped exponential backoff with jitter on inventory GETs so the UCS audit job recovers from brief controller load without a request flood. Record attempt count and final outcome in job logs so the data-center audit trail shows whether the read eventually succeeded or exhausted policy. Do not mutate method or payload while retrying a pure inventory fetch.