Hooks, and Claude Code as an operating surface
Two small domains to close on. Claude Code Operation is 3.1% and Claude Hooks is 1.0%, so this is a working-level lesson, not a manual. Know what the things are and where they sit.
Claude Code, in the amount the exam wants
Claude Code is an agentic coding tool that operates in your terminal against your actual repository. You drive it in natural language, it reads and edits files, runs commands, and works through multi-step tasks with the codebase as its context rather than a pasted snippet.
The operational facts worth holding: it works against real files in a real working directory, it is configured per-project as well as globally, and it is interactive by default but scriptable.
The one architectural fact that carries the most weight:
That framing is worth memorising verbatim, because the natural assumption is the other one. Almost every vendor SDK you have used is a transport wrapper. This is the agent.
Hooks: the deterministic interception point
You already know this pattern under another name. A line in CONTRIBUTING.md saying "always run the formatter before you commit" is a request; a pre-commit hook is a fact about what happens. Nobody who has maintained a repository believes those two are equivalent, and nobody expects the wording of the CONTRIBUTING.md line to close the gap.
A hook is a configured command that fires at a defined point in the agent's lifecycle. Around tool use, around edits, at session boundaries. You configure it in settings; you do not ask for it in a prompt.
The single property that matters, and the only thing worth a whole percent of an exam:
A hook is not a decision the model makes.
You can write "always run the linter after editing" in your project instructions. It will mostly happen. Mostly is a probability, and on current models a more forcefully worded version of that instruction is actively worse, because they overtrigger on emphatic language.
A hook that fires on the edit event runs the linter. Full stop. No negotiation, no context window, no chance the instruction got crowded out by three thousand lines of file content.
Why this lands in the security module
Because it is the same distinction as the previous lesson, one layer down.
Guardrails are enforcement because they sit outside the model and can veto. Hooks are enforcement because they sit outside the model's decision-making and fire regardless. Prompt instructions shape behaviour. Hooks and guardrails constrain it.
If you want a single sentence to carry out of the whole security half of this course: anything that has to be true cannot live in the context, because everything in the context is negotiable.
Try it yourself
Hooks versus instructions
You want to guarantee that a formatter runs after every file edit, every time, with no exceptions. What do you reach for?
The Agent SDK
What is the relationship between Claude Code and the Agent SDK?
What a hook is
One definition and one property. The property is the whole reason this concept is worth a percent of an exam, so an answer that only defines the mechanism is half an answer.
What is a Claude Code hook, and what does it give you that a prompt instruction cannot?
Hooks as the guardrail pattern
This card asks you to join two lessons together rather than to retrieve a fact. If the link comes back as one sentence, you have it.
Why do hooks belong in the security domain rather than only the tooling domain?
Sort your own rules
Ten minutes, one scratch file, no configuration changes. A sorting exercise rather than a setup exercise, and the useful output is a disagreement between what you believed and what is true.
Tick every step to confirm you did it.