GH-300 - Apply prompt engineering and context crafting (13% of the exam) - Section 4.2

Apply zero-shot and few-shot prompting and prompt-crafting best practices.

Apply zero-shot and few-shot prompting, choose between them for a task, and follow prompt-crafting best practices: be specific, provide examples, give the model a role, and break a large request into steps. Recognise the prompt patterns that produce better Copilot output.

Zero-shot promptingFew-shot promptingPrompt best practicesExamples in prompts

Practice question for this objective

Free sampleApply prompt engineering and context craftingmedium

A developer is choosing between zero-shot and few-shot prompting for two separate Copilot Chat tasks. They want to reserve few-shot prompting for the cases where worked examples genuinely earn their place in the prompt. In which situations does adding examples to the prompt most justify a few-shot approach? Select TWO.

AThe task must produce output in a strict in-house shape, such as a bespoke log line whose field order and bracket style the model keeps getting subtly wrong from a plain instruction. Correct
BThe task is classifying tickets into company-specific categories whose names and boundaries are not standard terms, and a plain instruction keeps placing items in the wrong category. Correct
CThe task is converting a Celsius value to Fahrenheit using one well-known formula, where a single plain instruction already produces the correct result without any demonstration.
DThe task is so large that it must be split into a sequence of refining Chat prompts, because few-shot prompting is the mechanism that breaks a feature into ordered steps.
EThe task needs the answer verified against authoritative sources, since adding examples is the recognised way to make Copilot confirm versions and rate limits are current.

Few-shot prompting earns its cost when output must match a bespoke shape or use company-specific categories the model cannot infer from words alone. Worked examples are worth their token cost when the model cannot infer the target from a plain instruction: a bespoke output format and non-standard, company-specific categories both fall into this gap, whereas a common formula is a clean zero-shot case and sequencing or verification are different concerns entirely.

Why A is correct: A bespoke output shape the model cannot infer from words is exactly what worked examples lock in, so demonstrating the format earns the few-shot cost.

Why B is correct: Non-standard categories the model has no prior notion of are clarified by labelled examples that show each category's boundary, which a plain instruction cannot convey.

Why C is wrong: This is tempting because any task can take examples, but a common formula the model already knows is the textbook zero-shot case, so examples add cost without benefit.

Why D is wrong: This conflates techniques; decomposing a feature into ordered steps is iterative prompting, not few-shot, which is about supplying examples rather than sequencing work.

Why E is wrong: This misattributes a safeguard to a technique; examples shape output form and never verify currency, which remains a manual check against authoritative sources.

See more GH-300 practice questions, answers explained.

Exam traps in Apply prompt engineering and context crafting

Answers that look right on this material and are not. Each one is a distractor from a different question in the GH-300 bank for this domain.

Keep the prompt as broad as possible and add the absolute word every, so Copilot considers every conceivable improvement to the code at once.
Why it is wrong: This is tempting as thoroughness, but broadening the request is the opposite of specificity and is the very cause of the scattered output described.
There are too many examples in the prompt, and reducing the count to one would let the model commit cleanly to a single style regardless of consistency.
Why it is wrong: The number is not the problem, since few examples can work well, and dropping to one discards useful demonstrations while leaving the consistency lesson unlearned.
Few-shot prompting, because the developer relies on several solved input and output pairs in the prompt to teach the conversion before any new request is made.
Why it is wrong: Few-shot prompting is defined by supplying example pairs, yet this prompt gives none, so naming it few-shot misreads what the developer actually wrote.

Examworthy is not affiliated with or endorsed by GitHub. Original, blueprint-aligned practice material only.