Prompt Engineering

Prompt Engineering is 20% of the CCA-F blueprint — roughly 12 of the 60 official-simulation questions come from this domain. It is the second-largest scoring area after Agentic Architecture, and the one where candidates most often confuse 'good general prompt advice' with the specific, production-grade patterns the exam rewards.

The questions in this domain are not about cleverness, persona tricks, or 'jailbreak' tactics. They are about predictable decisions a working Claude architect makes every day: do I include three actual examples or a one-paragraph description of the style? Do I put the schema in the system prompt or in tool_use? Should this field be required, or nullable? Do I tell Claude to 'think carefully', or do I use extended thinking? Should the rule live in the system prompt where it persists, or in the user turn where it can be ignored?

The exam consistently rewards answers that match documented Claude behaviour: XML tags for unambiguous parsing, few-shot examples for format and style, tool_use with a strict JSON schema for structured output, nullable fields to prevent fabrication on missing data, and extended thinking when a task genuinely needs deeper reasoning. It consistently punishes answers that sound smart but rely on vague instructions, summarised style, or out-of-scope techniques like fine-tuning.

What the exam tests in this domain

• ·Few-shot examples vs. summarised style — when concrete examples are required
• ·Extended thinking and chain-of-thought — when to enable, when not to
• ·XML tags for unambiguous prompt structure and reliable parsing
• ·Structured output via tool_use with a strict JSON schema
• ·Nullable schema fields to prevent hallucination on optional data
• ·System prompt vs. user prompt placement for rules, persona, and per-task input

Key concepts

Common traps and distractor patterns

Sample questions with explanations

1. Question 1

   When using tool_use to extract structured data from documents, which JSON schema design best prevents Claude from hallucinating values for fields that may not be present in the source?

   • A.Use nullable fields (type: ['string', 'null']) for optional data and set required only for fields that must always be present✓ Correct
   • B.Use anyOf schemas with multiple type options for every field
   • C.Add a 'confidence' field next to each extracted value
   • D.Make all fields required with strict types
   Why A is correct: Nullable fields (type: ['string', 'null']) allow Claude to return null when a value is not present in the document, rather than fabricating a plausible-sounding value. This is the primary technique for preventing hallucination in structured extraction. Making all fields required forces Claude to fill them even when data is absent. The anyOf and confidence approaches add complexity without addressing the core issue of optional data.

2. Question 2

   You need Claude to review code in the same style as your senior engineers. You have 3 examples of excellent code reviews from your team. How should these be incorporated?

   • A.Include them in the system prompt as few-shot examples showing the exact format and tone expected✓ Correct
   • B.Summarize the review style in the prompt without including the actual examples
   • C.Reference them in a CLAUDE.md file and let Claude read them when needed
   • D.Fine-tune Claude on these examples for consistent behavior
   Why A is correct: Few-shot examples in the system prompt directly shape Claude's output format and style for the current task. Including 3 concrete examples of excellent reviews trains Claude on the exact level of detail, tone, and structure expected. Referencing examples in CLAUDE.md without including them in the prompt context is less reliable. Summarizing style loses the concrete patterns. Fine-tuning is out of scope for the CCA-F certification (explicitly listed as out-of-scope in the exam guide).

3. Question 3

   What is prompt engineering?

   • A.The hardware optimization process for running AI models faster
   • B.The practice of designing, refining, and optimizing the inputs (prompts) given to language models to achieve desired outputs✓ Correct
   • C.Writing code to build AI models
   • D.A programming language for AI development
   Why B is correct: Prompt engineering is the practice of designing, refining, and optimizing the inputs (prompts) given to language models to achieve desired outputs. It involves crafting clear instructions, providing appropriate context, and structuring prompts to guide the model toward producing accurate, relevant, and useful responses.

How to study this domain

For each Prompt Engineering question, force yourself to name the mechanism each option relies on before you pick. 'Include three examples' relies on few-shot conditioning. 'Use tool_use with a schema' relies on validated structured output. 'Mark the field nullable' relies on giving Claude a legitimate 'not present' value. 'Enable extended thinking' relies on budgeted reasoning tokens. If you can name the mechanism, the correct answer usually becomes obvious; if you can't, you are guessing.

Memorise four contrasts: few-shot examples vs. summarised style; extended thinking vs. 'think carefully'; tool_use with schema vs. prose 'reply in JSON'; nullable fields vs. all-required. These four contrasts cover the majority of distractor pairs in this domain. Also internalise that fine-tuning is out of scope — any option that proposes it at Foundations level is wrong by definition. Drill 25–30 practice questions in this domain and articulate, for every wrong option, the specific failure mode it would cause in production.

Frequently asked questions

How many questions on the CCA-F exam are from Prompt Engineering?

Prompt Engineering is 20% of the blueprint. On the 60-question Official Simulation that maps to roughly 12 questions — the second-largest domain after Agentic Architecture.

When should I use few-shot examples vs. just describing the style?

Whenever you have concrete examples of the output you want, include them as few-shot examples in the system prompt. Description loses the specific patterns — cadence, length, where to soften vs. mandate — that examples carry. The exam treats 'summarise the style' as a distractor when 'include the actual examples' is available.

Is fine-tuning ever the right answer on the CCA-F exam?

No. Fine-tuning is explicitly out of scope for Foundations. If a question can be solved with few-shot examples, system-prompt rules, tool_use schemas, or extended thinking, those are the intended answers. Treat any option proposing fine-tuning as a distractor at this level.

How do I stop Claude hallucinating values during structured extraction?

Use tool_use with a strict JSON schema and mark optional fields as nullable (type: ['string', 'null']). Reserve required for fields that must always be present. Forcing all fields to be required is the single biggest cause of fabricated values — Claude has to satisfy the schema, so it makes something up.

When should I enable extended thinking instead of just asking Claude to reason step by step?

Enable extended thinking for genuinely hard, multi-step, or analytical tasks — debugging, planning, complex synthesis. Asking the model to 'think carefully' is vague prompting; extended thinking is the structured feature with a real reasoning-token budget. The exam consistently prefers the structured feature when the task warrants deeper reasoning.

Where should rules live — system prompt or user prompt?

Rules that must hold across every turn (persona, policy, output format, refusal behaviour) belong in the system prompt. Per-task content — the document, the question, the live input — belongs in the user turn. Mixing them, especially putting durable rules in the user turn, is a frequent exam trap.