A slow Cisco API call finally returns HTTP 403 Forbidden after several seconds. Which consumer action is correct?
Select an answer to reveal the explanation.
Short Explanation
A late “no” is still a no—not a dropped phone call. When the response finally arrives with 400/403/404, follow the status and stop; do not switch into timeout retry just because the clock ran long.
Full Explanation
A completed HTTP response carrying 403 Forbidden is an application-level outcome, not a transport timeout. Even if the slow Cisco API call took several seconds before returning, the consumer must read the completed status and take the unrecoverable abort path. Elapsed wall-clock time does not reinterpret Forbidden as “maybe try again with backoff”; the server already answered.
Ignoring the 403 and retrying with exponential backoff as if the client had hit a transport timeout fails by concept: timeout retry exists when no usable application response arrived. Treating elapsed wall-clock time as the only signal and discarding the HTTP status fails because it throws away the authoritative outcome. Upgrading the call to a websocket stream so Forbidden statuses can be delayed indefinitely fails the requirement to honor HTTP semantics and does not fix an authorization problem.
Exam caveat: if the client times out locally before any response, that is a different branch from a late 403; once 400/403/404 arrives, follow the status. Slow success with 200 is still success—latency alone is not failure.
Operational check: in integration tests, delay a 403 response beyond the usual SLA and verify the client still records Forbidden (not timeout-retry), and that no backoff scheduler is armed solely due to latency.