200-901 Understanding and Using APIs Practice Question
A developer is designing a REST API client that must handle rate limiting from a Cisco Webex API. The API returns HTTP 429 Too Many Requests with a 'Retry-After' header. Which two strategies should the developer implement to handle rate limiting gracefully? (Choose two.)
⚠ Common exam trap
The trap here is thinking that immediate retries or switching endpoints can bypass rate limiting, but the correct approach is to wait and back off as indicated by the server.
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, increasing the delay between retries after each 429 response.
To handle rate limiting gracefully, the client should respect the 'Retry-After' header and implement exponential backoff. These strategies reduce request frequency and align with server expectations. Immediate retries, switching endpoints, or indefinite caching do not properly address rate limiting and can worsen the situation.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Cache all responses indefinitely to avoid making repeated requests.
Why it's wrong here
Caching can reduce the number of requests, but caching indefinitely is not practical for dynamic data and does not handle rate limiting when new requests are needed. It also does not respect the Retry-After header. Caching should be used with appropriate time-to-live values, but it is not a primary strategy for handling 429 responses.
- ✗
Switch to a different API endpoint that is not rate-limited.
Why it's wrong here
Switching endpoints does not address the root cause of rate limiting and may not be possible if the required data is only available on the rate-limited endpoint. It also does not follow API best practices. Rate limiting is typically applied per API key or user, not per endpoint, so this may not help.
- ✓
Implement exponential backoff, increasing the delay between retries after each 429 response.
Why this is correct
Exponential backoff is a standard strategy to handle rate limiting. By increasing the wait time after each 429, the client reduces the load on the server and increases the chance of success. It is recommended in conjunction with the Retry-After header for optimal behavior.
- ✗
Immediately retry the request without delay to ensure the data is retrieved as quickly as possible.
Why it's wrong here
Immediately retrying without delay will likely result in another 429 response and may exacerbate rate limiting. It does not respect the server's request to slow down and can lead to temporary blocking. This strategy is counterproductive and should be avoided.
- ✓
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 explicitly tells the client how long to wait before making another request. Respecting this value is crucial to avoid further rate limiting. It is the most direct and recommended approach when the header is present.
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.