200-901 Understanding and Using APIs Practice Question
A developer is integrating with a REST API that uses rate limiting. The API documentation states that clients can make 100 requests per minute. The developer's application needs to fetch data from multiple endpoints. Which HTTP status code should the application expect if it exceeds the rate limit, and what header might indicate when to retry?
⚠ Common exam trap
The trap here is assuming that any error with a Retry-After header indicates rate limiting, but only 429 is the correct status code for exceeding rate limits.
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
✓
429 Too Many Requests with Retry-After header
HTTP 429 Too Many Requests is specifically defined for rate limiting scenarios. When a client exceeds the allowed request rate, the server responds with 429 and may include a Retry-After header indicating how many seconds to wait before retrying. This allows clients to implement backoff strategies. Other status codes like 403, 503, and 401 relate to authorization, server availability, and authentication, respectively, not rate limiting.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
429 Too Many Requests with Retry-After header
Why this is correct
HTTP 429 Too Many Requests is the standard status code for rate limiting. The Retry-After header, when included, indicates how long the client should wait before making another request. This combination allows the application to handle rate limiting gracefully by pausing and retrying after the specified period.
- ✗
503 Service Unavailable with Retry-After header
Why it's wrong here
503 Service Unavailable indicates that the server is temporarily unable to handle the request, often due to maintenance or overload. While it can include a Retry-After header, it is not the standard code for rate limiting. Using 503 would suggest a server-side problem rather than a client exceeding its quota.
- ✗
401 Unauthorized with WWW-Authenticate header
Why it's wrong here
401 Unauthorized indicates that the request lacks valid authentication credentials. The WWW-Authenticate header is used to challenge the client for credentials. This is unrelated to rate limiting. If the application receives 401, it should check its API key or token, not wait and retry.
- ✗
403 Forbidden with X-RateLimit-Reset header
Why it's wrong here
403 Forbidden indicates that the server understood the request but refuses to authorize it. It is not used for rate limiting. While some APIs might use custom headers like X-RateLimit-Reset, the status code 403 implies a permissions issue, not a temporary rate limit, so the application would not know to retry after a delay.
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.