CCAR-P Advanced Agentic Architecture Practice Question
An orchestration agent runs a nightly workflow that fans out to 12 subagents, each calling a partner REST API. Partner calls intermittently return HTTP 429 with a Retry-After header. The orchestrator currently retries immediately in a tight loop, causing cascading 429s and duplicate side effects on the partner systems. Which architectural change best addresses both the throttling and the duplicate side effects?
⚠ Common exam trap
The trap here is assuming that making the model 'smarter' about errors, via more tokens or more context, substitutes for enforcing rate limits and idempotency at the orchestration layer.
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
✓
Introduce a shared token-bucket rate limiter in front of the partner calls plus idempotency keys on every mutating request, with subagents respecting Retry-After.
Bursty fan-out against a rate-limited partner needs two coordinated controls: a shared limiter so the aggregate request rate stays under the partner's ceiling, and idempotency keys so a retried mutating call cannot create a second side effect. Honoring Retry-After aligns retry timing with the partner's guidance. Token or context changes operate on model text, not on outbound traffic, and serializing the workload removes parallelism without addressing throttling or duplication.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Reduce the fan-out to a single subagent that processes all 12 partners sequentially with no retry logic at all.
Why it's wrong here
Collapsing to one sequential worker removes parallelism but does not solve intermittent 429s, since even a single caller will eventually exceed the partner's limit. Dropping retry logic entirely means transient throttling becomes permanent failure, and without idempotency keys a retried mutating call after a timeout can still duplicate. This sacrifices throughput without fixing either root cause.
- ✗
Switch every subagent to a larger context window so each can hold the full history of prior 429 responses and learn to avoid them.
Why it's wrong here
Context size affects how much conversation history fits in a single request; it does not enforce outbound pacing or make partner systems deduplicate writes. A subagent can see every past 429 and still fire simultaneous calls that trip the same limit. Duplicate side effects come from repeated mutating requests, which larger context cannot detect or suppress.
- ✓
Introduce a shared token-bucket rate limiter in front of the partner calls plus idempotency keys on every mutating request, with subagents respecting Retry-After.
Why this is correct
A shared token bucket caps aggregate concurrency across all 12 subagents so bursts stop triggering 429s, while Retry-After compliance paces retries. Idempotency keys let the partner recognize a repeated mutating call and return the original result instead of creating a second record, which directly eliminates duplicate side effects. Together these address throttling and duplication at the architecture layer rather than relying on model behavior.
- ✗
Increase the orchestrator's max_tokens so the model can reason longer about each 429 before deciding to retry.
Why it's wrong here
Token limits govern how much text the model may generate or accept, not how outbound calls are paced or deduplicated. Raising max_tokens does nothing to honor Retry-After, does not reduce burst concurrency against the partner API, and cannot prevent a subagent from re-issuing a request whose side effect already landed. The cascading 429s and duplicate writes would persist unchanged.
About these practice questions
This CCAR-P question is part of Courseiva's 262-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 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.