200-901 Understanding and Using APIs Practice Question
A developer is integrating a Python application with the Cisco DNA Center API. The application must handle rate limiting gracefully. The API returns HTTP 429 Too Many Requests with a 'Retry-After' header indicating the number of seconds to wait before retrying. Which approach best implements exponential backoff with jitter to respect the rate limit and avoid overwhelming the server?
⚠ Common exam trap
The trap here is either ignoring the Retry-After header or implementing backoff without jitter, which can lead to thundering herd problems.
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
✓
Upon receiving 429, wait for the number of seconds specified in Retry-After, then retry the request. If it fails again, double the wait time and add a random jitter between 0 and 1 second.
The best practice for handling 429 responses is to honor the Retry-After header and then apply exponential backoff with jitter for subsequent retries. This respects the server's guidance while preventing synchronized retries from multiple clients. The other options either ignore the header, use fixed waits, or give up permanently, all of which are suboptimal.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Upon receiving 429, wait for the number of seconds specified in Retry-After, then retry the request. If it fails again, double the wait time and add a random jitter between 0 and 1 second.
Why this is correct
This approach respects the server's Retry-After header, which is the authoritative wait time. Then, for subsequent retries, it implements exponential backoff with jitter by doubling the wait and adding randomness. This combination is a best practice for handling rate limits and transient errors, reducing the chance of repeated collisions.
- ✗
Upon receiving 429, wait for a fixed 60 seconds before retrying, regardless of the Retry-After header. Repeat this fixed wait for each retry.
Why it's wrong here
A fixed wait ignores the dynamic Retry-After header, which may specify a shorter or longer duration. If the server requests a longer wait, this approach would retry too soon; if shorter, it wastes time. It also lacks exponential backoff and jitter, making it less adaptive to changing server conditions.
- ✗
Upon receiving 429, log the error and abort the request permanently, as rate limiting indicates a fatal error.
Why it's wrong here
Rate limiting is a transient condition, not a fatal error. Aborting the request would cause the application to fail unnecessarily. The correct behavior is to back off and retry after a suitable delay, as the server is indicating it can handle the request later. Permanent abort is only appropriate for non-recoverable errors like 400 or 401.
- ✗
Upon receiving 429, immediately retry the request in a tight loop until it succeeds, ignoring the Retry-After header.
Why it's wrong here
Immediately retrying in a tight loop ignores the server's explicit instruction and will likely exacerbate the rate limiting, potentially leading to temporary bans or further 429 responses. It does not implement backoff and can overwhelm the server, violating the principle of graceful degradation.
Go deeper
Related to this question
About these practice questions
Courseiva writes every 200-901 question from scratch — 975 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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.