The municipal Intersight consumer receives HTTP 503 with a Retry-After header during a maintenance blip. Which 2.1 branch should the client take inside its retry budget?
Select an answer to reveal the explanation.
Short Explanation
503 with Retry-After is 'the counter is closed for a short cleanup—come back then.' Wait and retry inside the budget. It is not a forever locked door like a hard permission deny.
Full Explanation
HTTP 503 with Retry-After during a maintenance blip is temporary unavailability. Inside the client’s retry budget, the correct branch is to wait for the Retry-After interval and retry the municipal Intersight call as a recoverable condition—not to abandon credentials or mutate the request method. That matches “service unavailable, try later” semantics.
Treating 503 like a permanent 403 and abandoning all credentials confuses outage with authorization failure. Immediately marking every 5xx as unrecoverable with no wait ignores Retry-After and recoverable blips the exam expects you to handle. Rewriting the request as DELETE because 503 means the object is gone invents destructive semantics from a gateway/maintenance signal.
Exam caveat: 503 without Retry-After still warrants backoff inside a budget; persistent 503 after the budget is exhausted becomes unrecoverable. Operational check: on Intersight 503, honor Retry-After, retry within max attempts, and only then open an incident—do not rotate OAuth clients solely because of a maintenance blip. Count 503 retries against the same overall budget used for timeouts so maintenance blips cannot stretch an Intersight job indefinitely. Distinguish 503 (try later) from 401/403 (fix authz) in metrics so on-call does not rotate secrets for every maintenance window.