Prompt Engineering & Structured Output accounts for 20% of the CCA-F exam. Questions in this domain test your ability to write prompts that reliably elicit the output format your application needs, to use Claude's tool use mechanism as a schema enforcement layer, and to design retry loops that recover gracefully from validation failures. This domain bridges the gap between research-style prompt tweaking and production-grade prompt engineering.
Structured output questions centre on JSON schema enforcement. When an application needs Claude to return a JSON object with specific fields and types, the correct approach is to define the schema as a tool and call that tool every time — not to instruct the model to 'respond in JSON.' The tool use mechanism enforces the schema at the API level, so the model physically cannot return a response that violates the schema. The exam will present scenarios where a developer used a natural-language instruction to enforce structure and ask why it fails intermittently.
Few-shot design is the practice of including example input-output pairs in the prompt to demonstrate the expected behaviour. Good few-shot examples share the same format as the target task, cover edge cases that the instruction alone might not make clear, and are placed close to the instruction rather than buried in a long system prompt. The exam will ask you to compare few-shot configurations and identify which one is most likely to produce consistent results on out-of-distribution inputs.
Output format selection is a recurring question type: given a downstream consumer (a database write, a human reader, a code parser, another model), which output format should you request? JSON is best for machine consumption when the schema is known in advance. Markdown is best for human-facing text. Plain text is best when the downstream parser is brittle. XML is occasionally preferred when the consumer is an existing XML pipeline. The exam will present a downstream consumer and ask you to select the appropriate format.
Validation retry loops are the production pattern for handling outputs that do not conform to the expected schema. When the model's output fails validation, you feed the validation error back into the conversation as a user turn and ask the model to fix it. The exam tests the correct structure of this retry loop: the validation error must be specific and actionable (not just 'invalid JSON') and the retry prompt must reference the original instruction so the model does not drift from the task.
Scenario: A developer is building a document classification API. The API accepts a document and must return a JSON object with three fields: category (a string from an enum of 12 values), confidence (a float between 0 and 1), and reasoning (a short string). The developer instructs Claude to 'respond with a JSON object containing category, confidence, and reasoning.' In production, roughly 3% of responses either include extra commentary text before the JSON, use a category value not in the enum, or omit the confidence field entirely.
The correct fix is to define the expected output as a tool — with category as an enum string, confidence as a number with minimum 0 and maximum 1, and reasoning as a string — and to call that tool on every request. Claude's tool use mechanism enforces the schema at the API level, eliminating the 3% failure rate. The distractor answers — lowering the temperature, adding 'do not include any text outside the JSON' to the instruction, and adding a few-shot example of the correct format — are all partial mitigations that reduce the failure rate but do not eliminate it. Only tool use provides a hard guarantee.