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 — explicit 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.

Negative prompt versus context. Describing a situation is context, and context only implies a rule. Telling a travel-planning assistant that a traveller uses a wheelchair leaves the model to infer which suggestions are unsuitable, and it may not. An explicit negative prompt, such as "Do not suggest venues that can only be reached by stairs," names the unwanted content and targets it directly. When one specific item keeps appearing in the output, a direct exclusion instruction is the construct built for that job; background facts help the model understand the situation but do not reliably remove the item.

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 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 before the real task. There is no fixed number: Amazon Bedrock's prompt guidance notes that a handful can be enough for a simple task such as classification, while harder tasks need more. 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. The names follow the count: zero examples is zero-shot, one example is single-shot, and several examples is few-shot. Because every example adds input tokens, zero-shot is the leanest choice when a capable model already performs the task well; add examples only when testing shows the model needs them.

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. Chain-of-thought addresses faulty reasoning: when an answer is wrong because the model jumped over intermediate steps, asking it to work through those steps targets the cause. Inference settings that only change how varied the output is do not add the missing reasoning (see the comparison with temperature below).

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. Amazon Bedrock Prompt Management, covered at the end of this lesson, stores templates like this with named variables.

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 content versus inference parameters

A prompt technique changes what the model is told; an inference parameter changes how the model samples its reply. Temperature is an inference parameter, not part of the prompt. Lowering it makes output more deterministic and repeatable; raising it makes output more varied. It cannot do the work of prompt content:

• It does not fix faulty multi-step reasoning; chain-of-thought does.
• It does not keep a specific item out of the output; a negative prompt does.
• It cannot supply requirements the prompt never stated, such as length, audience, or format; specific instructions do.

Inference parameters such as temperature, top-p, and maximum length belong to Task 3.1 and are covered in the lesson on design considerations for foundation model applications.

Prompt engineering delivers four benefits with no training cost (better response quality, fast experimentation, discovery, and lightweight guardrails), and a small set of habits produces them consistently.

Benefits

• Response quality improvement. Good prompts produce more accurate, relevant, and well-formatted answers from the same model.
• Experimentation. Changing a prompt takes seconds and costs only the request, so you can test many variations, compare them, and keep the best one.
• Discovery. Trying different prompts reveals what a model can and cannot do for your use case: tasks it handles well, where it struggles, and capabilities you had not planned to use. That knowledge tells you whether prompting is enough or whether you need retrieval or fine-tuning.
• Guardrails. Instructions can set boundaries, for example "Answer only questions about our products" or "If the policy does not cover it, say you do not know." These prompt-level guardrails shape normal behavior, but they are only text the model is asked to follow. Injected or jailbreak input can talk a model out of them, so they complement dedicated controls such as Amazon Bedrock Guardrails rather than replace them.

Best practices

• Be specific. State exactly what you want, including format, length, tone, and audience. The model cannot meet a requirement you never wrote down.
• State the task in plain, concise wording. Phrase the instruction clearly and unambiguously. Amazon Bedrock's prompt guidance recommends placing the question or instruction at the end of the prompt, after the context and input data, for best results.
• Give relevant context, not everything. Context that bears on the task helps; padding the prompt with every document you have breaks concision, costs input tokens on every request, and can bury the details that matter.
• Use multiple comments. AWS lists this practice without a precise definition. The common reading, especially for code-generation assistants, is to guide the model with several short comments or instructions, one per requirement or step, rather than one long run-on request. The underlying principle is that small, separate instructions are easier for the model to follow and easier for you to adjust.
• Provide examples when needed. Show examples when the format or judgment is not obvious from the instruction alone.
• Experiment and iterate. Try variations, compare results, and refine, since small wording changes can noticeably change output.

The main risks of prompting are prompt injection (which AWS groups with hijacking), jailbreaking, exposure, prompt leaking, and poisoning. Each one attacks a different part of the system, so learn each term by what it targets.

Telling the near-twins apart

• Injection and hijacking versus jailbreaking. Prompt injection and hijacking are about redirecting the task: the injected instruction may ask for something entirely harmless, just not what the application was built to do. Jailbreaking is about defeating safety rules to obtain content the model is meant to refuse.
• Exposure versus prompt leaking. Exposure reveals sensitive or confidential data; prompt leaking reveals the prompt or system instructions. AWS treats them as separate risks.
• Poisoning versus prompt injection. Poisoning happens in the training data, so the skewed behavior repeats across fresh sessions even when every prompt and user input looks clean. Prompt injection arrives in a specific request and affects that interaction.

The limitation behind injection, hijacking, and jailbreaking 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.

Each prompt risk has a mitigation that matches where it acts: separate and screen untrusted input for injection and jailbreaking, keep secrets out of the system prompt and screen extraction attempts for prompt leaking, keep restricted data out of the context for exposure, and clean the training data for poisoning. Prompt wording alone is never the whole defense.

Prompt injection, hijacking, and jailbreaking

• Delimit untrusted input. Wrap user-supplied or fetched text in clear delimiters (for example XML-style tags) and tell the model that the enclosed text is data to process, not instructions to follow.
• Screen input with Amazon Bedrock Guardrails. The guardrail prompt attack filter detects attacks in user input before the model acts on them: jailbreaks, prompt injection, and (on the Standard tier) prompt leakage attempts. When you call the model with the InvokeModel API, you mark the user-supplied content with input tags so the guardrail evaluates that content rather than your own system instructions.
• Keep prompt-level guardrails as a complement. Scope instructions still help, but because an attack can override them, they sit on top of a dedicated control, not in place of one.

Prompt leaking

• Keep secrets out of the prompt. Treat the system prompt as something a determined user may eventually see. Never put credentials, API keys, or confidential business data in it; a model cannot leak what the prompt does not contain.
• Screen extraction attempts. The Amazon Bedrock Guardrails prompt attack filter can detect prompt leakage attempts, meaning user input that tries to extract the system prompt or developer instructions (a Standard-tier capability).
• Do not rely on "keep this secret". An instruction telling the model not to reveal its instructions is a prompt-level guardrail and can be talked around like any other.

Exposure

• Fix it at the source. A model cannot reveal data it never received. Pass only the data the requesting user is allowed to see into the context, for example only that customer's own records. This does not depend on the model obeying an instruction.
• Reformatting is not removal. Summarizing, condensing, or reformatting restricted records before putting them in the prompt still places their content in the context, so it can still be exposed.
• Add an output-side second layer. The Amazon Bedrock Guardrails sensitive information filter can detect and block or mask personal data in responses. It is a useful backstop, but it depends on scanning replies, so it complements limiting the context rather than replacing it. A negative prompt such as "Do not discuss other customers" is weaker still, because the model may not obey it.

Poisoning

• Audit training data sources. Vet where training and fine-tuning data comes from, especially public or external sources an adversary could write to.
• Remove the cause, not the symptom. Once a model has learned poisoned behavior, input filters, negative prompts, and output masking only hide its effects in some requests. The fix is to clean the poisoned records out of the training data and retrain or re-fine-tune the model.

Broader security controls for AI systems, such as access control and data governance, are covered under Task 5.1.

Amazon Bedrock Prompt Management is the AWS feature for creating, testing, versioning, and reusing prompts, so a prompt can be changed safely and rolled back like any other application asset. A prompt that works today may be edited, and a change can quietly make outputs worse, so teams need to save known-good versions and return to them.

How it works

• Prompts with variables. A prompt in Prompt Management is a template: its text contains variables written in double curly braces, such as {{product_name}}, that are filled with real values at run time. A prompt also carries its model choice and inference settings.
• Variants. In the prompt builder you can create variants of a prompt, with different wording, a different model, or different settings, and compare their outputs side by side for the same test values.
• Working draft. Editing a prompt and saving it updates the prompt's working draft. Saving does not create a version and does not change anything production is already using.
• Versions. Creating a version takes a point-in-time snapshot of the prompt configuration. An application deploys a specific version, either by referencing it when calling the model for inference or through a prompt node in Amazon Bedrock Flows. A pinned version keeps serving the same prompt however the draft changes.
• Rollback. Because each version is an unchanging snapshot, rolling back is simply a matter of switching the application back to an earlier version. Releasing an improvement works the same way in reverse: snapshot the improved configuration as a new version, then switch the application to it.

Prompt Management versus SageMaker Model Registry. Prompt Management versions prompts. Amazon SageMaker Model Registry versions models (trained model artifacts and their approval status). If the thing that changes is the wording or configuration of a prompt, Prompt Management is the relevant tool; if it is the model itself, Model Registry is.

Storing prompts centrally also lets teams reuse the same approved prompts instead of copying slightly different versions into different parts of the code, bringing the discipline developers already apply to source code to prompts.