Prompt and Context Engineering

11% of the Claude Certified Developer – Foundations blueprint — roughly 6 of the 53 questions on a real sitting.

Prompt and Context Engineering is 11.0% of the CCDV-F blueprint — roughly 6 of the 53 scored questions. It splits into Prompt Engineering (4.6%), Context Engineering (3.8%) and Output Handling (2.6%), and the exam treats those as three genuinely different skills rather than three names for writing good prompts.

Prompt engineering is the craft of the instruction itself: clarity, motivation, examples, structure, role. Context engineering is a step up the stack — Anthropic's engineering writing defines it as curating and maintaining the optimal set of tokens available during inference, and calls it the natural progression of prompt engineering. The distinction matters because the failure modes differ: a bad prompt gives a wrong answer, while bad context management gives an answer that degrades as a session grows, which is a far harder bug to see. Output handling is the third leg — constraining the response into a shape your code can consume, and handling the cases where the constraint does not hold.

This is also where experienced practitioners carry the most stale knowledge. Prefilling the assistant turn to force a JSON shape, spelling out step-by-step reasoning instructions, layering emphatic 'you MUST' language — all were standard advice, and all have since been superseded by API features or now backfire on models that follow instructions more literally.

What the exam actually tests

  • —Clear, direct instructions with context and motivation — and why emphatic phrasing now overtriggers
  • —Structuring prompts with XML tags, and where long documents belong relative to the query
  • —Context engineering as token curation: attention budget, context rot, and what to do about them
  • —Constraining responses with structured outputs (`output_config.format`) and strict tool schemas
  • —That last-turn assistant prefill returns a 400 on current models, and what replaced each of its uses
  • —Handling the cases where a constrained output still does not arrive — truncation and refusal

What 'clear and direct' actually means

The baseline technique is to describe the task the way you would brief a capable new colleague who has no context on your organisation: what the output is for, who reads it, what a good result looks like, and any constraint that is not obvious from the request. Giving the *reason* behind an instruction generalises better than the instruction alone, because it tells the model how to handle the cases you did not enumerate. Examples are the strongest single signal in a prompt — the model matches their length, tone and structure — so use several deliberately varied ones rather than a single gold output you did not intend to be copied exactly. XML tags separate the parts of a prompt cleanly, and a system prompt is the right place for role and standing behaviour, with the request itself in the user turn.

Laying out a long-context prompt

Once inputs get large — the documented threshold is around 20,000 tokens — layout starts to matter as much as wording. Anthropic's guidance is explicit: place long documents and data near the *top* of the prompt, above your query, instructions and examples. Queries placed at the end have been measured to improve response quality by up to 30 percent in their tests, most noticeably on complex multi-document inputs. Wrap each document in `<document>` tags with `<source>` and `<document_content>` subtags so metadata and body are unambiguous. For long-document tasks, asking the model to quote the relevant passages before it reasons over them grounds the answer and makes it far easier to audit. This layout also happens to be cache-friendly, since the stable bulk sits ahead of the varying question.

Context engineering is curation, not compression

Context engineering asks a different question from prompt engineering: not 'what should I say' but 'what should be present at all'. The motivating fact is that a model spends a finite attention budget across the window, and recall degrades as token count grows — the effect Anthropic's engineering writing names *context rot*. The remedies are structural. Just-in-time retrieval keeps lightweight identifiers such as file paths or queries in context and loads content only when needed. Compaction summarises a long history and continues from the summary. Structured note-taking persists findings outside the window. Sub-agent delegation moves reading-heavy work into a separate clean window that returns only its conclusion. Each addresses a different symptom, and the exam expects you to match the symptom to the remedy.

Output handling: constrain, then verify

Where downstream code consumes the response, ask for a shape rather than hoping for one. Structured outputs constrain the response format through `output_config.format` with a JSON schema — note that the older top-level `output_format` parameter is deprecated in favour of it. For tool arguments the equivalent is `strict: true` on the tool definition, which requires `additionalProperties: false` and an explicit `required` list and guarantees the arguments validate. Both have edges worth knowing: the schema dialect is a subset, so recursive schemas and numeric or string range constraints are not supported; a first request with a new schema pays a one-off compilation cost; and structured outputs cannot be combined with citations. Two situations still yield output that does not match your schema — a safety refusal and a `max_tokens` truncation — so branch on `stop_reason` before parsing.

Prefill is gone; know its five replacements

Ending the messages array with an assistant turn to steer the start of a response was a workhorse technique and is now a hard failure: on current models it returns a 400 stating that the model does not support assistant message prefill and that the conversation must end with a user message. Assistant messages *elsewhere* in the conversation, such as few-shot exchanges, are unaffected. Each of prefill's uses has a documented successor: forcing an output format is now structured outputs; suppressing preambles is a system-prompt instruction to answer directly; steering around an unwanted refusal is ordinary user-turn prompting; continuing a truncated response moves into the user turn; and injecting context mid-conversation goes in the user turn, a tool result, or a supported mid-conversation system message.

Where candidates go wrong

Trap 1 — 'Ask the question first, then attach the document'

It reads naturally and it is the wrong order for long inputs. The documented layout puts long documents and data at the top of the prompt, above the query, instructions and examples — placing the query at the end is what produces the measured quality gain. The same trap has a structural half: an option that pastes several documents in as one undifferentiated block loses to the one that wraps each in `<document>` tags with a `<source>` and a `<document_content>`, because the model can no longer tell where one source ends and the next begins.

Trap 2 — 'Prefill the assistant turn so the reply starts with a brace'

This is the highest-value stale technique in the domain, because it does not degrade gracefully — it returns a 400 on current models. Any option that ends the messages array with a partial assistant message to force a format, skip a preamble, or continue a cut-off answer is wrong. The correct answers are structured outputs for shape, a system-prompt instruction for preambles, and a user-turn instruction for continuation. Note the exception that examiners like: assistant turns in the middle of a conversation, such as few-shot examples, remain perfectly valid.

Trap 3 — 'Structured outputs guarantee I can always parse the response'

Constraining the format removes the common failure, not every failure. A safety refusal produces a successful response whose content may be empty or partial and need not match your schema, and a response truncated by `max_tokens` produces incomplete JSON. Code that pipes the body straight into a parser without first checking `stop_reason` will crash on exactly those cases. The exam-correct answer constrains the output *and* keeps a validation and error path — and if a question mentions citations, remember that structured outputs are incompatible with them.

Trap 4 — 'It got that wrong, so add another rule to the prompt'

Prompts grow by accretion: each incident adds a line, until the model navigates a maze of special cases instead of a coherent brief. Two symptoms show up as distractors. Emphatic escalation — CRITICAL, you MUST, always — was needed on older, less steerable models and now causes overtriggering. And bulk itself costs, because everything in the window draws on the same attention budget. The stronger fix is to state the principle and its reason once, or move the constraint out of prose into a schema, a tool contract, or code.

How to study this domain

Weight your time toward prompt engineering (4.6%) and context engineering (3.8%), with a lighter pass on output handling (2.6%) — though output handling has the highest density of exact, checkable facts, so it is the best value per minute.

To internalise the layout rules, build one long-context prompt properly: three documents wrapped in `<document>` tags with sources, placed above the query, with an instruction to quote relevant passages first. Then move the query to the top and compare. Feeling that difference makes the ordering question automatic.

For output handling, write down prefill's five old jobs and their replacements — format, preamble suppression, refusal steering, continuation, context injection. That mapping is directly answerable and it is where stale expertise costs marks. Then constrain one real response with a JSON schema and truncate it with a tiny `max_tokens`, so you see that constrained output is not unconditional output.

Finally, audit a prompt you already own: delete every emphatic marker, every restatement of a trained default, and every rule whose original incident nobody remembers. What survives is what the exam considers good prompting.

Common questions

How many CCDV-F questions come from Prompt and Context Engineering?

It is 11.0% of the blueprint — roughly 6 of the 53 scored questions. The sub-skills are Prompt Engineering (4.6%), Context Engineering (3.8%) and Output Handling (2.6%).

What is the difference between prompt engineering and context engineering?

Prompt engineering is how you write and organise instructions. Context engineering is the broader discipline of curating which tokens are present during inference at all — retrieval, compaction, note-taking and delegation. Anthropic's engineering writing describes context engineering as the natural progression of prompt engineering, and the two have different failure modes.

Where should long documents go in a prompt?

At the top, above the query, instructions and examples, with each document wrapped in `<document>` tags carrying `<source>` and `<document_content>` subtags. The guidance applies from around 20,000 tokens of input, and queries placed at the end have been measured to improve quality by up to 30 percent on complex multi-document inputs.

Can I still prefill Claude's response?

Not on the last assistant turn of current models — it returns a 400 saying the conversation must end with a user message. Assistant messages elsewhere in the conversation, such as few-shot examples, still work. Use structured outputs for format control, and system- or user-turn instructions for the other things prefill used to do.

Do structured outputs remove the need for validation?

No. They remove the common failure — a response that is nearly but not quite the shape you wanted — while leaving two cases where the constraint does not apply: a safety refusal, and a response truncated by `max_tokens`. Check `stop_reason` before parsing, and keep an error path.

Is 'think step by step' still worth putting in a prompt?

Rarely, on models with adaptive thinking. Reasoning depth is configured rather than requested — through the thinking parameter and effort level — so the incantation is at best redundant. Prompting is still the right lever for *when* to think, but not for making the model reason at all.

Practise this domain

The CCDV-F bank is weighted to the blueprint above, so 11% of what you practise is this domain — and every option carries a written explanation, not just the correct one.

See CCDV-F

Other CCDV-F 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.