CCDV-F · module 4 of 8 · 11% of the exam

Prompt and context engineering

Weight: 11 percent of the exam. Tests whether you can structure a prompt so the model reliably does the right thing, and manage what occupies the context window as a conversation or agent run grows.

What the exam expects

This domain is about two related crafts. Prompt engineering is how you arrange instructions, examples, and inputs inside a single request. Context engineering is how you decide what belongs in the context window at all, and what happens to it over a long-running session.

Questions here are rarely "what is a system prompt". They are far more often: a team has a working integration, something is degrading (quality, cost, cache hit rate, coherence over long runs), and you have to name the structural cause and the correct fix. The tempting wrong answers are usually a prose instruction where a structural mechanism belongs, or a knob (effort, max_tokens, model tier) where a layout change belongs.

You are expected to know that several older techniques have been removed or superseded. Assistant prefill is rejected with a 400 on current models. Fixed thinking budgets are gone. Prompted chain of thought is a fallback rather than the default. Getting these wrong is the fastest way to lose points in this domain.

Prompt anatomy: what goes where

The request has three regions and they render in a fixed order: tools, then system, then messages. That order matters for both comprehension and caching.

The last row is the one developers most often get wrong. When an application needs to change behaviour partway through a session (a mode switch, freshly fetched state, a revised constraint), the instinct is to rewrite the top-level system prompt. That changes bytes ahead of the entire conversation, so every cached turn is reprocessed. Appending a {"role": "system", ...} message to messages puts the instruction after the cached history instead. It is available on Claude Opus 5, Opus 4.8, Fable 5, and Mythos 5, and it requires no beta header.

Structuring with XML and examples

XML tags are the standard way to keep the parts of a prompt from bleeding into each other. Wrap instructions, context, examples, and input in their own tags, and nest when there is a natural hierarchy. For multiple documents, the conventional shape is a documents element containing numbered document elements, each with source and document_content subtags. That structure is what lets the model keep sources distinct and attribute a claim to one of them.

Few-shot examples are the highest-leverage steering tool you have, but their value comes from coverage, not count. Three examples spanning the categories and including one genuinely ambiguous case outperform fifteen near-identical ones. If the model is failing on a category, the diagnostic question is almost always "is that category demonstrated?" rather than "should I add more examples?" The same applies to edge cases: if every example shows a fully populated record, the model will infer that fields are always populated and invent values for blanks.

Reasoning: thinking, effort, and what replaced prefill

On current models, reasoning depth is configured, not prompted.

• Set thinking to {"type": "adaptive"} and let the model decide when and how much to think.
• Control spend with output_config.effort, which accepts low, medium, high, xhigh, and max.
• Fixed budget_tokens is removed on the Claude 5 family and returns a 400.
• Thinking output defaults to display: "omitted", which streams thinking blocks whose text is empty. If your product shows reasoning to users, set display: "summarized" explicitly. The raw chain of thought is never returned on any current model.

"Think step by step" in a prompt is now a fallback for when thinking is disabled, not a default technique. If you do use it, separate reasoning from the answer with tags such as thinking and answer.

Assistant prefill deserves its own note because so many older integrations depend on it. Ending the messages array with an assistant turn to force JSON, force a label, or skip a preamble now returns a 400. The replacements, by intent:

Assistant messages elsewhere in the conversation, such as few-shot demonstrations, are still perfectly legal. It is specifically the final assistant turn that is rejected.

Caching as a design constraint

Prompt caching is a strict prefix match. Any byte that changes anywhere in the prefix invalidates everything after it. Almost every caching problem reduces to that one sentence.

Practical consequences worth memorizing:

• A timestamp, UUID, session id, or user name near the top of the system prompt invalidates the whole prefix on every request.
• Non-deterministic serialization counts as a change. Iterating a set, or serializing tool definitions without sorting keys, produces different bytes each time. Tools render first, so this poisons everything.
• Caches are scoped per model. Alternating models, or spawning a fork on a cheaper tier, cannot read the parent's entry.
• A prefix shorter than the model's minimum silently fails to cache. There is no error, just cache_creation_input_tokens: 0.
• You get at most four breakpoints per request.

Verify with usage.cache_read_input_tokens. A persistent zero across identical-prefix requests means something is invalidating; do not infer success from latency. Note that input_tokens reports only the uncached remainder, so a small value there alongside a large cache read is exactly what a working setup looks like.

For agent forks (a summarization side-call, a sub-agent), copy the parent's system, tools, and model verbatim and append only the fork-specific instruction. Trimming the tool list to "save tokens" changes the front of the prefix and guarantees a full miss.

Managing a growing context window

Three mechanisms, three different jobs. The exam likes to test whether you can tell them apart.

Editing prunes; compaction summarizes. The single most common compaction bug is a loop that extracts only the text from a response and appends that as the assistant turn. Compaction returns a block inside response.content that the API needs on the next request to stand in for the compacted history. Append the full response.content, not an extracted string, or the conversation silently loses its history.

How to think through the question

Prompt and context questions almost always describe a symptom and ask for a cause or a fix. Work the scenario in this order.

1. Name the symptom precisely. Cache reads are zero. Output is too long. The model blends sources. History was lost after compaction. Answers degrade only on long inputs. The symptom usually maps to exactly one mechanism.
2. Ask what layer the problem lives in. Layout (where content sits), mechanism (a feature you should be using), or behaviour (prompt wording). A caching miss is layout. Lost history after compaction is mechanism. Excessive verbosity is behaviour.
3. Eliminate any option that answers a different layer than the symptom. This kills most distractors. Raising effort does not fix a caching miss. Lowering max_tokens does not shorten a rambling answer, it truncates one.
4. Eliminate prose where a structure is available. If the requirement is a guarantee (schema, label set, contract with a downstream system), a system prompt instruction is never the best answer.
5. Check for removed features. If an option relies on prefill, budget_tokens, or temperature, it is wrong on current models regardless of how sensible it sounds.

Worked example. A team migrates a summarizer and finds quality is fine on short documents but noticeably worse on 90,000 token ones. The template puts the instructions and output format first, then the document, then a closing format reminder. What change helps most?

Step 1: the symptom is scoped to long inputs only, which rules out anything wrong with the instructions in general. Step 2: nothing here is broken behaviourally and no feature is missing, so this is a layout problem. Step 3: raising max_tokens addresses output capacity, and the complaint is about comprehension, so it goes. Step 4: no guarantee is being asked for, so schema options are irrelevant. Step 5: nothing removed is in play. What remains is the documented long-context rule: put longform data at the top, above the query, instructions, and examples. Chunking the document is a heavier architectural change that also destroys cross-document coherence, and it is unnecessary at a 1M token context window. Move the document to the top.

Exam traps

• Reaching for a knob when the fix is layout. Effort, max_tokens, and model tier are tempting because they are single-line changes. If the symptom is a cache miss, source blending, or degradation only on long inputs, the answer is where content sits.
• Believing effort controls response length. On Claude Opus 5 it does not reliably shorten user-facing output. An explicit conciseness instruction does.
• Porting aggressive prompts unchanged. Lines like "CRITICAL: You MUST call this tool" and "double-check your answer" were written to overcome older models' reluctance. Current models follow them literally, producing over-triggering and over-verification. The fix is usually to delete, not to rewrite.
• Assuming more examples beats better examples. Adding volume to a biased example set deepens the bias.
• Trusting prose for a hard contract. "Reply with only one of these five words" is a strong nudge. An enum in a schema is a guarantee.
• Appending only the text after compaction. The compaction block is load-bearing state, and dropping it looks exactly like amnesia.
• Forgetting that tools render first. Teams freeze the system prompt, place the breakpoint correctly, and then rebuild the tool array non-deterministically on every request.
• Assuming an empty thinking block means the model did not think. Thinking happens and is billed under every display setting; omitted is just the default visibility.

Quick reference

• Render order: tools, system, messages. Stable first, volatile last.
• Caching is a prefix match; verify with usage.cache_read_input_tokens; max four breakpoints; caches are per model.
• Long documents go at the top, above the query. Wrap multiple documents in document tags with source and document_content. Ask for quotes first to ground answers.
• Adaptive thinking plus output_config.effort replaces prompted chain of thought and budget_tokens.
• thinking.display defaults to omitted; set summarized to surface reasoning.
• Last-turn assistant prefill returns a 400; use output_config.format, an enum, or a direct instruction.
• Context editing clears; compaction summarizes and returns a block you must pass back.
• Mid-session operator instructions go in a system role message inside messages, not in the top-level system field.