200-901 Understanding and Using APIs Practice Question
A developer is building a Python script that calls the Cisco Webex Rooms API. The API returns a JSON error response with HTTP status code 429. The script currently retries immediately in a tight loop, but the errors persist. What should the developer implement to correctly handle this response?
⚠ Common exam trap
The trap here is assuming that retrying immediately or refreshing credentials will resolve a 429, when the response specifically requires the client to pause for the interval given in the Retry-After header.
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
✓
Read the Retry-After response header and wait that many seconds before retrying the request.
HTTP 429 signals that the client has exceeded the API rate limit. Cisco Webex APIs return a Retry-After header indicating how long to wait before the next request. Reading and honoring that value prevents further throttling and is the standard remediation. Immediate retries, changing methods, or refreshing tokens do not address the underlying rate-limit condition.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Read the Retry-After response header and wait that many seconds before retrying the request.
Why this is correct
HTTP 429 indicates the client has exceeded the rate limit. Cisco Webex APIs include a Retry-After header specifying how long to wait before retrying. Honoring this header prevents additional throttling and aligns with API rate-limiting best practices. Immediate retries in a tight loop would continue to fail and may extend the throttling period.
- ✗
Change the HTTP method from GET to POST and resend the request.
Why it's wrong here
Changing the HTTP method does not address rate limiting. The 429 status is a server-side throttle response, not a method-not-allowed error. Using POST on a resource that expects GET would likely produce a 405 Method Not Allowed or create unintended side effects. The correct fix is to respect the rate-limit signal, not alter the method.
- ✗
Set the Authorization header to a new access token and resend the request immediately.
Why it's wrong here
A 429 response is not an authentication failure. Refreshing the token will not lift the rate limit and immediate resending worsens throttling. Authentication issues manifest as 401 or 403, not 429. The developer should instead back off according to the server's Retry-After guidance before issuing another request.
- ✗
Add a Content-Type: application/json header and resend the request.
Why it's wrong here
Content-Type describes the request body format and does not influence rate limiting. The 429 response is triggered by request frequency, not media type negotiation. Adding this header will not stop the throttling. The developer must implement a backoff strategy using the Retry-After header or exponential backoff to resolve the issue.
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.