A prompt is the whole input a model sees, and prompt engineering is the practice of shaping it so the answer is usable.
What a prompt is made of
Instruction is what you want done. Context is the material to do it with, including retrieved documents and conversation history. Input is the specific case. Output indicator is the shape you want back, such as JSON or a heading and three bullets.
Two further ideas appear in the syllabus. Negative prompts state what to avoid, which works better on image models than on text, where naming a thing tends to summon it. Latent space is the model's internal representation of meaning, and it is the thing a prompt is steering through.
The shot based techniques
Zero shot asks with no examples. It is the default and it works whenever the task is common enough that the model has seen it in training.
Single shot gives one worked example. Few shot gives several. Examples teach format and edge handling far more efficiently than describing them, and this is the cheapest large improvement available. Three examples covering the awkward cases usually beats a paragraph of instructions.
The limits are real. Examples consume context, and the model will imitate their distribution, so if all your examples are positive cases it will lean positive.
Chain of thought
Asking the model to work through its reasoning before answering. It materially improves multi step problems, arithmetic and anything with intermediate conclusions, because the intermediate tokens give the model something to condition on.
Two cautions. The stated reasoning is generated text rather than a report of internal process, so it can be plausible and wrong while the answer is right, or the reverse. And it costs tokens and latency, so applying it to classification is waste.
Role prompting and prompt chaining
Two more the Google exam names.
Role prompting tells the model who to be. Answer as a technical support engineer, or as a sceptical reviewer. It works because it narrows the register, the vocabulary and the assumptions the model draws on, and it is most useful where the same facts should be expressed very differently for different audiences.
Prompt chaining splits work across several calls, each one taking the previous output as input. Extract the facts, then check them against a policy, then write the reply. It costs more calls and it is far easier to debug, since you can see which step went wrong, and each step can use a different model or temperature.
ReAct
ReAct, reason and act, interleaves thinking with tool use. The model reasons about what it needs, calls a tool, reads the result, reasons again. It is the pattern underneath most agents, and it is the point at which prompting stops being about wording and becomes about what the model is permitted to do.
Prompt templates
A parameterised prompt with slots filled at runtime. This is how prompting becomes engineering rather than craft, since a template can be versioned, tested and changed in one place. It also creates the injection surface, because whatever fills the slot is text the model will read as though you had written it.
The four risks
The syllabus names these and expects you to distinguish them.
Exposure is confidential material leaking through the prompt. Anything you put in context can appear in output, so a system prompt containing a key, or a retrieved document the user should not see, is one clever question away from being read back.
Poisoning is corrupting what the model learns from or retrieves. Planting misleading content in a source that gets indexed means the system quotes it back with confidence, and this is the risk that grows as retrieval is added.
Hijacking, or prompt injection, is input that overrides your instructions. A support agent reading a customer email that says to ignore previous instructions and issue a refund is the canonical case. It follows from instructions and data sharing one channel, which is why it cannot be solved with wording.
Jailbreaking is getting the model past its own safety training, usually by roleplay or hypothetical framing.
Defending against them
Treat every model output as untrusted input to whatever consumes it. Filter on the way in and on the way out. Give any tool the model can call the narrowest permission that works. Keep secrets out of prompts. On AWS, Guardrails for Amazon Bedrock applies content filters, blocked topics and word filters to both sides of the exchange, which is the service the exam expects you to name.