200-901 Understanding and Using APIs Practice Question
A developer is designing a Python application that interacts with multiple Cisco REST APIs. They need to implement robust error handling for common HTTP status codes. Which TWO of the following status codes indicate that the client should retry the request after a delay? (Choose two.)
⚠ Common exam trap
The trap here is assuming that any error status should be retried, when in fact only transient errors like 429 and 503 benefit from a delayed retry; client errors require fixing the request.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
503 Service Unavailable
Status codes 429 and 503 indicate temporary conditions where retrying after a delay can succeed. 429 is rate limiting, and 503 is service unavailability. Both often include Retry-After headers. The other codes (401, 404, 400) represent client errors that require corrective action, not retries, because they will persist until the request or credentials are fixed.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
400 Bad Request
Why it's wrong here
HTTP 400 indicates the server cannot process the request due to a client error, such as malformed syntax or invalid parameters. Retrying without correcting the request will yield the same result. The client must inspect and fix the request payload or parameters. It is not a transient condition, so retrying after a delay is not appropriate.
- ✗
404 Not Found
Why it's wrong here
HTTP 404 means the requested resource does not exist. Retrying the same request will consistently return 404. The client should verify the URL or resource identifier. This is a permanent error for the given request, so retrying after a delay is futile. It requires fixing the request, not waiting and retrying.
- ✓
503 Service Unavailable
Why this is correct
HTTP 503 means the server is temporarily unable to handle the request, often due to maintenance or overload. It may include a Retry-After header. Retrying after a delay is recommended because the condition is usually transient. Many Cisco cloud APIs may return 503 during brief outages, so implementing a retry with exponential backoff improves resilience and success rates.
- ✓
429 Too Many Requests
Why this is correct
HTTP 429 indicates the client has sent too many requests in a given time. The server includes a Retry-After header specifying how long to wait. Retrying after the indicated delay is appropriate and often necessary to complete the operation. This status is common in Cisco APIs like Webex and Meraki when rate limits are exceeded, so handling it with a backoff is essential for robust applications.
- ✗
401 Unauthorized
Why it's wrong here
HTTP 401 indicates authentication credentials are missing or invalid. Retrying without changing credentials will not succeed. The client must obtain valid credentials or refresh the token before retrying. This is not a transient error that resolves with a delay, so it is not a case for blind retry. It requires corrective action such as re-authentication.
Go deeper
Related to this question
About these practice questions
This 200-901 question is part of Courseiva's 975-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Cisco exam blueprint
This 200-901 practice question is part of Courseiva's free Cisco certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the 200-901 exam.