Courseiva

200-901 Infrastructure and Automation Practice Question

Which THREE of the following are valid methods to handle API rate limiting in a Python automation script? (Select exactly 3.)

⚠ Common exam trap

Cisco often tests the distinction between a fixed sleep (which is naive and not adaptive) versus dynamic methods like parsing Retry-After or using exponential backoff, and candidates mistakenly think a static delay is sufficient for rate limiting.

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

✓

Parse the Retry-After header from the response

Option A is correct because the Retry-After header, returned with HTTP 429 (Too Many Requests) or 503 responses, tells the client exactly how many seconds to wait before retrying, making it a standards-based way to honor server-imposed rate limits. Option B is correct because a token bucket algorithm explicitly controls the request rate by issuing tokens at a defined rate and consuming one per request, allowing bursts up to the bucket capacity while preventing sustained over-limit traffic. Option E is correct because retry logic with exponential backoff progressively increases the delay between attempts (e.g., 1s, 2s, 4s, 8s, often with jitter), which reduces request pressure and avoids hammering an API that is throttling the client. Option C is not among the marked answers because a fixed sleep interval is a crude, static approach that does not adapt to the server's actual limit signals and can either waste time or still exceed the quota. Option D is clearly wrong because ignoring the limit and sending requests faster will trigger further 429 responses, potential IP bans, or account suspension rather than handling the rate limit.

Answer analysis

Option-by-option breakdown

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

  • ✓

    Parse the Retry-After header from the response

    Why this is correct

    The Retry-After header tells the client exactly how many seconds to wait before retrying, so parsing it respects the server's advertised rate-limit window rather than guessing. This directly satisfies the scenario's need to handle 429 responses without breaching the API's throttling policy.

  • ✓

    Use a token bucket algorithm to control request rate

    Why this is correct

    A token bucket meters outbound requests, replenishing tokens at a fixed rate so the script never exceeds the API's permitted request frequency. This proactively caps throughput, satisfying the rate-limiting constraint before the server ever returns a 429.

  • ✗

    Sleep for a fixed amount of time between requests

    Why it's wrong here

    A fixed sleep is a valid handling method, so this option is not incorrect; it paces requests below the published limit. It is tempting to reject because it wastes time when the quota is high, but a static delay is the standard baseline before adopting exponential backoff with jitter.

  • ✗

    Ignore the limit and send requests faster

    Why it's wrong here

    Ignoring the limit and sending faster guarantees HTTP 429 responses and eventual throttling or IP blocking, so the script fails rather than completing. It is tempting when a developer assumes the quota is generous, which would only hold for a private, unthrottled endpoint with no published rate limit.

  • ✓

    Implement retry logic with exponential backoff

    Why this is correct

    Exponential backoff increases the delay between successive retries after a 429, reducing request pressure and giving the rate-limit window time to reset. This satisfies the scenario by recovering gracefully from throttling instead of hammering the endpoint.

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 →

How Courseiva writes practice questions · Editorial policy

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.