CCAR-P prompting and context engineering, domain 2

13% of the exam — about 8 of the 63 questions — across 5 sub-objectives.

Domain 2 is smaller than it feels while studying, because prompting is the part of the syllabus with the most material written about it elsewhere. The exam is narrower than that literature. It asks what belongs in a prompt at all, what belongs somewhere the model cannot ignore, and what a context window costs you when it fills.

Four terms get conflated constantly, and several questions turn on keeping them apart. The context window is the model's active attention space. Retrieval fetches external knowledge into that space at query time. Persistent application state, such as an order status or an account balance, is owned by your system and reaches the model only through a tool call. Memory across turns exists because

your application stored something, since the model has none between calls. Mixing these up produces confident, wrong architectures.

Three of these five turned up on my form: system prompts and guardrails, prompt technique, and reuse. Model selection and context-window sizing did not appear at all, which is worth knowing if you are budgeting study time by how much has been written about a topic rather than by how much of it is tested.

Select appropriate Claude models based on trade-offs

Model questions are cost, latency, and capability questions wearing a product name. Opus, Sonnet, and Haiku sit at different points on those three axes, and Sonnet is the sensible default that you move away from deliberately.

The exam rewards a specific discipline: move up only when a quality bar is demonstrably not met, and move down when the task is narrow, high-volume, and latency-sensitive. Scenarios hand you the deciding evidence in the numbers. A tight per-request latency budget, a volume figure in the tens of thousands, and a stable well-documented task all point down the family. Ambiguous reasoning over long documents with a low tolerance for error points up.

The common wrong answer reaches for the most capable model because the domain sounds important. Legal, medical, and financial scenarios invite this, and the credited answer is often a smaller model on a narrow task with a human check on the output. Importance of the domain is not the same as difficulty of the task.

Fine-tuning deserves a note because it appears as a distractor more often than as an answer. Try prompting first. A well-constructed prompt with good examples closes most gaps, and fine-tuning adds a training and maintenance burden that scenarios rarely justify.

Design system prompts, templates, and guardrails

The design question is not how to word an instruction. It is which instructions belong in a prompt at all.

A system prompt shapes behavior. It does not enforce it. Anything that must hold every single time belongs somewhere deterministic: validation inside the tool, a hook that fires on an event, a check in your code after the model returns. When a scenario describes a constraint that cannot ever be violated, such as a refund never exceeding the original transaction, the credited answer moves the constraint out of the prompt and into the boundary where the action happens.

Templates matter for a reason the exam tests directly. A stable prefix is cacheable, and a prompt assembled in a different order each call is not. Put the fixed material first and the variable material last.

The other recurring point is where the user's identity comes from. The server injects the role and what data that role may see, before the call. A role the user asserts in their own message is a role the user can change, and options that accept it are wrong regardless of how much validation surrounds them.

Apply prompt engineering techniques (zero-shot, few-shot, chain-of-thought)

These questions are about matching technique to failure, so read the failure first.

Output that is right in substance but inconsistent in shape wants few-shot examples, because examples teach form better than description does. Reasoning that skips steps and arrives somewhere wrong wants chain-of-thought, which buys accuracy with tokens and latency. A task the model already performs reliably wants zero-shot, and adding examples to it spends context for nothing.

The trap is treating chain-of-thought as a general quality upgrade. On a high-volume classification task with a latency budget, asking the model to reason step by step makes every call slower and more expensive to fix a problem the scenario never described. Techniques have costs, and the exam prices them.

Structured output is worth its own note. When downstream code parses the result, constrain the shape rather than asking politely for JSON in the prose. A parse failure at three in the morning is a design decision made earlier.

Optimize context windows and manage token usage

The context window has the hardest edge of any property you design around. Inside it the model can attend to everything. Outside it, the content does not exist to the model at all, and there is no partial credit.

The practical rule is that you do not budget the full window. Budget the largest realistic conversation, plus retrieved context, plus the system prompt, plus working room, plus margin for growth. Designs that fit exactly today fail on the first long document.

Questions in this area usually describe a system whose context grows without bound: a conversation that runs past forty turns, an agent loop accumulating tool results, a document set that got bigger. The credited answers separate what must stay exact from what only needs recalling. Recent turns stay verbatim, older ones compress to what was decided, and full detail stays retrievable for the rare question that needs it. Truncating the oldest content is the attractive wrong answer, because the oldest content is usually where the commitments live.

Cost follows tokens, so a cost question is a token question. When spend rises with flat traffic, split prompt tokens from completion tokens before doing anything else. Prompt tokens climbing points at grounding, and completion tokens climbing points at generation length.

Implement prompt reuse strategies (caching, modular prompts, Skills)

Caching rewards structure. A stable prefix that repeats across calls can be cached, which cuts both cost and time to first token, and the design consequence is that you order the prompt to make the front of it invariant. System instructions, tool definitions, and reference material go first. Anything that changes per request goes last.

Scenarios that mention a large fixed corpus consulted on every call, such as a policy manual or a style guide, are usually caching questions even when they do not use the word.

Skills package a repeatable procedure as a versioned unit, which matters when several teams need the same behavior and you would otherwise have the same instructions copied into four codebases drifting apart. The exam frames this as a maintenance question rather than a capability one. Ask where the behavior is defined and what happens when it needs to change.

Modular prompts follow the same logic. Assemble prompts from named pieces you can version and test, rather than long strings edited in place, so that a change is reviewable and a regression is attributable.