Claude Models, Prompting and Context Engineering

What this domain tests

13% — roughly 8 of the 63 scored items. This is the most technical domain that is still framed as architecture rather than implementation: you will not be asked to write a prompt, you will be asked which prompting or context strategy a system should adopt and what it costs.

The items cluster into three species:

• Selection judgment. Given a workload shape, which model tier, which reasoning depth, which prompting technique, which reuse mechanism.
• Diagnosis. A symptom (inconsistent format, slow first token, cost that scaled worse than volume, degraded quality on long conversations) and you name the mechanism responsible.
• Mechanism recall. Prompt caching is the one place in this domain with genuinely memorizable rules — prefix matching, render order, and the economics. It is worth knowing cold because the guide's own published sample item for this domain is a caching-and-layout question.

The exam guide's preparation section tells you where the weight sits: it asks candidates to practice architectural decision-making around model selection, integration protocols, and security trade-offs. Read that as: prefer the answer that names the trade-off and picks a side.

Theory outline

1. Selecting models on trade-offs (Task 2.1)

The tier framework. Within a model family, tiers trade capability against cost and latency. Rather than memorizing names and prices — which move — internalize the shape:

A production architecture is a portfolio, not a model choice. Route by task. A support system might classify intent on the fast tier, draft a response on the mid tier, and escalate genuinely ambiguous cases to the frontier tier — with a confidence or complexity signal deciding the ladder. The exam's framing of "select appropriate models" is plural for a reason; an option that assigns one model to an entire heterogeneous system is usually the distractor.

Selection inputs, in the order they usually decide the answer:

1. Accuracy bar on your own eval. Public benchmarks measure someone else's distribution. The rule: the cheapest tier that clears your bar wins.
2. Latency budget. Interactive paths constrain both tier and reasoning depth. Streaming changes perceived latency but not total.
3. Cost at forecast volume. Per-call differences that look trivial multiply by request count; run the arithmetic at peak, not at pilot volume.
4. Context window requirement. Does the task genuinely need a large window, or is that a retrieval problem in disguise (see Task 2.4)?
5. Tool-use and instruction-following reliability. For agentic paths this often matters more than raw reasoning; it is the failure mode that produces silent wrong actions.
6. Deployment surface. Feature availability is not identical across the first-party API and the various cloud-marketplace surfaces; a feature your design depends on may not exist where the customer must deploy. Verify per platform.
7. Data handling constraints. Retention and residency requirements can eliminate an otherwise ideal option before capability is even discussed.

Reasoning depth is a second, cheaper dial. Modern Claude models support adaptive thinking together with an effort level, which controls how much reasoning and tool activity the model spends before answering. Architecturally this matters more than it sounds: raising effort is often a cheaper way to buy accuracy than moving up a tier, and lowering effort is the first thing to try when a route is too slow or too expensive. Two practical rules — raise the dial before you change the tier, and lower the dial before you downgrade the tier. Note that the older pattern of specifying a fixed thinking-token budget is legacy configuration on current models; treat "adaptive thinking plus an effort level" as the current control and verify exact parameter support against the provider documentation for the model you deploy (this space changes; anything you memorize should carry an "as of" date — this module is current as of August 2026).

Anti-patterns:

• Frontier tier everywhere "to be safe." You pay in cost and latency on every request, and on simple tasks extra deliberation can actively hurt.
• One model for the whole system, no routing.
• Downgrading a tier to fix a cost problem without re-running the evaluation suite. A cost win that costs accuracy is a trade, not an optimization, and it needs to be measured.
• Switching models mid-conversation without accounting for the cache invalidation it causes (caches are model-scoped — see Task 2.5).
• Selecting on a public leaderboard rather than a task-representative eval.

Model version pinning and deprecation planning are covered in the Stakeholder Communication and Lifecycle module — architecturally they are expectation-management concerns, and the exam frames them there.

2. System prompts, templates, and guardrails (Task 2.2)

What belongs in a system prompt: role and scope, durable domain context, operating rules, tool-use policy, the output contract, refusal and escalation behavior, and — routinely forgotten — the rule for what to do when required information is missing. Without that last one, the model's fallback is a confident guess.

What does not belong: per-request data, anything volatile (timestamps, request identifiers, the current user's name), and secrets of any kind. Credentials placed in a prompt persist in conversation history and anywhere that history is stored or replayed.

The layout rule pays twice. Putting stable content in the system prompt and volatile content later in the message array is good prompt hygiene — and it is precisely the layout that makes prompt caching possible. Architects who get section 5 right get section 2 right for free, and vice versa.

Templates, not concatenation. Parameterize prompts with named slots. Delimit any injected content — retrieved passages, user-pasted documents, tool output — with clear markers and a label saying what it is. Undelimited concatenation is how a document's own text starts reading as instructions.

Guardrails come in three layers, and the exam tests whether you know which layer a given requirement belongs in.

The rule to carry into the exam: a requirement stated as "must never" or attached to a dollar figure, a regulation, or an irreversible action does not belong in the prompt layer. The seductive wrong answer is always "strengthen the instruction." Governance and safety controls are Domain 5's territory; what Domain 2 tests is your recognition that a prompt is not a control.

Prompt injection is a design constraint, not a prompt-writing problem. Any content the system did not author is untrusted: retrieved documents, uploaded files, web pages, third-party tool output, and other agents' output. Mitigations, in order of strength: keep consequential actions behind deterministic checks outside the model; keep authority in the trusted channel (the system prompt or a privileged operator channel) rather than in text that untrusted content could imitate; delimit and label untrusted content explicitly as data; and give the model an explicit instruction that material inside those markers is information to be considered, never instructions to be followed.

Prompts are production configuration — govern them like code. A short but load-bearing subsection:

• Version every prompt, with an owner.
• Review changes through the same process as code.
• Tie each version to the evaluation run that justified it and to the model and configuration it was tuned against — a prompt tuned on one model and one effort level is not automatically valid on another.
• Keep rollback as easy as deployment.

The anti-pattern is the prompt edited live in a console with no diff, no owner, and no eval: behavior changes, nobody can say when, and last month's quality numbers become unreproducible.

3. Prompt engineering techniques (Task 2.3)

The official statement names three techniques. The exam tests selection among them, not execution.

Three refinements that separate a senior answer from a plausible one:

Examples must span the distribution. Few-shot examples are training-by-demonstration for that call. If all your examples are clean, well-formed inputs, the model learns that inputs are clean. Include the awkward cases and, where relevant, an example of the correct behavior on a case that should be refused or escalated.

On models with adaptive thinking, reasoning depth has a configuration dial as well as a prompt lever. Use the parameter (effort) to buy depth; use the prompt to shape what reasoning is surfaced and in what form. Asking for lengthy visible step-by-step reasoning when the consumer is code is a common design error — you pay output tokens for text nobody reads.

When the consumer is code, constrain the format rather than requesting it. Schema-constrained output and strict tool schemas guarantee a parseable shape; "please respond in JSON" plus hopeful parsing is a class of production incident.

The other named anti-pattern: the mega-prompt that asks for five things at once. Decompose into chained steps with validation between them — errors in a single mega-prompt propagate silently and are hard to attribute. (Decomposition strategy itself belongs to Solution Design.)

Exam angle by symptom:

4. Context windows and token usage (Task 2.4)

Treat the context window as a budget you allocate, not a container you fill. A defensible design assigns shares to: the system prompt and tool definitions, retrieved context, conversation history, and a reserve for output. Large windows do not make the allocation unnecessary — cost is linear in tokens, and packing a window with marginally relevant material dilutes attention on the material that matters.

Long context versus retrieval is the decision this task statement most often tests. Domain 3 owns pipeline construction; Domain 2 owns the choice.

Output tokens need headroom. On models where reasoning happens before the visible answer, the response cap covers both. A cap sized tightly around the expected answer can be consumed by reasoning and truncate mid-sentence — a failure that looks like a quality problem and is actually a configuration problem.

Measure, do not estimate. Use the provider's token-counting endpoint against the same model you will deploy. Tokenizers from other vendors give wrong numbers for Claude, and token counts for identical text differ across model generations — so counts measured on an older model do not transfer to a newer one. Re-baseline whenever the model changes.

Fleet-level arithmetic. Context budget per request multiplied by request volume is your bill. A two-thousand-token system prompt is nothing on one call and a line item at ten million. This is the framing that turns a prompt-engineering detail into an architecture decision, and it is the framing the exam prefers.

5. Prompt reuse: caching, modular prompts, and Skills (Task 2.5)

Prompt caching

This is the highest-value mechanism in the domain, and the guide's own published sample item for Domain 2 is a caching-and-layout question. Know these rules cold.

• It is a prefix match. The cache key derives from the exact bytes up to each breakpoint. One byte changed anywhere invalidates everything after that point.
• Render order is tools, then system, then messages. Stable content must physically precede volatile content. A breakpoint on the final system block therefore covers the tool definitions as well.
• Breakpoints are markers on content blocks, and a request supports a small maximum number of them — four.
• There is a minimum cacheable prefix, it is model-dependent, and it is not monotonic across generations. A prompt long enough to cache on one model may silently fail to cache on another, older or newer. Below the minimum you get no error and no cache entry — just zeros in the usage numbers. Look the value up for the specific model you deploy rather than memorizing one number.
• Economics. Cache reads cost roughly a tenth of base input price. Cache writes cost more than a normal request — about 1.25x for the short time-to-live and about 2x for the long one. Break-even is therefore roughly two reads on the short TTL and three on the long one. The long TTL keeps entries alive across idle gaps in bursty traffic but needs more reads to pay for its heavier write.
• Verify empirically. The usage object reports how many tokens were written to cache and how many were read from it. If the read count stays at zero across repeated requests that you believe share a prefix, something is invalidating it.

Silent invalidators — the diagnosis checklist:

Architectural consequences worth stating explicitly, because they are what the exam actually asks:

• Freeze the system prompt; inject dynamic context later in the message array instead of interpolating it into the prompt header.
• Serialize tool definitions deterministically and keep the set stable for the life of a conversation.
• A forked or sub-agent call that rebuilds the prompt slightly differently misses the parent's cache entirely — reuse the parent's system, tools, and model verbatim and append fork-specific content at the end.
• Concurrent identical requests fired simultaneously all miss, because none can read an entry the others are still writing. Fan-out patterns should let one request establish the cache first.

Modular prompts

Compose prompts from reviewed, individually owned fragments: a shared policy block, a per-tenant or per-product block, a task block. The composition constraint follows directly from prefix matching: shared fragments go first. A per-tenant block placed ahead of the shared policy destroys cross-tenant cache sharing for no benefit, and it is a favorite distractor because it looks tidy.

Skills

A Skill packages task-specific instructions and supporting files that the model loads on demand. The mechanism is progressive disclosure: a short description sits in context by default, and the full content is read only when the task calls for it. That property is the whole architectural point — you get a large body of specialized procedure available without paying for it on every request.

Distinguish Skills from adjacent things the exam may offer as distractors: a tool performs an action, a Skill supplies know-how; few-shot examples demonstrate a format, a Skill carries a procedure; a stuffed system prompt achieves the same coverage but is paid for on every request and dilutes attention on the task at hand.

Worked problems

Problem 1. A document-classification service processes about two million requests a day against a fixed set of eighteen labels. The team runs it on the frontier tier "for accuracy." Cost is now the top complaint and p95 latency is above the interactive budget. What should the architect do?

A. Reduce the number of labels to make the task easier B. Evaluate the fast and mid tiers on a representative labelled sample, adopt the cheapest tier that clears the accuracy bar, and route only low-confidence cases upward C. Keep the frontier tier and add more instances to reduce latency D. Keep the frontier tier but shorten the system prompt to cut cost

Approach: A narrow, high-volume task with a closed label set is the canonical fast-tier workload, and the exam's selection rule is the cheapest tier that clears your bar on your own eval. The confidence-based escalation ladder preserves the hard cases without paying frontier prices on the ninety-plus percent that are easy.

Why the others fail: A changes the product to fit the infrastructure. C addresses throughput, not per-request latency, and leaves the cost problem untouched. D trims a fraction of input tokens while the per-token tier premium — the actual driver — stays.

Answer: B

Problem 2. A legal-research assistant sends the same 9,000-token policy corpus and system prompt on every request, followed by a short varying question. Cost is high and time-to-first-token is poor. Which change addresses both most directly?

A. Truncate the policy corpus to the first 2,000 tokens B. Place the stable system prompt and policy corpus before the varying question and enable prompt caching with a breakpoint at the end of the stable portion C. Move the policy corpus into a few-shot example block D. Switch to the fastest available tier

Approach: A large invariant prefix followed by a small variable suffix is the textbook caching layout. Ordering stable content first and marking the breakpoint at the end of the shared portion lets every subsequent request read the prefix at roughly a tenth of input price and skip re-processing it, which cuts both cost and time-to-first-token without discarding any required context.

Why the others fail: A throws away policy the task depends on. C relocates the text without creating a reusable cached prefix — few-shot framing is about demonstration, not reuse. D trades quality for speed on a task where the corpus, not the tier, is the cost driver, and a smaller model still re-reads 9,000 tokens every call.

Answer: B

Problem 3. A team enables prompt caching on a high-volume endpoint. After a week, the usage numbers show cache reads are still zero on every request even though the system prompt "hasn't changed." Select two likely causes.

A. The system prompt header interpolates the current date and time B. Tool definitions are serialized from an unordered map, so their byte order varies between requests C. The requests use the long time-to-live rather than the short one D. The breakpoint was placed on the last system block rather than the first E. Cache reads are only reported for streaming requests

Approach: Zero reads across supposedly identical prefixes always means the prefix is not identical. A timestamp in the header changes the bytes on every call; non-deterministic tool serialization changes bytes at the very front of the render order, which invalidates everything after it. Both are named silent invalidators.

Why the others fail: C changes economics and entry lifetime, not whether a match occurs. D describes correct placement — the last system block is exactly where a breakpoint should go to cover tools and system together. E invents a restriction; usage reporting is not tied to streaming.

Answer: A and B

Problem 4. An extraction pipeline feeds Claude output straight into a downstream service. The prompt asks for JSON. Roughly one response in fifty arrives with a conversational preamble before the JSON, and the parser throws. The team proposes adding "Respond with ONLY valid JSON. This is critical." to the prompt. Assess.

A. Correct — emphatic instructions reliably eliminate preambles B. Insufficient — use a constrained output format or a strict tool schema so the response shape is guaranteed rather than requested C. Correct — add three few-shot examples of bare JSON as well D. Insufficient — switch to the frontier tier, which follows formatting instructions more reliably

Approach: This is the three-layer guardrail rule applied to output shape. Instructions are the probabilistic layer; a one-in-fifty failure rate is exactly what "high compliance, never guaranteed" looks like in production. When code consumes the output, move the requirement to the schema layer where valid shape is guaranteed.

Why the others fail: A restates the failing approach with more capital letters. C lowers the rate — examples are genuinely good at locking format — but leaves the pipeline dependent on a probabilistic guarantee for a machine-parsed contract. D spends money to move the failure rate, not to eliminate it.

Answer: B

Problem 5. An internal assistant answers questions over a knowledge base of about 40,000 documents that is updated daily, and answers must cite their sources. An engineer proposes loading the whole corpus into the model's context window on every request because the window is large. What is the architect's response?

A. Approve — a large window removes the need for a retrieval pipeline B. Reject in favor of retrieval — the corpus exceeds any practical window, changes daily, and citation requires knowing which passages were used C. Approve, but cache the corpus so subsequent requests are cheap D. Reject and instead summarize all 40,000 documents into a single condensed context block

Approach: All three retrieval triggers fire at once: corpus size beyond the window, high change rate, and an attribution requirement. Retrieval gives you the selected passages, which is what makes a citation possible in the first place.

Why the others fail: A confuses window capacity with fit. C is doubly wrong: it does not fit, and a daily-changing prefix would invalidate the cache every day anyway. D destroys the specificity the answers and citations depend on, and re-summarizing daily is its own pipeline with worse fidelity than retrieval.

Answer: B

Problem 6. A platform team runs six internal agents that all need the same 30-page incident-response procedure, but only occasionally — perhaps one conversation in ten actually touches it. Today the procedure is pasted into all six system prompts. What is the better design?

A. Leave it — the system prompt is the right place for durable instructions B. Package the procedure as a Skill so a short description stays resident and the full content loads only when the task calls for it C. Convert the procedure into few-shot examples D. Move the procedure into a tool that returns it when called

Approach: The cost shape decides this. Resident-in-every-system-prompt means paying for 30 pages on ten times as many requests as need it, in six places, while diluting attention on the actual task. Progressive disclosure is exactly the mechanism for a large, occasionally-relevant procedure shared across agents.

Why the others fail: A is the status quo being questioned; durability is not the issue, resident cost and attention dilution are. C misapplies few-shot, which demonstrates output format rather than carrying a procedure. D is closer but conflates categories — a tool performs an action; know-how the model reads is what a Skill is for, and routing it through a tool call adds a round trip for content that is not an action.

Answer: B

Exam traps

• Frontier tier by default. The rule is the cheapest tier that clears your accuracy bar on your own eval. Watch for options that evaluate and route rather than upgrade everything.
• One model for a heterogeneous system. "Select appropriate models" is plural; routing by task with an escalation ladder is usually the senior answer.
• Changing tier when the reasoning dial was the lever. Raise effort before upgrading; lower effort before downgrading. And treat a fixed thinking-token budget as legacy configuration rather than current design.
• Downgrading to cut cost without re-running evals. A cost win of unknown accuracy cost is not an optimization.
• Strengthening a prompt instruction to guarantee anything. Prompt is probabilistic, schema guarantees shape, code guarantees behavior. Money, legal, safety, and irreversibility never rest on prompt text.
• Treating retrieved or user-supplied content as instructions. Delimit it, label its provenance, keep authority in the trusted channel, and enforce consequential actions outside the model.
• Chain-of-thought on lookups. Reasoning depth buys accuracy on multi-constraint problems and buys nothing but latency on extraction and classification.
• Few-shot examples that all look alike. Examples define the distribution the model generalizes from; include the awkward cases.
• Forgetting that caching is a prefix match. Render order is tools, then system, then messages, and one changed byte invalidates everything downstream. Any timestamp, request ID, unsorted serialization, per-user tool set, or mid-conversation model switch is a silent invalidator.
• Quoting one number for the minimum cacheable prefix. It is model-dependent and not monotonic across generations — a prompt that caches on one model can silently fail to cache on another, with no error.
• Ignoring cache break-even. Writes cost more than normal requests; roughly two reads pay back the short TTL and three the long one. Caching a prefix used once is a loss.
• Per-tenant fragments placed ahead of shared ones. Modular prompts must put the shared block first or there is nothing shared to cache.
• Confusing a large context window with a retrieval strategy. Corpus larger than the window, changing frequently, or citations required means retrieval — every time.
• Estimating tokens with a non-Claude tokenizer, or reusing counts across model generations. Measure with the provider's counting endpoint against the model you will actually deploy.