CCAR-P Practice Question: Developer Productivity and Operational Enablement
A fintech platform runs a Claude-powered transaction summarizer in production. Latency spikes during market open, and the team suspects that requests are being retried unnecessarily when the API returns overloaded errors. They want to make retry behavior observable and tunable without redeploying each service. Which design best meets that goal?
⚠ Common exam trap
The trap here is assuming that retrying harder or faster improves reliability, when tight-loop retries during overload actually amplify the problem and hide the evidence needed to diagnose it.
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
✓
Centralize retry logic in a shared client with exponential backoff, jitter, and a configurable maximum attempt count exposed as environment variables, and emit structured metrics for retry reasons and attempt counts.
Centralizing retry behavior in a shared client makes it consistent and configurable, while exponential backoff with jitter prevents synchronized retry storms during market open. Structured metrics on retry reasons and attempt counts provide the observability needed to confirm whether overloaded errors are the trigger, and environment-variable tuning allows adjustment without redeploying each service.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Route all requests through a fixed-size thread pool and rely on occasional gateway timeouts to shed load, with no client-side retry configuration.
Why it's wrong here
Relying on gateway timeouts is an uncontrolled shedding mechanism that produces inconsistent failures and gives operators no visibility into retry causes. It also leaves retry policy undefined, so behavior cannot be tuned per environment. Latency during market open would remain unpredictable, and the team still could not distinguish overload from other faults.
- ✓
Centralize retry logic in a shared client with exponential backoff, jitter, and a configurable maximum attempt count exposed as environment variables, and emit structured metrics for retry reasons and attempt counts.
Why this is correct
A shared client with backoff, jitter, and a tunable attempt cap lets operators adjust behavior through configuration rather than code changes. Structured metrics on retry reasons and attempt counts make the overloaded-error pattern visible during market open. This combination directly satisfies both observability and tunability while preventing synchronized retry storms.
- ✗
Disable retries entirely and surface overloaded errors to end users, instructing them to resubmit the transaction manually.
Why it's wrong here
Removing retries converts transient overload into user-visible failures and manual work, which is unacceptable for a production transaction summarizer. It also discards the legitimate benefit of retrying after a short backoff. No metrics or tuning capability are added, so the team gains neither observability nor control.
- ✗
Have each service catch overloaded errors and immediately retry in a tight loop up to ten times, logging only the final success or failure.
Why it's wrong here
Immediate tight-loop retries amplify load precisely when the API is already overloaded, worsening the latency spikes. Logging only final outcomes hides the retry volume, so operators cannot diagnose the pattern. Because the logic lives in each service, changing the attempt count requires a redeploy, failing the tunability requirement.
About these practice questions
One of 262 original CCAR-P 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 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.