Claude Certification Blog
Models, prompting and context: the CCAR-P domain that maintains a prompt
One CCAR-P domain treats a prompt as an asset with a lifecycle rather than a message you send, and four of its vocabulary items appear on no other Claude blueprint.
Claude Models, Prompting and Context Engineering is 13% of CCAR-P — about 8 of 63 items — across five objectives. Four terms inside them appear in no other blueprint in the programme: templates, caching, prompt reuse and chain-of-thought. They point the same way, at a domain that treats a prompt as something an organisation maintains rather than something a person writes.
Five objectives, eight items
| Objective | Subject | What it turns on |
|---|---|---|
| O07 | Model selection against trade-offs | What you gave up, stated |
| O08 | System prompts, templates and guardrails | The standing instruction, designed once |
| O09 | Prompt engineering technique | Zero-shot, few-shot, chain-of-thought by name |
| O10 | Context window and token management | What fits, what it costs, what to cut |
| O11 | Prompt reuse strategies | Caching, modular prompts and Skills |
Between one and two items each, on a paper where the heaviest domain is 19% and the lightest is 7%. The flatness of CCAR-P is its defining feature and the reason an even plan is closer to right here than on any other track — see the published weights for the comparison.
A prompt with a lifecycle
The framing worth carrying into the exam is that a prompt here has a life beyond the request it was written for. It gets templated, so several teams start from the same place. It gets versioned, so a change is a decision rather than a surprise. It gets cached, so the stable part is paid for once. And it gets shared, which means somebody has to maintain it.
None of that appears on the other three tracks. The developer exam names prompt engineering as a 4.6% skill and stops there; the associate exam asks about writing and iterating. Only here does the blueprint ask what happens to a prompt after it works.
Three ways to stop retyping
Caching is about cost and depends entirely on arrangement: a request whose stable material leads can be reused from that point, and the same content assembled in the order it was written cannot. Ordering is a design decision with a price on it, which is the same point the developer track makes inside cost and token management.
Modular prompts are about maintenance. A prompt duplicated across five services is five things to change when one rule moves, and the version that gets missed is the one nobody remembers exists. Skills are about packaging: a repeatable way of working invoked the same way each time rather than reproduced from memory — the same judgment CCDV-F calls agentic customization.
Ask what breaks when this prompt changes
The question that separates the three. If the answer is “the bill”, you are looking at caching. If it is “five copies drift apart”, modularity. If it is “everyone reinvents the procedure”, packaging. The scenario always says which, and it usually says it in one sentence.
The techniques it names
Zero-shot, few-shot and chain-of-thought, listed in the objective. That is unusual — the other three blueprints describe prompting in terms of what it achieves rather than naming techniques, and CCAR-P is the only one that says chain-of-thought at all.
Naming them is not the same as testing recall of them. The examinable question stays what it is everywhere else in the programme: given this specific failure, which technique addresses it. A scenario where output is inconsistent across similar inputs is a few-shot problem; one where the answer is right but the working is unauditable is a different one. The cross-track shape of that is in prompt engineering on the Claude exams.
Where it meets three other domains
This domain has more borders than most. Its guardrail half meets governance from the design side — designing a control against placing one, covered in CCAR-P governance. Its context and token objective meets the optimisation objective in evaluation and testing, where the same trade is judged against measurements. And model selection is the per-call end of the architecture decisions in solution design.
The practical effect is that a scenario touching this domain often has a second domain in it, and the item is decided by which one the question is asking about. That is the flat-spread problem this paper has generally, and it is sharpest here.
How to study it
An evening and a half. Most of the first on reuse and templates, because that is the material with no counterpart on any other track and therefore the material your experience is least likely to cover. The rest on the technique objective, which is mostly recognition once you can name the failure.
Model selection needs least of all, because the judgment is the same one every track asks: name what you gave up. A choice with no stated reason is not an answer, and the reason has to reference the scenario rather than a general preference for quality or speed.
Key takeaways
- Thirteen percent, eight items, five objectives. One to two items each on the flattest paper in the programme.
- Four terms exist only here. Templates, caching, prompt reuse and chain-of-thought appear on no other blueprint.
- A prompt is an asset. Templated, versioned, cached and shared, which means somebody maintains it.
- Reuse is three different problems. Cost, maintenance and packaging — and an option can solve the wrong one.
- Caching rewards ordering. Stable material first, or the reuse the mechanism depends on is not available.
- Naming a technique is not testing recall. The question is still which technique addresses the failure described.
The material your experience is least likely to cover
Most architects arrive fluent in model trade-offs and prompting technique, and having never been asked to treat a prompt as a maintained asset. That is two or three items sitting outside the shape of your own practice, which is exactly what a timed paper surfaces. Our claude certification study guide covers how to sequence them.
See the CCAR-P blueprintQuestions
Frequently asked
The follow-up questions people search next.
What is in the CCAR-P models and prompting domain?
Five objectives across 13% of the exam — about 8 of 63 items: model selection against trade-offs, system prompts and templates with guardrails, prompt engineering technique, context window and token management, and prompt reuse strategies.
Which prompting techniques does the exam name?
CCAR-P names zero-shot, few-shot and chain-of-thought directly in one objective. It is the only blueprint in the programme that names chain-of-thought, and the only one that names templates, caching or prompt reuse.
What are prompt reuse strategies?
The objective names three: caching, modular prompts and Skills. They solve different problems — paying once for a stable block, changing one thing instead of five copies, and packaging a way of working so it is invoked rather than reproduced — and the exam expects them told apart.
Why does prompt caching depend on ordering?
Because reuse is the whole mechanism. A prompt whose stable material leads and whose varying material follows can be reused from the stable point; the same content assembled the other way round cannot. Ordering is therefore a design decision with a price attached.
Is this domain the same as prompt engineering on the other exams?
Only partly. The technique objective is common ground, but no other track asks about templates, caching, reuse or the lifecycle of a prompt as a shared asset. That framing is what makes this an architect’s version of the subject.
Keep reading
Related posts
Not affiliated with, or endorsed by, Anthropic or Pearson VUE. Details are summarised from publicly published program information and can change — always confirm against the official exam guide before booking.