200-901 Software Development and Design Practice Question
A developer is writing a Python script that uses the requests library to call a REST API. The API occasionally returns a 429 status code. Which approach best handles this situation?
⚠ Common exam trap
The trap here is thinking that immediate retries will eventually succeed, but they can worsen rate limiting; backoff is essential.
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
✓
Implement exponential backoff and respect the Retry-After header if present.
Exponential backoff with respect to Retry-After is the recommended way to handle 429 responses. It allows the client to recover from rate limiting without overwhelming the server. The other options either ignore the error, retry too aggressively, or avoid the endpoint, none of which are robust solutions. This approach balances persistence with respect for API limits.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Implement exponential backoff and respect the Retry-After header if present.
Why this is correct
Exponential backoff increases the delay between retries, reducing load on the API. Respecting the Retry-After header ensures compliance with the API's rate limit policy. This approach is standard for handling 429 errors and improves the chances of eventual success without causing further throttling. It is both polite and effective.
- ✗
Ignore the 429 and continue with the next request.
Why it's wrong here
Ignoring a 429 Too Many Requests error means the request failed and the desired data was not retrieved. Continuing without handling it may lead to missing data or errors downstream. It does not respect the API's rate limiting and could result in further throttling or blocking. Proper handling is necessary to ensure reliability.
- ✗
Retry the request immediately in a tight loop until it succeeds.
Why it's wrong here
Retrying immediately in a tight loop can exacerbate rate limiting and may lead to being blocked. It ignores the Retry-After header that the API may provide, which indicates how long to wait. This approach is aggressive and can overload the API, making the situation worse. A backoff strategy is required.
- ✗
Switch to a different API endpoint that is not rate-limited.
Why it's wrong here
Switching endpoints is not a general solution; it may not provide the same data and could also be rate-limited. It avoids the problem rather than handling it. The developer should handle rate limiting gracefully on the intended endpoint. This option is impractical and does not address the root cause.
Go deeper
Related to this question
About these practice questions
One of 975 original 200-901 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.