Claude Models, Prompting & Context Engineering
13% of the Claude Certified Architect – Professional blueprint — roughly 8 of the 63 questions on a real sitting.
This domain is 13% of the CCAR-P blueprint — about 8 of the 63 questions. It is the smallest of the four technical domains, and the one candidates most often assume they already know because they write prompts every day.
The blueprint covers selecting Claude models against trade-offs, designing system prompts, templates and guardrails, applying prompt engineering techniques, optimising context windows and token usage, and implementing prompt reuse through caching, modular prompts and Skills.
The Professional framing changes what is being asked. A prompt at this level is not a piece of writing, it is a shared, versioned artifact that every request pays for, whose byte-level structure determines your cache hit rate and therefore a large share of your bill. Model selection is not a preference, it is a per-route decision with two independent dials — which model, and how much effort it spends — that you tune against a latency budget you have measured.
The questions reward candidates who can say what a change costs. Enabling caching, raising effort, adding examples, moving a document into retrieval: each has a first-order effect the stem will state and a second-order effect the distractors are built from. If you have never looked at a cache-hit metric or re-measured token counts after a model change, this is the cheapest domain to bring up to standard.
What the exam actually tests
- —Choosing a model and an effort level as two separate decisions against a measured budget
- —Prompt caching as a prefix match: what invalidates it, and how that constrains prompt layout
- —Verifying caching actually works rather than assuming it does
- —Context strategy: what belongs in the window, what belongs in retrieval, what belongs in memory
- —Clearing versus summarising versus persisting, for conversations that outgrow the window
- —When a Skill is the right reuse mechanism instead of a longer system prompt
Model and effort are two dials, not one
Model tier sets a capability and price ceiling; the effort setting controls how much thinking and how many tokens are spent inside that tier. They move independently, and treating them as one dial is the most common architectural mistake here.
The practical consequence: a route that is too slow is frequently better fixed by lowering effort than by downgrading the model, because effort cuts token spend without giving up the model's capability on the hard cases. Conversely, raising effort on an under-performing route is cheaper to try than a migration.
Model selection is also per route, not per system. High-volume extraction, classification and normalisation belong on a fast tier; the judgement step belongs on the capable one. And the version you evaluate is the version you should pin, because behaviour shifts across releases — an unpinned model is an untested one.
Prompt caching is a prefix match, and that dictates layout
Cached content is matched as an exact prefix. Any byte that changes anywhere in the prefix invalidates everything after it. Requests are rendered in a fixed order — tools, then system, then messages — so a change to the tool list invalidates the entire cache, and a change to the system prompt invalidates system and messages.
That single fact drives prompt architecture: stable content first, volatile content last. A timestamp, a request ID, a per-user name interpolated into the system prompt is the classic silent invalidator — no error, just a cache that never reads. Non-deterministic serialisation of a tool list does the same thing.
The economics are worth memorising in shape rather than in decimals: a cache read costs roughly a tenth of the base input price and a write costs a premium over it, so caching pays back after a small number of reads and loses money on a prefix that is used once.
Verify caching; do not assume it
Every response reports cache activity separately from uncached input: tokens written to the cache, tokens read from it, and tokens processed at full price. The diagnostic is simple — if reads stay at zero across repeated requests that should share a prefix, something in the prefix is changing.
This matters at Professional level because caching failures are silent and expensive. Nothing errors. The system behaves correctly and the bill is several times what the design predicted, often for weeks before anyone reconciles it.
Two further gotchas are worth carrying into the exam. The minimum cacheable prefix is model-dependent, so a prompt that cached on one model may silently stop caching on another with no code change. And caches are model-scoped — switching models mid-conversation starts again from cold.
Context engineering: the window is a budget
A large context window is a capacity, not an invitation. Everything in the window is re-processed on every request, so what you load once you pay for repeatedly, and long contexts cost latency as well as money.
Three mechanisms handle conversations that outgrow the budget, and the exam cares about the distinction. Context editing clears stale material — old tool results, old thinking — removing it outright. Compaction summarises earlier history into a condensed form so the thread can continue. External memory persists facts outside the conversation so they survive the session entirely.
Choose by what you need to keep: clear what is genuinely spent, summarise what still shapes the current task, persist what must outlive it. A design that answers 'append it to the conversation' for anything that has to survive the session is the wrong answer.
Reuse: system prompts, modular templates, Skills
Three reuse surfaces with different cost profiles. The system prompt is always loaded and always in force — right for stable policy and role, wrong for task-specific procedure. Tool descriptions load per request and drive triggering, so they carry contract detail and when-to-call guidance, not worked examples. A Skill keeps its description in context and loads its body only when the task calls for it: progressive disclosure, and the right home for a procedure that matters to one task in twenty.
The decision rule is what fraction of requests need the content. Moving rarely-needed procedure out of the system prompt is one of the highest-leverage cost changes available, and it usually improves adherence too, because less is competing for attention.
Where candidates go wrong
Trap 1 — 'Put the important dynamic content first so the model sees it'
Recency and salience arguments are about the model; caching is about bytes. Volatile content placed early in the prefix destroys the cacheable span behind it, and the failure is silent. The correct layout puts the frozen system prompt and deterministic tool list first and the varying question last. If dynamic operator context genuinely has to arrive mid-conversation, the cache-preserving move is to add it after the cached history rather than to edit the top of the prompt.
Trap 2 — 'A million-token window means we do not need retrieval'
Filling a large window works and is a legitimate design for a small corpus that rarely changes. It is a bad default because the cost is recurring — every request pays for everything you loaded — and because the corpus is now pinned to the prompt, so a document update means a full cache rebuild. Retrieval is a freshness and cost strategy, not only a capacity workaround. The exam-relevant version: 'the whole corpus fits' is not by itself a reason to skip retrieval.
Trap 3 — 'Emphasis makes instructions stick'
Prompts full of CRITICAL, MUST and NEVER were written for older models that under-followed instructions. Current models follow the system prompt closely, so the same text over-triggers — a tool marked as critical gets called when it should not be, and a rule marked as absolute gets applied in cases it was never meant for. When several instructions are all marked critical, the marker stops carrying information. Dialling the language back is usually the fix, not adding another guardrail on top.
Trap 4 — 'Lower the effort setting to make responses shorter'
Effort governs how much thinking and total token spend a request gets; it is not a length control for the visible answer, and reducing it to shorten output tends to cost quality without reliably shortening anything. Verbosity is a prompting problem and responds to explicit instruction. The mirrored error is also examinable: instructing the model to 'think less' is not a substitute for the effort dial, because it changes what the model says about its process rather than what the request is budgeted.
How to study this domain
Spend your time on the two things that are measurable, because they are what the questions turn on: caching and token accounting.
Take one real prompt you own and trace it end to end. Write out the render order, mark where the prefix stops being stable, and identify what would have to change for the cache to miss. Then look at an actual response's usage fields and confirm reads are non-zero. Architects who have done this once stop falling for the layout distractors, because the failure mode is no longer abstract.
Second, re-measure token counts rather than estimating them. Counts are model-specific — a count taken on one model does not transfer, and a general-purpose tokeniser from another vendor is simply wrong for Claude. Any question comparing cost across models is testing whether you know the comparison must be re-measured.
Finally, audit one of your own system prompts against current model behaviour: delete emphasis written for a model you no longer use, move task-specific procedure into a Skill, and check whether the examples you pay for on every request still earn their place.
Common questions
How many CCAR-P questions come from this domain?
13% of the blueprint, which is about 8 of the 63 questions. It is the smallest technical domain, but it overlaps heavily with Integration and Evaluation — caching, token cost and context strategy show up inside questions weighted to those domains too.
Do I need to memorise model IDs, prices and parameter names?
No. The exam tests decisions, not the catalogue. You should be able to reason about tiering — fast model for high-volume mechanical steps, capable model for judgement — and know that effort is a separate control from model choice. Prices change; the trade-off structure does not.
What is the single highest-yield thing to learn here?
That prompt caching is an exact prefix match, and therefore that prompt layout is an architectural decision rather than a stylistic one. It explains the correct answer to caching questions, cost questions, and several Integration questions about why a system got expensive without any traffic change.
Context editing, compaction, external memory — how do I keep them straight?
By what happens to the content. Editing clears it, compaction summarises it, memory persists it outside the conversation. Pick by whether the material is spent, still relevant to the current task, or needs to survive the session.
Is chain-of-thought prompting still the right answer?
Treat it as a dated technique on current models, which decide how much to reason on their own and expose an effort control for depth. Instructing a model to think step by step is at best redundant and at worst competes with that mechanism. Where a question offers both, the configuration answer beats the incantation.
Practise this domain
The CCAR-P bank is weighted to the blueprint above, so 13% of what you practise is this domain — and every option carries a written explanation, not just the correct one.
See CCAR-POther CCAR-P domains
Not affiliated with or endorsed by Anthropic. Domain names and weightings are taken from the published exam guide; always check the official guide before booking.