Prompt engineering & structured output on CCAR-F: the Domain 4 lesson

Prompt engineering & structured output on CCAR-F is Domain 4 of the Claude Certified Architect Foundations blueprint, weighted at 20 percent, about 12 of the 60 items. Its six task statements are explicit criteria, few-shot prompting, structured output through tool use and JSON schemas, validation and retry loops, batch processing, and multi-pass review. Two of six published scenarios name it as primary: CI code review and structured data extraction. Every item turns on one move: name the failure, then pick the mechanism that fixes it at the layer where it lives.

What prompt engineering & structured output on CCAR-F covers

The official CCAR-F exam guide (version 1.0, effective July 2026) lists six task statements, each with a knowledge block and a skills block. The right-hand column is the Cred Farmer reading of what each one decides, the question to answer before you look at any option. Checked against the official sources on 17 September 2026.

Notice how little of the middle column is prompting: two statements, against one schema and three about the code around the call. Of the four tracks where prompt engineering is examined, this is the one where the subject is widest, and where it is most often the wrong answer.

Six objectives, two scenario families

Section 5 of the guide names Domain 4 as primary in two of its six scenarios: Claude Code for Continuous Integration, which wants actionable review feedback with few false positives, and Structured Data Extraction, which validates against JSON schemas and must not fabricate. Lay the task statements over those two and they sort themselves. The weight stays near 20 percent whichever four scenarios your form draws; all six are mapped in the CCAR-F exam scenarios post.

Three layers, three different guarantees

Hold the domain as a stack: prompt, schema, code. Each layer guarantees something the one above cannot.

The prompt layer is 4.1 and 4.2, with Anthropic's pages on being clear and direct and multishot prompting as the reference. The guide's contrast is precise: telling the model to be conservative does not improve precision; a rule about which issue types to report does. The schema layer is 4.3: tool use with a JSON schema, per the tool use overview and structured outputs, removes syntax errors and knows nothing about whether the numbers are right. The code layer, 4.4 to 4.6, checks truth, tells a retry what went wrong, correlates a batch by custom_id, and reviews with a second instance that never saw the first one's reasoning.

Few-shot prompting on CCAR-F: the key once, the distractor twice

Section 9 of the guide publishes twelve sample items, and few-shot examples appear as an option in three. They are the key where an agent escalated easy cases and handled hard ones alone: the failure was an unclear decision boundary, and examples draw one. They are a distractor where an agent skipped a mandatory identity check, because a sequence that must never be violated needs a programmatic prerequisite. And they are a distractor where an agent chose the wrong tool, because the descriptions were minimal and the first fix is the description. That option also proposed five to eight examples; the skill statement under 4.2 says two to four. Examples here are a scalpel, and a pile of them is usually demonstrating its way past a defect in a description, a schema or a hook.

Shape from the schema, truth from the code

Task 4.3 names three tool_choice modes: auto, which may answer in prose; any, which forces some tool call and fits several extraction schemas with an unknown document type; and a named tool, which forces one specific extraction. Its other half is field design: nullable fields for information a source may not contain, so the model returns null rather than an invention, and enums with an unclear option and an other-plus-detail pattern. Task 4.4 draws the line the exam most likes to test: a retry that appends the validation error can repair a format mistake and cannot repair an absence. Where that line runs into batch handling and independent review is what a retry knows on CCAR-F; which papers name a JSON schema at all (one objective in the programme) is JSON schemas on the Claude exams; the round trip itself is Claude tool use and structured output.

A worked item

How to prepare for it

Classify the failure before the options, then check the layer. Take a free timed CCAR-F mock exam with the Domain 4 filter on and write the failure type beside every item; where the miss log repeats a word, reread that task statement. A practice percentage is practice evidence; it does not predict the 720 scaled cut. The practice exams guide covers what official material exists, and which Claude certification to sit owns the choice between the architect papers: the counterpart domain on CCAR-P names zero-shot, few-shot and chain-of-thought inside 13 percent and never mentions a schema. If Domain 4 is your weakest CCAR-F domain, the Claude certification study guide sets out the repair loop, and the Message Batches documentation is the primary source for the figures most often misremembered.

Key takeaways

• Domain 4 is 20 percent of CCAR-F, about 12 of 60 items. Tied second-largest behind the 27 percent agentic domain.
• Two of six task statements are prompting. One is a schema; three are code around the call.
• Two scenarios name it primary. CI review fails by saying too much; extraction by saying the wrong thing.
• Few-shot is the key once and the distractor twice in the guide's sample items. Examples draw a boundary; they cannot enforce an ordering.
• A schema guarantees shape, never truth. Arithmetic and absence are checked in code, and a retry only helps when the source held the answer.