200-901 Cisco Platforms and Development Practice Question
A developer is using the Meraki Dashboard API to retrieve a list of clients for a network. The API returns a 429 error. What should the developer do to handle this correctly?
⚠ Common exam trap
Cisco often tests the misconception that 429 is a transient error like a 503 Service Unavailable, leading candidates to think they can simply retry immediately or ignore it, rather than understanding that 429 specifically requires honoring the Retry-After header for rate-limit compliance.
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
✓
Wait for the number of seconds specified in the Retry-After header before retrying.
A 429 HTTP status code indicates 'Too Many Requests,' meaning the client has exceeded the rate limit imposed by the Meraki Dashboard API. The correct handling is to respect the Retry-After header, which specifies the number of seconds the client must wait before retrying the request, as per RFC 7231 Section 7.1.3. This ensures compliance with API rate limits and prevents further throttling or temporary blocking.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Ignore the error and continue, as 429 is a temporary issue.
Why it's wrong here
A 429 signals rate limiting, so continuing without delay keeps hitting the cap and may trigger further throttling; the developer must respect the Retry-After header and back off. Ignoring transient errors suits idempotent retries of 5xx faults, not quota exhaustion, which requires pacing requests.
- ✓
Wait for the number of seconds specified in the Retry-After header before retrying.
Why this is correct
A 429 signals rate limiting, and the Meraki Dashboard API returns a Retry-After header giving the exact backoff interval. Honouring that value respects the documented rate-limit window, so the retry succeeds rather than being throttled again. Immediate retries or fixed delays ignore the server-supplied timing and risk further 429 responses.
- ✗
Switch to a different base URL to bypass the limit.
Why it's wrong here
A 429 signals rate limiting tied to the API key and endpoint; changing the base URL still hits the same Meraki rate limiter, so the error persists. It tempts as a workaround for endpoint-specific problems, which is valid when a host is unreachable or deprecated, but not for throttling.
- ✗
Increase the request rate by using multiple API keys in parallel.
Why it's wrong here
Meraki rate limits apply per organisation, so parallel keys do not multiply the allowance and may trigger further 429 responses. It tempts because distributing load across credentials works against per-key quotas elsewhere, but Meraki enforces organisation-wide limits, so retrying with backoff is required.
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.