200-901 Infrastructure and Automation Practice Question
A developer is building a Python application that calls the Cisco DNA Center Intent API to retrieve device health. The application must handle pagination and rate limiting gracefully. After receiving an HTTP 429 response, which action should the application take?
⚠ Common exam trap
The trap here is treating a 429 like a transient network error that can be fixed by immediate retries, when it actually signals a deliberate throttle that requires honoring Retry-After.
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
✓
Read the Retry-After header and wait that many seconds before retrying the request.
When an API returns 429, the client must back off according to the server's Retry-After header rather than retrying aggressively or trying to evade the limit. Immediate retries, transport downgrades, and token rotation do not address the throttling and can worsen it. Respecting Retry-After is the standard, reliable way to recover from rate limiting against the Cisco DNA Center Intent API.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Read the Retry-After header and wait that many seconds before retrying the request.
Why this is correct
An HTTP 429 indicates the client exceeded a rate limit, and well-behaved APIs include a Retry-After header specifying how long to wait. Honoring that value avoids hammering the service and prevents escalating throttling. This is the correct, standards-aligned response for the Cisco DNA Center Intent API and similar REST APIs.
- ✗
Switch from HTTPS to HTTP to bypass the rate limiting mechanism.
Why it's wrong here
Rate limiting is enforced by the API gateway based on client identity and request volume, not by the transport scheme. Downgrading to HTTP would not avoid throttling and would expose credentials and data to interception. This action is both ineffective and a serious security regression, so it cannot resolve the 429 condition.
- ✗
Delete the existing authentication token and request a new one to reset the rate limit counter.
Why it's wrong here
Rate limits are typically tied to the client or token identity over a time window, and re-authenticating does not reset that window. It may even create additional load and trigger further throttling. The correct behavior is to respect the server's backoff guidance rather than attempt to circumvent the limit through token churn.
- ✗
Immediately resend the same request in a tight loop until a 200 response is received.
Why it's wrong here
Retrying immediately in a tight loop ignores the server's throttling signal and will likely extend the block or trigger additional 429 responses. It also wastes resources and can impact other clients. The API expects the client to back off, so this approach is counterproductive and may lead to longer denial windows.
Go deeper
Related to this question
About these practice questions
This 200-901 question is part of Courseiva's 975-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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.