200-901 Infrastructure and Automation Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  HTTP 403 Forbidden

  Why it's wrong here

  HTTP 403 indicates that the API key lacks permission for the requested resource or the organization, not that a rate limit was reached. Retrying a 403 will never succeed until permissions change, so treating it as throttling would cause the application to loop uselessly instead of alerting the administrator.

• ✗

  HTTP 401 Unauthorized

  Why it's wrong here

  HTTP 401 means the API key is missing or invalid, so the request was rejected at the authentication layer. It has nothing to do with call volume. An application that waits and retries on 401 would simply keep failing until a valid key is supplied.

• ✓

  HTTP 429 Too Many Requests

  Why this is correct

  The Meraki Dashboard API returns HTTP 429 when a client exceeds the allowed call rate. A well-behaved client should inspect this status, read the Retry-After header when present, and pause before retrying. Handling 429 explicitly prevents the application from hammering the API and being throttled further.

• ✗

  HTTP 503 Service Unavailable

  Why it's wrong here

  HTTP 503 signals a temporary server-side outage or maintenance on Meraki's side, not client throttling. Although retrying may eventually work, the cause is infrastructure availability, so relying on 503 to detect rate limiting would miss the actual 429 responses the API sends when quotas are exceeded.

Go deeper

Related to this question