200-901 Understanding and Using APIs Practice Question
A developer is using the Meraki Dashboard API and receives a 429 Too Many Requests error. The API documentation states a rate limit of 5 calls per second. What is the best practice to handle this?
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
✓
Implement exponential backoff and honor the Retry-After header.
Implementing exponential backoff with retry-after headers is the recommended approach for rate-limited APIs. Ignoring or simply retrying immediately may worsen the situation.
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 retry immediately.
Why it's wrong here
Retrying immediately without delay keeps exceeding 5 calls per second, so the 429 persists and may escalate to longer throttling. It is tempting because a single retry often succeeds on transient failures, but rate limiting requires waiting. Honouring the Retry-After header with exponential backoff is the documented practice.
- ✗
Use a different API key to bypass the limit.
Why it's wrong here
Meraki rate limits apply per organisation, not per API key, so rotating keys does not raise the 5 calls per second ceiling and may breach acceptable-use terms. It is tempting because separate keys appear to grant separate quotas. The correct approach is throttling requests client-side with backoff and Retry-After compliance.
- ✗
Increase the number of concurrent requests to exhaust the rate limit quickly.
Why it's wrong here
Raising concurrency accelerates the request rate, guaranteeing further 429 responses and possible throttling penalties. It is tempting because exhausting the quota quickly appears to clear the backlog, yet Meraki enforces 5 calls per second per organisation. The correct approach is client-side pacing with exponential backoff and Retry-After handling.
- ✓
Implement exponential backoff and honor the Retry-After header.
Why this is correct
Exponential backoff spaces retries progressively, preventing repeated collisions with the 5 calls per second limit, while honouring Retry-After respects the server's stated wait. Together they satisfy the rate-limit constraint without hammering the Meraki Dashboard API.
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 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.