200-901 Understanding and Using APIs Practice Question
An application uses the Meraki Dashboard API and receives a 429 Too Many Requests error. What is the most likely cause, and how should the application adjust?
⚠ Common exam trap
200-901 often tests HTTP status codes and their meanings, and candidates may confuse 429 with 400 or 401, or fail to recognize that rate limiting requires backoff rather than immediate retry.
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 application exceeded the rate limit of 5 calls per second; implement exponential backoff.
A 429 Too Many Requests error from the Meraki Dashboard API indicates that the application has exceeded the rate limit, which is 5 calls per second per organization. The correct adjustment is to implement exponential backoff to retry requests after increasing delays, respecting the Retry-After header if provided.
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 request body is malformed; check JSON syntax.
Why it's wrong here
Malformed JSON produces a 400 Bad Request, not 429, so syntax checking cannot resolve throttling. It is tempting because request-formatting errors are common API failures, and this check would be correct when the service rejects the payload's structure rather than its arrival rate.
- ✗
The API key is invalid; regenerate the key.
Why it's wrong here
An invalid API key yields 401 Unauthorized, not 429, so regenerating credentials leaves the rate limit unaddressed. It is tempting because authentication failures also block API calls, and this action would be correct when the dashboard rejects the key itself rather than the request frequency.
- ✗
The network is down; check connectivity.
Why it's wrong here
A 429 signals rate limiting, not loss of connectivity, so checking the network diagnoses nothing and leaves the request throttled. It is tempting because connectivity faults also break API calls, and this check would be correct if the client received a timeout or DNS resolution failure instead.
- ✓
The application exceeded the rate limit of 5 calls per second; implement exponential backoff.
Why this is correct
The Meraki Dashboard API enforces a per-organisation limit of five calls per second, so sustained bursts trigger 429 responses. Exponential backoff retries with progressively longer delays, letting the application recover without hammering the endpoint, directly satisfying the stem's requirement to identify the cause and adjust accordingly.
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.