CCAO-F Using the Claude API Practice Question
A developer is implementing retry logic for calls to the Anthropic Messages API in a production service. The service must handle transient failures gracefully without overwhelming the API. Which TWO practices should the developer implement? (Choose two.)
⚠ Common exam trap
The trap here is treating all HTTP errors as retryable, when client errors such as 400 and 401 will never succeed on a repeated identical request.
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
✓
Retry requests that fail with HTTP 429 and HTTP 500 status codes, using exponential backoff with jitter between attempts.
Resilient retry logic targets transient failures such as 429 and 500 responses, spacing attempts with exponential backoff plus jitter to avoid synchronized retry storms. A retry cap, whether by count or total time budget, prevents runaway loops and bounds latency. Client errors like 400 and 401 are not transient and should not be retried, and the API does not redeliver failed requests, so some client-side retry strategy is necessary.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Retry requests that fail with HTTP 429 and HTTP 500 status codes, using exponential backoff with jitter between attempts.
Why this is correct
Status 429 indicates rate limiting and 500 indicates a server-side error, both of which are typically transient. Retrying with exponential backoff and jitter spaces out attempts and avoids synchronized retry storms. Jitter prevents many clients from retrying simultaneously. This combination is a standard resilient pattern that improves success rates without hammering the API during periods of contention.
- ✗
Disable all retries and rely on the API's internal queueing to eventually deliver failed requests.
Why it's wrong here
The Messages API does not queue and redeliver failed requests on the client's behalf; a failed call is simply a failed call. Disabling retries means transient errors immediately surface as failures to the user. Without any retry mechanism, the service loses resilience against brief rate limiting or server hiccups, which are exactly the conditions retries are designed to absorb.
- ✗
Retry all failed requests immediately in a tight loop until they succeed, to minimize latency for the end user.
Why it's wrong here
Immediate retries in a tight loop amplify load during outages or rate limiting and can worsen the condition that caused the failure. It ignores backoff guidance and can exhaust client resources. This approach also risks cascading failures across dependent services. Transient errors need spaced retries, not rapid-fire repetition, so this practice is counterproductive in production.
- ✓
Set a maximum retry count or total elapsed time budget so the service stops retrying after a defined threshold.
Why this is correct
Capping retries by count or elapsed time prevents indefinite retry loops that consume resources and delay failure reporting. Once the threshold is reached, the service can surface an error or fall back to an alternative path. This bounds latency and cost while still allowing a few attempts to recover from brief transient issues, making the retry logic predictable and safe.
- ✗
Retry requests that fail with HTTP 400 and HTTP 401 status codes, since these often resolve on a second attempt.
Why it's wrong here
Status 400 indicates a malformed or invalid request, and 401 indicates an authentication problem. These are client errors that will not resolve by retrying the same payload or credentials. Retrying them wastes resources and can trigger lockouts. The correct action is to fix the request or credentials rather than repeat the call.
About these practice questions
One of 259 original CCAO-F practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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 CCAO-F 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 CCAO-F exam.