There is a family of questions in this exam's published objectives that splits candidates two ways, and the advice most preparation material gives you, including ours, only covers one of them.
The scenario gives you a system that must never do something. A classifier that can only return categories from a fixed list. An agent that must not run destructive SQL. A step that must not start before an earlier one has completed. Then it asks which option satisfies the requirement.
One option adds a clear, well written instruction. Another adds a hook, a gate, a scope restriction or a validation step.
The standard advice is that infrastructure enforces and prompts only guide, so pick the infrastructure. Our own anti-patterns post says exactly that, and it is right about half the time.
Where these questions actually sit #
Most people file this under Prompt Engineering and Structured Output. That is where the schema discussion belongs, and it is where the vocabulary of validation gets taught.
In our own bank, the questions where a code-level answer is keyed over a prompt-level distractor cluster in Agentic Architecture and Orchestration: twelve items there against five in Prompt Engineering. Hooks, prerequisite gates, subagent isolation, tool scoping.
But the reverse runs the other way. Of the items where the prompt-level answer is correct and the code-level option is marked wrong, two thirds are in Prompt Engineering.
So if you revise this topic by reading about structured output, you will meet the cases where wording is right and miss most of the cases where it is not. And if you revise it by memorising "always enforce in code", you will do the opposite.
The guide's own phrasing is conditional #
This is the part worth taking from the published guide directly.
Each time the guide sets a deterministic mechanism against a prompt instruction, the condition sits beside it. Hooks and gates appear "when deterministic compliance is required" and "when business rules require guaranteed compliance". Even the strongest statement about structured output, that it is the most reliable approach for guaranteed schema-compliant output, carries "guaranteed" inside it.
The guide never says enforcement is generally better. It says it is what you reach for when a guarantee is what the requirement demands.
Beside those, the same guide names prompt-level answers elsewhere. Normalisation rules belong in the prompt alongside a schema. Few-shot examples are named as the most effective technique for format consistency. Tool descriptions are named as the primary mechanism for tool selection, not a routing layer.
The test that works #
Does the requirement need a guarantee, or does it need accuracy?
If something must never happen or must always hold, and a violation is a business or safety failure rather than a quality one, the requirement needs enforcement outside the model.
If something needs to be done well, consistently, or in a particular format, that is a prompting problem, and adding infrastructure is the wrong answer.
The reliable way to tell them apart is not the wording of the requirement. It is asking whether the consequence lands outside the conversation. Downstream code branches on the category. A deletion touches production. A step commits something irreversible. When the failure escapes the conversation and lands somewhere else, you need a guarantee.
When it does not, when the cost of a bad output is that the output is bad, you need accuracy.
Why the obvious shortcut fails #
The tempting version of this test is to scan the stem for "never", "always" or "must".
That does not work, and it is worth knowing why before you rely on it. In our bank, guarantee words appear in at most half the items where a code-level answer is correct. The rest state the requirement without them. Meanwhile at least one item where the prompt-level answer is correct contains "always" inside a quoted system prompt line, which is precisely the trap: the word is in the scenario because someone wrote it into an instruction, and the instruction is the thing being examined.
Read the consequence, not the adjectives.
Three shapes worth recognising in the wrong options #
From hand-classifying the distractors in our own items in this family: Prompt wording offered as the guarantee. The most common by some distance. An instruction that names the constraint clearly and emphatically, sitting where a mechanism should be.
A real mechanism at the wrong scope. The option names something that genuinely enforces things, applied where it does not cover the failure. A hook on an event that fires after the damage. A tool withdrawn from the subagent that actually needs it. A forced tool choice that cannot sequence a second call.
A false claim about how a real mechanism behaves. Harder to spot, because the mechanism is right and the described behaviour is not. Hooks that retry. Hooks configured somewhere they do not live. A strict schema that fills missing fields from the source document.
There is also a smaller group worth naming separately, because it catches experienced people: temperature zero, or a change of model, offered as a substitute for a guarantee. Neither converts a probability into a certainty. Temperature zero is genuinely the right answer to some consistency questions, which is what makes it effective as a distractor everywhere else.
How to use this while revising #
Take questions you have already answered in this family and, before looking at the options, write down where the consequence of a failure lands. Inside the conversation, or outside it.
If you can classify that correctly, the right option usually becomes obvious. If you cannot, the wrong answer will keep looking reasonable no matter how many times you review it. Then check which direction your errors run. Reaching for infrastructure on an accuracy question and reaching for wording on a guarantee question are different mistakes with different fixes. The first means you have over-corrected, probably from advice like ours. The second means you have not yet internalised that an instruction is a request.
A worked example of this family, with the full explanation, is in our free questions post.
The one sentence version #
An instruction changes what the model is likely to do. A hook, a gate or a validation step changes what the system is able to do. Read where the failure lands, decide which one the requirement needs, and the option that mixes them up will stand out.
For the structured output side of this, including where a schema stops helping, see the prompt engineering and structured output guide. For the orchestration patterns these questions sit inside, the agentic architecture guide covers the wider domain. Independent preparation material for the CCAR-F exam, also written as CCA-F. Not affiliated with Anthropic; we do not sell the exam and cannot register you for it. Our practice question bank carries a written explanation on every question, and the free diagnostic is ten questions and needs no account.