Prompt engineering, and prompt lifecycle

The syllabus names four prompt engineering techniques: examples, dynamic context
injection, defensive guidelines, and prompt lifecycle management. Three are craft.
The fourth is engineering, and it is the one that gets skipped.

The four

Examples. Few-shot prompting — showing the shape you want rather than describing
it. Almost always more effective than another paragraph of instruction, because a
model matches patterns more reliably than it follows prose.

Dynamic context injection. Inserting retrieved, current material at run time
rather than baking it into the template. This is what keeps a prompt from being a
snapshot of what was true when someone wrote it.

Defensive guidelines. Instructions intended to resist manipulation. Microsoft is
honest about their limits: they "lower the success rate of known attacks; they
don't make the next attack impossible."

Prompt lifecycle management. The prompt treated as a deployable artefact.

Why the lifecycle one matters most

A prompt changes behaviour more than most code changes do, and it changes far more
often. Which makes it, in every meaningful sense, production code — and it is
routinely managed like a document.

The failure mode is easy to recognise once named: a prompt edited in a portal by
nine different people over six months. Nobody knows what the current version is
meant to say, nobody knows why the odd clause in the middle is there, and nobody can
roll back — because there is nothing to roll back to.

So:

Keep it in the repository, not the portal. If it lives only in a portal, you
have an untracked production dependency.

Every change runs the evaluation set, before and after. This is what turns
prompt engineering from superstition into evidence. Without it, a change that feels
better and is measurably worse is indistinguishable from a change that is better.

Prompt and code roll back together. A prompt written for v2 running against v1
code is a state neither was tested in.

A note on defensive guidelines

It is worth being precise about what they are good for, because the exam tests the
boundary.

They are genuinely useful. They reduce the success rate of the attacks people
already know about, they cost almost nothing, and they make ordinary behaviour more
predictable.

They are not a control. They are heuristic, they have to be re-tuned as adversaries
adapt, and they fail exactly when someone is deliberately trying to make them fail.

Use them. Do not rely on them for anything where being wrong is expensive.

The trap

If a requirement says the agent must never do something, a defensive guideline
is the wrong answer however well written it is.

Must never is an absolute, and an instruction is a probability. The correct answer
lives in tool restriction, identity, or an approval gate — somewhere the model's
cooperation is not required.

This is the same rule as card 2, and it recurs because it is the single most
frequently tested idea in this exam: constrain tools, not instructions.