CCAR-P Practice Question: Developer Productivity and Operational Enablement
Exhibit
2024-10-12 14:02:01 ERROR: Anthropic.Client: 429 Too Many Requests (Rate limit exceeded) 2024-10-12 14:02:02 WARN: Retrying in 500ms... 2024-10-12 14:02:03 WARN: Retrying in 1000ms...
Refer to the exhibit. The application is hitting rate limits during peak hours. What is the best architectural change to improve operational resilience?
⚠ Common exam trap
Candidates often choose basic synchronous retry loops or client-side caching instead of exponential backoff with jitter, failing to realize that static retries exacerbate traffic spikes and worsen rate-limit errors during peak operational windows.
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
✓
Implement an exponential backoff strategy with jitter.
Implementing an exponential backoff strategy with jitter is the industry-standard approach for handling 429 rate-limiting errors. Unlike static retries, this approach prevents the 'thundering herd' problem, where multiple failed requests attempt to reconnect simultaneously, further stressing the service. This enhances operational stability, ensures more graceful handling of high-traffic scenarios, and improves the overall reliability of the system, which is a key requirement for professional architects.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Increase the timeout duration of the API calls indefinitely.
Why it's wrong here
Indefinite timeouts are dangerous and can cause thread exhaustion in the application, leading to cascading failures. It does not address the 429 error and will only make the system less responsive. Effective error handling must be active and intelligent, not simply passive waiting for longer periods.
- ✓
Implement an exponential backoff strategy with jitter.
Why this is correct
Exponential backoff with jitter is the recommended strategy for handling transient rate limits. By increasing the wait time between retries and adding randomness, the application avoids overwhelming the API upon recovery. This ensures a stable, resilient architecture that handles traffic spikes gracefully without persistent errors.
- ✗
Bypass the API gateway and send requests directly to the model's backend IP.
Why it's wrong here
Bypassing the API gateway is a violation of security protocols and operational governance. It does not prevent rate limiting, as the model provider's service will still enforce these limits at the infrastructure level. This approach is unstable, unauthorized, and provides no solution to the rate-limiting problem.
- ✗
Disable all retries to prevent the application from crashing.
Why it's wrong here
Disabling retries means that every transient error results in a failed user request, leading to a poor user experience. While it prevents cascading failure, it is not an effective solution to the underlying need for high availability. Intelligent retries are essential for robust LLM application design.
About these practice questions
Courseiva writes every CCAR-P question from scratch — 262 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 →
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 Anthropic exam blueprint
This CCAR-P practice question is part of Courseiva's free Anthropic 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 CCAR-P exam.