Implement Robust REST API Error Handling for Time Outs and Rate Limits 350-901 Practice Questions (Page 2)

Questions 6–10

1. 6application · medium

   A support engineer is analyzing logs from an application that calls a Cisco Webex API. The logs show repeated 429 responses with 'Retry-After: 60'. The application is retrying after 60 seconds, but still getting 429s. What additional information should the engineer look for in the logs to diagnose the issue?

   • AThe application's retry count and the total number of requests made.
   • BThe application's log level and the timestamp format.
   • CThe X-RateLimit-Remaining and X-RateLimit-Reset headers from the 429 responses.
   • DThe IP address of the API server and the client's DNS server.
   Reveal Solution Discussion Select an answer first
2. 7application · medium

   A script receives a 429 response from a Cisco Meraki API. The response body contains a JSON field 'errors': ['Rate limit exceeded'], but there is no Retry-After header. What should the script do?

   • ATreat the 429 as a permanent error and stop retrying.
   • BRetry immediately since the error message does not specify a wait time.
   • CParse the error message for a numeric value and use that as the retry delay.
   • DUse a default backoff strategy (e.g., exponential backoff) since no Retry-After header is present.
   Reveal Solution Discussion Select an answer first
4. 8foundation · easy

   A client retries a timed-out request with exponential backoff. The first retry waits 1 second, the second waits 2 seconds, and the third waits 4 seconds. What is the expected wait time for the fourth retry if the pattern continues?

   • A8 seconds
   • B16 seconds
   • C4 seconds
   • D6 seconds
   Reveal Solution Discussion Select an answer first
5. 9application · medium

   A Python script calls a Cisco Meraki API to update device settings. The script receives an HTTP 429 response with a 'Retry-After: 120' header. The script's current retry logic retries immediately up to 5 times. What change should the engineer make to the retry logic?

   • ARetry immediately but only once, since the 429 is a temporary error.
   • BTreat the 429 as a permanent error and stop retrying, logging the failure.
   • CIgnore the Retry-After header and retry with exponential backoff starting at 1 second.
   • DCheck for the Retry-After header and wait the specified number of seconds before retrying, and cap the total retries.
   Reveal Solution Discussion Select an answer first
6. 10expert · hard

   An engineer is implementing retry logic for a Cisco Webex API client that occasionally times out. The engineer wants to avoid a 'thundering herd' effect where multiple clients retry simultaneously. Which retry strategy should the engineer use?

   • ARetry immediately with no delay, up to 3 times.
   • BFixed retry delay of 5 seconds for all retries.
   • CExponential backoff without jitter, starting at 1 second and doubling each time.
   • DExponential backoff with a random jitter added to each retry delay.
   Reveal Solution Discussion Select an answer first