Prompt engineering techniques (few-shot, chain-of-thought, structured output): AIP-C01 study notes and practice questions
What to know about Prompt engineering techniques (few-shot, chain-of-thought, structured output) for the AIP-C01 exam, from the Foundation Model Integration, Data Management, and Compliance domain (31% of the exam guide), then 1 free question to test it. Part of the AIP-C01 study guide.
AIP-C01 asks which prompting technique fixes a given symptom, such as inconsistent format, weak reasoning or instructions mixed with user data, and how to improve a prompt from evidence.
Techniques and what they fix
Technique
Fixes
Notes
Few-shot examples
Inconsistent format or tone
Two to five examples that match the target output closely
Chain-of-thought or extended thinking
Multi-step reasoning errors
Extended thinking is offered only by some models, such as recent Claude models
XML or tagged sections
Mixing instructions with user data
Wrap user content in tags such as <document> and refer to them in the instructions
Structured output
Downstream parsers breaking
Specify a JSON schema or use a structured output option where the model supports it
Role prompting
Wrong voice or scope
Set the persona in the system prompt
Prefill
Forcing a starting format
Begin the assistant turn with text where the model allows it
Structured output
When another system reads the response, ask for a defined format and validate it. A JSON schema in the request reduces malformed output. Validation still belongs in code, for example a Lambda check that rejects bad output and retries with a repair instruction.
Improving a prompt
Change one thing at a time, then measure. Use the golden test set and the metrics from prompt testing. Feed failing examples back into the prompt as new few-shot cases or as clearer rules. A prompt that improves on one model may behave differently on another, so retest after any model change.
How to choose
Scenario wording
Choose
“Output format varies between answers”
Few-shot examples, then structured output
“Model makes arithmetic or logic mistakes on multi-step tasks”
Chain-of-thought or extended thinking
“Retrieved text contains instructions that the model follows”
Tag the document as data and state it must not be followed
“Parser fails on some responses”
JSON schema plus code validation
“Need a formal, support-agent voice”
Role in the system prompt
Common traps
Expecting reasoning prompts to fix a format problem. Format needs examples or a schema.
Putting untrusted document text in the same block as instructions with no separation.
Unlimited examples, which consume context and cost without improving results.
Relying on the prompt alone to guarantee valid JSON. Validate in code.
Fine-tuning to fix a formatting issue that a few-shot prompt would solve at lower cost.
Changing many prompt parts at once, so no one knows which change helped.
A third-party logistics company receives thousands of shipping emails a day from carriers. A model must read each email and return one exception code from a fixed list of 14 codes, such as DAMAGED_IN_TRANSIT or ADDRESS_NOT_FOUND, so the warehouse system can route the case.
The model's current output sometimes adds an explanation, sometimes uses a label that is not on the list, and sometimes writes the code in a different case. The warehouse system rejects every such reply.
The fix must go live the same day, with no training job, and it must keep latency low.
Which change meets these requirements?
Choose one answer.
AA. Ask the model to reason step by step and write a short explanation of its choice before giving the code on the last line, so that the format is more careful and the code is easier to check.
BB. Add three to five worked examples to the prompt, each showing a realistic email and the exact code it should produce, including one edge case and the required uppercase format.
CC. Raise the temperature setting so that the model considers more labels for each email, which gives it more options to match an unusual message to a code on the list.
DD. Fine-tune a model on 50,000 labeled emails, so that it learns the code format from the training data, and deploy the new model after the training job finishes.
Show the answer and explanation
Answer: B
A. Wrong: Reasoning text adds output tokens and latency, and it does not stop the model from writing a label that is not on the list. The reply would still be rejected by the warehouse system, so the format requirement is missed.
B. Right: Few-shot examples show the model the exact output pattern, which makes the reply format far more consistent. The change is only a prompt edit, so it goes live the same day with no added latency.
C. Wrong: A higher temperature adds randomness to the output, which makes format errors more likely, not less. It does nothing to enforce the fixed list of codes.
D. Wrong: Fine-tuning can improve format consistency, but it needs a labeled dataset and a training job that cannot finish the same day. The team also has no time to wait for a training cycle, so this misses the go-live requirement.
Explanation
Few-shot examples show the exact output pattern, including the uppercase codes and an edge case, and they change only the prompt, so the fix goes live the same day with no added latency. Step-by-step reasoning adds latency without fixing the format, higher temperature adds randomness, and fine-tuning cannot finish on this timeline.
Want more on Prompt engineering techniques (few-shot, chain-of-thought, structured output)? The 5 full-length practice sets have 5 more Prompt engineering techniques (few-shot, chain-of-thought, structured output) questions, 375 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →
Study Prompt engineering techniques (few-shot, chain-of-thought, structured output)