200-901 Cisco Platforms and Development Practice Question
A developer is using the Meraki Dashboard API and receives an HTTP 429 status code with a Retry-After header. What is the correct interpretation?
⚠ Common exam trap
Cisco often tests the distinction between HTTP 429 (rate limiting) and 503 (server unavailable), and candidates may confuse Retry-After with a suggestion rather than a mandatory wait period.
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
✓
The rate limit has been exceeded; the client should wait the number of seconds specified in Retry-After before retrying.
HTTP 429 status code indicates 'Too Many Requests', meaning the client has exceeded the rate limit imposed by the Meraki Dashboard API. The Retry-After header specifies the number of seconds the client must wait before sending a new request to avoid further throttling. This is a standard rate-limiting mechanism defined in RFC 6585.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The API key is invalid and the request should be re-authenticated.
Why it's wrong here
HTTP 429 indicates rate limiting, not authentication failure; an invalid API key returns 401 Unauthorized. It is tempting because both statuses require client action, but re-authenticating does nothing when the request was throttled — the client must wait for the Retry-After interval before resending.
- ✓
The rate limit has been exceeded; the client should wait the number of seconds specified in Retry-After before retrying.
Why this is correct
HTTP 429 signals the Meraki Dashboard API rate limit has been exceeded. The Retry-After header specifies the number of seconds the client must wait before issuing another request; retrying earlier risks further throttling. This is a throttling response, not an authentication or server error.
- ✗
The server is temporarily unavailable; the client should retry immediately.
Why it's wrong here
An HTTP 429 signals rate limiting, not server unavailability, so retrying immediately would breach the limit again and prolong throttling. The Retry-After header specifies the wait before the next request. This option would fit a 503 response, where the server genuinely cannot handle the request and an immediate retry may succeed.
- ✗
The request was successful but the response is too large.
Why it's wrong here
HTTP 429 signals rate limiting, not payload size; the Retry-After header specifies how long to wait before retrying. A successful-but-oversized response would return 200 with a body, or 413 Payload Too Large. This option is tempting because large responses can cause client-side timeouts, but that scenario involves response size, not request throttling.
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 by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
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.