Prompt Engineering Techniques: Zero-Shot to Chain-of-Thought (AIF-C01)

Prompt engineering is the practice of designing the input you give a foundation model so it returns accurate, relevant, useful output. Because you are only changing the prompt, not retraining the model, it is the fastest and cheapest way to improve results. A well-built prompt is usually made of a few recognizable constructs.

• Instruction — the task you want done, stated directly, such as "Summarize the review in two sentences." Clear instructions are the heart of a good prompt.
• Context — background information the model should use, such as the document to summarize, the audience, or the role the model should play. Context grounds the answer.
• Input data — the specific content the model acts on, for example the customer message or the text to translate.
• Examples — sample input-and-output pairs that show the model the format or style you expect. Examples power the few-shot techniques below.
• Negative prompts — instructions about what to avoid, such as "Do not include personal opinions" or "Do not mention competitors." Negative prompts steer the model away from unwanted content.

You rarely need all of these at once, but recognizing them helps you diagnose a weak prompt. If a model's answer is off-topic, the context may be missing; if the format is wrong, add an example; if it keeps including something unwanted, add a negative prompt. The exam expects you to match each construct to its role in shaping the response.

The most commonly tested techniques differ by how many examples you include in the prompt. An example is a demonstration of the task, an input paired with the desired output, that shows the model what you want.

Zero-shot prompting gives the model an instruction with no examples and relies on its built-in knowledge. For instance: "Classify this review as positive or negative: The delivery was fast and the product works great." You provide only the task and the input. Zero-shot is quick and works well for straightforward tasks a capable model already understands.

Single-shot (also called one-shot) prompting gives one example before the real task, so the model can see the expected format. You might show one review already labeled "positive," then ask the model to label a new one the same way.

Few-shot prompting gives several examples, typically two to five, before the real task. Each example demonstrates an input and its correct output, so the model learns the pattern from the samples and applies it. Few-shot improves accuracy and consistency on tasks where the format or the desired judgment is not obvious from a plain instruction, such as applying a specific labeling scheme or a particular writing style. The trade-off is that more examples use more tokens. For the exam, anchor on the count: zero examples is zero-shot, one example is single-shot, and several examples is few-shot. When a scenario says "give the model a few examples in the prompt," the answer is few-shot prompting.

Chain-of-thought (CoT) prompting asks the model to show its reasoning step by step before giving a final answer, often by adding a phrase such as "Let's think step by step" or "Explain your reasoning, then answer." By working through intermediate steps, the model handles complex, multi-step problems, such as word problems, logic puzzles, or multi-part analysis, more reliably than when it jumps straight to an answer. The technique trades extra output tokens for better accuracy on hard tasks. When a question describes a complex reasoning problem and asks how to improve the model's accuracy, chain-of-thought is the technique being tested.

Prompt templates are reusable prompt structures with placeholders that you fill in for each request. Instead of rewriting a prompt every time, you create a template such as: "You are a support assistant. Using the following policy: {policy}, answer the customer question: {question}. Do not guess if the answer is not in the policy." The bracketed slots are filled with real values at run time. Templates make prompting consistent and repeatable across many requests, which matters when an application sends thousands of prompts. They also make prompts easier to test, share, and improve, because everyone uses the same proven structure. Templates often combine the constructs from the first section, a role, an instruction, context, and a negative prompt, into one dependable pattern that a whole team can reuse.

The table below summarizes the core techniques and when to reach for each.

A concrete before-and-after shows why technique and construction matter. A weak prompt is: "Write about our product." It is vague, has no context, no audience, and no format, so the model guesses and the output is generic.

An improved prompt applies clear instruction, context, specificity, and a negative prompt: "You are a marketing writer. Write a 50-word product description for the SoloBrew coffee maker, a compact single-cup brewer aimed at people in small apartments. Highlight its small size and one-touch operation. Use a friendly, concise tone. Do not invent technical specifications." The improved version tells the model who to be, exactly what to produce, for whom, what to emphasize, the length and tone, and what to avoid. This is prompt engineering in action: same model, far better result, achieved only by rewriting the prompt.

Prompt engineering delivers real value with no training cost, which is why the exam frames it as the first tool to reach for. The main benefits and best practices are worth knowing as a group.

Benefits. Good prompts improve response quality, producing more accurate and relevant answers. Prompting supports fast experimentation, since you can test many variations quickly and cheaply. It aids discovery, helping you learn what a model can do for your use case. And prompts can enforce lightweight guardrails at the instruction level, for example telling the model to refuse off-topic requests or to stay within a defined scope.

Best practices. Follow a few habits to get consistent results:

• Be specific. State exactly what you want, including format, length, tone, and audience. Vague prompts produce vague answers.
• Give clear instructions. Put the task up front and phrase it plainly, avoiding ambiguity.
• Be concise. Include what the model needs and cut noise; unnecessary text wastes tokens and can distract the model.
• Provide context and examples. Ground the model with relevant background, and show examples when the format or judgment is not obvious.
• Experiment and iterate. Try variations, compare results, and refine, since small wording changes can noticeably change output.

Taken together, specificity, clarity, and concision are the habits that most improve results, and the exam rewards recognizing them as best practices.

Prompting introduces security risks the exam expects you to recognize, because a model follows instructions in its input and an attacker may try to control that input. Learn each term by what it does.

• Prompt injection — an attacker hides malicious instructions inside the input, such as a document or user message, to trick the model into ignoring its original instructions and doing something else. This is the headline risk when untrusted text reaches a model.
• Jailbreaking — crafting input designed to bypass the model's safety rules and make it produce restricted or harmful content it would normally refuse.
• Prompt hijacking — taking over the model's behavior by overriding the intended instructions, redirecting it to serve the attacker's goal instead of the application's.
• Prompt (or prompt-data) poisoning — corrupting the examples, context, or data a model relies on so its behavior is skewed or its outputs become untrustworthy.
• Exposure — sensitive information leaking, for example a system prompt, private data, or confidential context being revealed in the model's output.

The limitation behind all of these is that a foundation model does not truly separate trusted instructions from untrusted input; it treats the whole prompt as text to act on. That is why untrusted content, such as a user message or a fetched web page, must be handled carefully. For the exam, connect "trick the model into ignoring its instructions" to prompt injection, and "bypass the model's safety rules" to jailbreaking. Deeper guardrail and responsible-AI controls belong to another domain; here you only mention prompt-level defenses.

Once prompts become part of a real application, they need to be managed like any other important asset. A prompt that works today may be edited, and a change can quietly make outputs worse, so teams need a way to save, compare, and roll back prompt versions. This is prompt versioning and management: keeping track of prompt changes over time, storing known-good versions, and reusing tested prompts across an application.

On AWS, Amazon Bedrock Prompt Management is the service for this. It lets you create, store, and version prompts in one place, so you can build a prompt, save it as a version, test changes, and return to a previous version if an edit causes problems. Because prompts are stored centrally, teams can reuse the same approved prompts instead of copying slightly different versions into different parts of the code, which reduces inconsistency and mistakes.

The exam-level point is simple: when a scenario describes the need to organize, version, reuse, or roll back prompts in a controlled way, Amazon Bedrock Prompt Management is the AWS answer. It brings the same discipline to prompts, saving versions, comparing them, and reusing tested ones, that developers already apply to source code, which matters as an application grows and many prompts must stay consistent and reliable over time.