Mechanism versus workaround: the pattern behind most CCAR-F questions
Four distinctions the exam tests repeatedly, each one separating people who know how something works from people who know a way around it.
Once you have worked through enough CCAR-F practice items, a shape starts repeating. The question describes a system misbehaving. One option addresses the mechanism causing it. The other three are things that make the symptom go away, or appear to.
The exam consistently rewards the first. That is not a quirk of question writing — it is what "architect" means in this credential. Below are four places the distinction shows up hardest.
1. Iteration caps are not termination conditions
An agentic loop ends because the model returned a stop_reason indicating it is not requesting further tool use. That is the mechanism. Control flow reads stop_reason and decides whether to continue.
An iteration cap — stop after twenty turns — is a safety bound. It exists so a bug cannot run forever. It is not how the loop is supposed to end, and a loop that routinely terminates by hitting its cap is a loop that is broken in some other way.
Questions in this area describe a loop that runs away, or one that stops early, and offer a cap adjustment among the options. Raising the cap on a runaway loop is the workaround; the mechanism question is why stop_reason is not being respected, or why the model keeps requesting tools it has already called.
2. Context degradation is not running out of context
This one catches experienced people, because both problems look like the model getting worse partway through a long session.
Running out of window is a capacity problem. It has a hard boundary and a mechanical fix.
Degradation happens well inside the limit. As a session accumulates verbose tool output, the earlier, more important instructions compete with a growing volume of low-signal text, and the model starts reaching for generic patterns instead of the specifics it discovered earlier. The observable symptom is telling: the agent stops naming the actual class it read and starts saying "this follows the typical repository pattern."
The workaround is a bigger window. The mechanism fix is spending less of it — trimming verbose tool results, extracting structured facts rather than carrying raw text forward, and ordering input so the things that matter are not buried in the middle.
3. A tool description is not documentation
The description is the mechanism by which the model selects a tool. It is not supplementary metadata that helps a human reading the code.
That single reframing answers a whole family of questions. An agent calling lookup_order when it should call get_customer is not a prompting problem; it is an interface problem, and the fix is in the descriptions. Adding "remember to use get_customer for customer lookups" to the system prompt is the workaround — it works until the conversation gets long enough for that instruction to compete with everything else.
The same logic explains when to split a tool and when to consolidate: the question is always whether the model can tell, from the descriptions alone, which one this situation calls for.
4. A guardrail in the prompt is not a guardrail
If an agent has a tool that issues refunds, the refund ceiling belongs in the orchestration layer or in the tool itself. A limit expressed as an instruction is a limit the model can be talked around, and the exam's scenarios — one of which is a support agent with process_refund in its toolset — are built to make that concrete.
The general form: prompts shape behaviour, they do not constrain it. Anything that must hold regardless of what the conversation contains has to be enforced somewhere the conversation cannot reach.
Why the exam is built this way
The scenarios come from real customer deployments, and every distraction option is something someone actually tried. Lowering temperature to fix inconsistent extraction, adding emphasis to reduce false positives, raising a context limit to fix degradation, threading a policy into a system prompt — these are not strawmen. They are the first thing most engineers reach for, and they mostly half-work, which is what makes them durable.
An architect's job is to know why they half-work. That is what the exam is measuring, and it is why reading about a technique is a weaker preparation than having once used the workaround and watched it fail three months later.
Using this while you study
When you get a practice question wrong, the useful question is not "what was the right answer" but "was I picking a workaround?" If you were, the gap is not knowledge of the correct option — it is knowing the mechanism the correct option operates on. Go and read that.
The lessons on agentic loops, tool interface design and context window management are where these four distinctions are set out properly, each with its sources.