A transit-agency client receives HTTP 403 Forbidden on one Cisco API call and HTTP 429 Too Many Requests on another. How should unrecoverable-error control flow treat them?
Select an answer to reveal the explanation.
Short Explanation
A red light and a traffic cop’s hand are both “stop,” but only the temporary jam clears if you wait. 429 says slow down and retry; 403 says you are not allowed—choose the stop branch for permission, not a blanket “all 4xx” rule.
Full Explanation
Not every 4xx shares the same recovery path. For the transit-agency client, HTTP 403 Forbidden is an unrecoverable permission or policy failure for that credential and resource: stop, fix RBAC or scope, and do not retry the same call as if load will clear it. HTTP 429 Too Many Requests is typically recoverable: honor Retry-After or apply bounded backoff, then retry only that rate-limited path. Correct unrecoverable-error control flow therefore stops on 403 while waiting and retrying only the 429 path.
Retrying both forever because any 4xx is always transient fails by collapsing distinct semantics into one naïve loop—403 will never heal from waiting. Aborting both immediately because any 4xx is always a permanent permission failure fails the other way: it treats rate limiting as a hard deny and abandons work that would succeed after a short pause. Ignoring both statuses and reusing the last successful response body fails because the client invents freshness and authorization outcomes the platform just refused.
Exam caveat: some gateways misuse 403 for WAF blocks that might be temporary—exam intent still separates permission/validation failures from 429. Distinguish 401 (re-auth) from 403 (authenticated but forbidden).
Operational check: in client metrics, assert 403 increments an authz-fail counter with no automatic retry, while 429 increments a throttled-retry counter with Retry-After respected and a maximum attempt cap.