200-901 Cisco Platforms and Development 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.

• ✗

  Switch to the DNA Center API.

  Why it's wrong here

  HTTP 429 signals Meraki rate limiting, which switching APIs does not resolve; the DNA Center API has its own separate limits and cannot serve Meraki data. It is tempting because moving to another platform appears to bypass throttling, and would be correct if the requirement were migrating management to a different vendor's controller.

• ✗

  Use a different API key.

  Why it's wrong here

  Meraki rate limits are enforced per organisation, not per API key, so a different key shares the same quota and still returns 429. It is tempting because key rotation appears to reset the counter, and would be correct where limits are scoped per credential rather than per organisation.

• ✓

  Reduce the number of concurrent requests and wait for the Retry-After header value.

  Why this is correct

  Meraki returns HTTP 429 when the rate limit is exceeded, and the Retry-After header specifies how long to pause. Throttling concurrent requests and honouring that value prevents further throttling and aligns the client with the documented limit.

• ✗

  Immediately retry the request without delay.

  Why it's wrong here

  Immediate retries consume the remaining quota and prolong the 429 condition; the Retry-After header specifies the wait before resending. It is tempting because retrying feels responsive, and would be correct for transient errors where no rate limit applies and the request simply failed once.

Go deeper

Related to this question