200-901 Understanding and Using APIs Practice Question
A developer is integrating with a REST API that returns a 429 Too Many Requests status code along with a Retry-After header. The developer's script currently retries immediately upon receiving a 429. What should the developer do to correctly handle rate limiting?
⚠ Common exam trap
The trap here is assuming that exponential backoff alone is sufficient, when the server explicitly provides a wait time via Retry-After.
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
✓
Parse the Retry-After header and wait for the specified number of seconds before retrying the request.
The correct approach is to parse the Retry-After header and wait the specified time before retrying. This respects the server's rate limit and increases the chance of a successful request. Other options either ignore the header, switch endpoints unnecessarily, or use arbitrary delays. Honoring Retry-After is the standard and most effective way to handle 429 responses.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Parse the Retry-After header and wait for the specified number of seconds before retrying the request.
Why this is correct
The Retry-After header indicates how long the client should wait before making another request. It can be a number of seconds or an HTTP date. Parsing it and waiting the specified time prevents further rate limiting and respects the server's limits. This is the correct way to handle 429 responses and ensures the request will likely succeed on retry.
- ✗
Immediately retry the request with an exponential backoff starting at 1 second, ignoring the Retry-After header.
Why it's wrong here
Ignoring the Retry-After header can lead to continued rate limiting and potential IP blocking. While exponential backoff is a good practice, the server explicitly provides a wait time. Not using it may result in repeated 429 errors and longer delays. The correct approach is to honor the Retry-After header.
- ✗
Reduce the request rate by adding a fixed delay of 60 seconds between all subsequent requests.
Why it's wrong here
A fixed delay of 60 seconds is arbitrary and may be too long or too short. The Retry-After header provides the exact time to wait. Ignoring it and using a fixed delay could still result in rate limiting if the limit is higher, or waste time if the limit is lower. The correct method is to use the server-provided wait time.
- ✗
Switch to a different API endpoint that is not rate-limited and continue the operation there.
Why it's wrong here
Switching endpoints is not a valid solution because the rate limit likely applies to the entire API or the specific resource. Other endpoints may have the same or different limits, and the operation may not be supported elsewhere. This does not address the rate limiting issue and could cause further errors or incomplete data.
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.