Prompt engineering basics: five fixes in order
Prompt engineering is the practice of shaping the input to a language model so that its output is useful, correctly formatted and based on the right information, without changing the model itself. The exam decision rule: fix the prompt before anything else. Give clear instructions, add examples if the format is wrong, supply source material if facts are wrong, and lower the temperature if the output must be repeatable. Only when none of that works do exams move on to RAG or fine-tuning.
One bad prompt, rewritten five times
The easiest way to learn the techniques is to watch one weak prompt improve. The scenario: a support team wants a model to turn a customer email into a short ticket summary.
Version 0. “Summarize this email.” The output is a paragraph of unpredictable length and tone. Nothing is wrong with the model; the prompt left everything open.
Fix 1: instructions. State the task, the audience and the limits. “You are a support triage assistant. Summarize the email below in at most two sentences for an engineer who has not seen it. Name the product and the symptom.” Microsoft’s prompt engineering guidance calls instructions the most commonly used prompt component, and its best-practice list begins with being specific and leaving as little as possible to interpretation.
Fix 2: examples (few-shot). The summaries are now short but the ticket system needs a fixed layout. Add two or three input and output pairs showing the exact layout. With no examples the prompt is zero-shot, with one it is one-shot, with several it is few-shot. Microsoft’s guidance is explicit that this is not learning in the sense of changing the model: the examples condition the response for that single request only. When output format is inconsistent despite clear instructions, examples are the standard remedy.
Fix 3: structure. The prompt mixes instructions, examples and the email in one block, and long emails sometimes get mistaken for instructions. Separate the parts with clear delimiters such as headings, triple dashes, Markdown or XML-style tags. Microsoft notes that models have seen a lot of Markdown and XML and suggests either when unsure. Putting the task first, and repeating a key instruction at the end of a long prompt, are also documented tactics, because text near the end of a prompt can carry extra weight (recency bias).
Fix 4: grounding. Customers ask about refund rules, and the model invents them. Paste the actual policy text into the prompt and tell the model to answer only from it. Give it an out: “If the policy does not cover this, reply ’not covered’.” Microsoft recommends exactly this, and recommends citations because a made-up answer then also needs a made-up citation. Grounding is the idea behind RAG, which automates the step of finding the right text to paste.
Fix 5: parameters. Two runs on the same email still differ in wording. Lower the temperature. Microsoft’s documentation describes lower values (it gives 0.2 as an example) as more focused and concrete and higher values (0.7) as more random and divergent. Its general advice is to change temperature or top_p, not both, and it notes that temperature can be set between 0 and 2. Note that lower temperature gives more consistent output, not more truthful output.
Result, in order of what to try:
| Symptom | First fix |
|---|---|
| Wrong length, tone or scope | Clearer instructions |
| Right content, inconsistent format | Few-shot examples |
| Model confuses instructions with data | Delimiters and structure |
| Invented facts | Grounding data, citations, an “I don’t know” out |
| Different answer each run | Lower temperature |
| Complex task fails as one step | Break it into steps, or ask for step-by-step reasoning |
A caution from the same Microsoft page: it says these techniques are not recommended for reasoning models such as gpt-5 and the o-series, and that each model behaves differently. Treat the list as a method to test, not a guarantee.
Which exams test this
| Exam | How it appears | On this site |
|---|---|---|
| AI-901 | Implement AI solutions by using Microsoft Foundry (55–60%): create effective system and user prompts; the AI concepts domain adds model configuration parameters | Foundry implementation |
| AIF-C01 | Domain 3, Applications of Foundation Models (28%): prompt constructs and techniques such as zero-shot, few-shot, chain-of-thought and templates, prompt risks, and the effect of inference parameters such as temperature; Domain 2 defines prompt engineering | GenAI fundamentals |
| AB-730 | Manage prompts and chats by using Microsoft 365 Copilot (20–25%): write an effective prompt, choose resources to reference, refine from the response, and save, schedule and share prompts (October 20, 2026 outline) | Prompts and chats |
| AB-731 | Business value of generative AI (35–40%): describe the impact of prompt engineering and understand its techniques, at leader level | Business value |
| AB-100 | Plan AI-powered business solutions (25–30%): provide prompt engineering guidelines and techniques and guidelines for a prompt library; testing adds validating Copilot prompt best practices | Plan AI solutions |
| AI-103 | Implement generative AI and agentic solutions (30–35%): tune generation behaviour with prompt engineering and model parameters | Generative AI and agents |
| AI-300 | Design and implement a GenAIOps infrastructure (20–25%): design and develop prompts, compare prompt variants and keep prompts under version control | GenAIOps infrastructure |
| Agentforce Specialist | Prompt Engineering (20%): best practices for writing effective prompts, prompt templates in Prompt Builder and choosing a grounding technique | Prompt engineering (Agentforce) |
| Databricks GenAI Engineer | Design Applications (14%): design a prompt that returns a specific format; Application Development (30%): adjust a prompt from a baseline to a desired output and add context from the user’s input | Application development |
| CY0-001 | Basic AI Concepts Related to Cybersecurity (17%), task 1.1: system and user prompts, zero-shot, one-shot and multi-shot prompting, system roles and templates | AI concepts |
| 200-301 | CCNA v2.0 only (from February 3, 2027), AI and network operations (10%): select a prompt for a generative AI system based on data classification, output format, persona and instructions; not in v1.1 | AI and network operations |
AB-730 tests prompting as a Copilot user (goal, context, source, format) and CCNA v2.0 tests choosing the best prompt for a network task. AI-901, AIF-C01, AI-103 and the Databricks exam test it as a developer or practitioner with parameters and techniques; AB-731 and AB-100 test it at the level of guidelines and business impact. Expect the vocabulary to differ while the ideas match.
How exam questions are built around prompting
Each question names a symptom and offers fixes from different layers. The decision words:
- “Inconsistent format”, “must follow a template” point to few-shot examples, not temperature.
- “Invents”, “not in our documents”, “must cite” point to grounding. Lowering temperature is the classic wrong option: it makes a wrong answer repeatable.
- “Same output every time”, “repeatable for audit” point to low temperature (and fixed instructions).
- “Creative”, “varied” point to higher temperature.
- “Company’s internal data changes weekly” moves past the prompt to RAG; “tone and vocabulary across every response” may justify fine-tuning. The comparison is in fine-tuning vs RAG vs prompting.
- “Cheapest, fastest first step” is almost always prompt changes, since they need no training or infrastructure.
A trap on AB-730: a follow-up that narrows the audience, format or source usually beats starting a new chat from scratch.
Two practice questions
Question 1. A model summarises meeting notes correctly, but the output layout differs on every call and the downstream parser breaks. The instructions already describe the layout in words. What should you change first?
- A. Raise the temperature
- B. Add two or three example input and output pairs to the prompt
- C. Fine-tune the model on thousands of past summaries
- D. Add the company handbook to the prompt as grounding data
Show answer
Answer: B
Few-shot examples show the exact input and output layout and condition the model for each request, which is the usual fix for inconsistent format. Raising temperature increases variation. Fine-tuning is heavier than needed before examples are tried. Adding more source documents addresses missing facts, not layout.
Question 2. An internal assistant answers fluently but sometimes states return-policy rules that do not exist. The policy document is available. Which change most directly reduces the problem?
- A. Lower the temperature to 0 and change nothing else
- B. Raise the temperature so the model explores more options
- C. Include the policy text in the prompt and instruct the model to answer only from it
- D. Ask the model for longer, more detailed answers
Show answer
Answer: C
Supplying the policy text, telling the model to answer only from it, and giving it a way to say the answer is not covered grounds the response and reduces invented rules. Lowering temperature makes output more consistent, not more accurate. Raising temperature adds randomness. Making the answer longer gives the model more room to invent.
Go deeper
- Prompt engineering techniques (Microsoft Foundry): the source for the components, few-shot, grounding and temperature guidance used here.
- Prompt engineering concepts (Amazon Bedrock): AWS’s entry page on prompt design, with links to model-specific prompt guides.
- Next topics: RAG explained, LLM evaluation, embeddings and vector search.
- Study plan context: how to study for certification exams.