Claude Code

3.1% of the Claude Certified Developer – Foundations blueprint — roughly 2 of the 53 questions on a real sitting.

Claude Code is 3.1% of the CCDV-F blueprint — roughly 1 or 2 of the 53 scored questions, and the second-smallest domain. Its single sub-skill is Claude Code Operation, and that word is the whole brief: the exam cares whether you can drive the tool correctly on a real codebase, not whether you can design a platform around it.

That sets a hard ceiling on how much preparation is rational. Claude Code ships continuously and its surface is large — dozens of settings keys, dozens of hook events, a long list of CLI flags — and memorising any of it is a poor return on one or two questions. What generalises is the structure underneath: the tool reads layered instruction files, resolves layered configuration with a defined precedence, gates tool calls through a permission system, and offers hooks when a rule must be guaranteed rather than merely followed.

The distinction that carries the most exam weight is between guidance and enforcement. Behavioural instructions — coding conventions, workflow requirements, paths to leave alone — live in project memory: `CLAUDE.md`, or a rules file under `.claude/rules/`. Configuration lives in `settings.json`: permissions, MCP servers, hooks, model selection. Guarantees live in hooks and permission rules, because those are executed by the harness rather than weighed by the model. Get that three-way split straight and you will answer most of what this domain asks, without memorising a single flag.

What the exam actually tests

  • —Where project instructions live: `CLAUDE.md`, `./.claude/CLAUDE.md`, `CLAUDE.local.md`, and `.claude/rules/`
  • —That `.claude/rules/` is a real, documented mechanism — including path-scoped rules via `paths:` frontmatter
  • —settings.json precedence: managed policy, then CLI arguments, then local project, then shared project, then user
  • —Permission evaluation order — deny, then ask, then allow — and why specificity does not override it
  • —Hooks as harness-enforced guarantees, where exit code 2 blocks the action
  • —Non-interactive operation with `--print`, structured output, and what a headless run inherits from the repository

Project memory: CLAUDE.md and .claude/rules/

Claude Code assembles its instructions from layered memory files rather than a single one. A managed enterprise policy file, a user-level `~/.claude/CLAUDE.md`, a project `./CLAUDE.md` or `./.claude/CLAUDE.md`, and a personal `./CLAUDE.local.md` are concatenated rather than overridden, with files closer to the working directory read last. `CLAUDE.md` can pull in other files with `@path` imports, resolved relative to the importing file and bounded to a maximum depth of four hops. Alongside this, `.claude/rules/` is a first-class mechanism: every `.md` file under a project or user rules directory is discovered recursively, and rules without a `paths` frontmatter field load at launch with the same priority as `.claude/CLAUDE.md`. Rules that do declare `paths` globs load only when Claude reads a matching file.

settings.json is configuration, and it layers

`settings.json` holds the wiring: permissions, hooks, MCP server configuration, model selection, environment variables and similar operational knobs. It exists at several scopes — user (`~/.claude/settings.json`), shared project (`.claude/settings.json`), local project (`.claude/settings.local.json`) and a managed policy file that administrators control — and the resolution order runs managed policy first, then command-line arguments, then local project, then shared project, then user settings. The important subtlety is that array-valued settings such as `permissions.allow` merge and de-duplicate across scopes instead of the narrowest scope replacing the broadest. Behavioural instruction does not belong here; a 'rules' key holding coding conventions is a classic invented distractor.

Permissions: three lists, evaluated in a fixed order

Tool use is gated by three lists — `permissions.deny`, `permissions.ask` and `permissions.allow` — and by a permission mode that sets the default posture. Rules take the form `Tool` or `Tool(specifier)`: `Bash(npm run build)`, `Read(./.env)`, `Edit(/src/**/*.ts)`, `WebFetch(domain:example.com)`, and `mcp__server__tool` for MCP tools. Evaluation runs deny first, then ask, then allow, and the first match in that order decides — a more specific allow rule does not beat a broader deny. One useful detail: a bare denial of a tool name removes that tool from the model's context entirely, while a scoped denial leaves the tool available and blocks only the matching invocations. Permission modes range from prompting on every action through to a bypass mode that should be reserved for genuinely sandboxed environments.

Hooks are for guarantees, not preferences

Hooks run shell commands, HTTP calls or other handlers at defined points in the session lifecycle — before and after tool use, on prompt submission, at session start and end, before compaction, and at many other events. They are configured in settings (and can also be declared by plugins, skills and subagents), and because the harness executes them rather than the model deciding to honour them, they are the correct mechanism for anything you cannot afford to be forgotten: blocking a write to a protected path, running a formatter after every edit, failing a session when a check fails. A hook exiting with code 2 is a blocking error; a `PreToolUse` hook can also return a structured decision that allows, denies or escalates the call to a prompt. Soft preferences the model should weigh in context still belong in memory files.

Non-interactive operation

`claude -p` (`--print`) runs a single non-interactive turn and exits, which is how Claude Code lands in CI, scripts and the GitHub Action. `--output-format` selects `text`, `json` or `stream-json`, and pairing `--json-schema` with JSON output produces a validated payload in a `structured_output` field — the difference between a pipeline that parses prose with a regex and one that reads a field. Because print mode never shows a trust dialog, a headless run in an untrusted repository will load that repository's configured hooks and connect its MCP servers; `--bare` skips auto-discovery of hooks, skills, plugins, MCP servers and memory files, and is the recommended mode for scripted use. In CI you also cannot approve tool calls interactively, so the permission lists and the prompt have to carry the whole load.

Where candidates go wrong

Trap 1 — 'Rules files are not a real mechanism'

Older study material — including some circulating question banks — treats `.claude/rules/` as an invented file path and marks it wrong on sight. That is out of date. Rules directories are documented behaviour at both project and user scope, discovered recursively, and support path-scoped loading through a `paths` frontmatter field. The genuine distractor in this area is the opposite claim: that behavioural conventions belong under a key in `settings.json`. Instructions go in memory files, including rules files; configuration goes in settings.

Trap 2 — 'The most specific permission rule wins'

Engineers import intuitions from firewall and IAM systems where specificity or ordering within a policy decides. Claude Code does not work that way: the lists are consulted deny, then ask, then allow, and the first match in that sequence determines the outcome regardless of how narrowly a later rule is written. An answer that resolves a conflict by picking the more precise rule is wrong; the answer that resolves it by list order is right.

Trap 3 — 'Subagents and skills both just add instructions'

They are different mechanisms with different context behaviour. A subagent, defined by a markdown file with frontmatter under `.claude/agents/` or `~/.claude/agents/`, runs in its own isolated context window with its own system prompt, tool access and permissions. A skill loads instructions into the main conversation, so it shares the current context. Options that describe subagents as a way of injecting extra instructions into the same conversation, or that treat the two as interchangeable, are the distractors — the whole point of a subagent is that the parent's context stays clean.

Trap 4 — 'Headless mode is inherently safer than interactive'

It is easy to assume that a non-interactive run does less, because nobody is approving anything. In fact print mode skips the trust prompt, so pointing it at a repository you do not control means that repository's hooks and MCP servers are loaded and run. The safe pattern for automation is explicit: restrict the permission lists, prefer `--bare` so nothing is auto-discovered, supply credentials through the environment, and treat the checked-out code as untrusted input rather than as configuration you have vetted.

How to study this domain

Cap your time here. At 3.1% this is one or two questions, and Claude Code ships continuously — the number of hook events, the settings keys, and the flag list all move between releases, so version-specific trivia is the worst thing to memorise.

Spend your effort on the three-way split instead. For any fact you meet, ask which bucket it belongs to: instruction to the model (memory files, including `.claude/rules/`), configuration for the harness (`settings.json`), or enforced guarantee (permission rules and hooks). Placing a fact correctly in a couple of seconds answers most of this domain without recall.

Then do one hands-on pass, because it is cheap and it sticks. On a throwaway project, add a rules file with a `paths` glob and watch it load only when a matching file is read. Add a deny rule a broader allow cannot override. Add a pre-tool-use hook that blocks a write to a protected path. Run the same task interactively and again with `--print --output-format json`, and compare. An hour of that beats a day of reading — and it inoculates you against the stale claim that rules files are made up.

Common questions

How many CCDV-F questions come from Claude Code?

It is 3.1% of the blueprint — roughly 1 or 2 of the 53 scored questions, the second-smallest domain after Eval, Testing, and Debugging. Its single sub-skill is Claude Code Operation. Note that the architect-level exam weights Claude Code far more heavily; do not carry a study plan across from it.

Is `.claude/rules/` real, or is it a distractor?

It is real and documented. Markdown files under a project or user `.claude/rules/` directory are discovered recursively; those without a `paths` frontmatter field load at launch with the same priority as `.claude/CLAUDE.md`, and those with `paths` globs load when Claude reads a matching file. Older question banks that mark it fabricated are out of date.

What is the difference between CLAUDE.md and settings.json?

`CLAUDE.md` (and rules files) carry instructions the model reads and follows — conventions, workflow requirements, constraints. `settings.json` carries configuration the harness acts on — permissions, hooks, MCP servers, model choice, environment. Putting behavioural rules under a settings key is the classic wrong answer.

When should I use a hook instead of writing the rule in CLAUDE.md?

When the behaviour must be guaranteed rather than followed. Hooks are executed by the harness at lifecycle events, so they enforce things the model cannot skip — blocking a write, running a formatter, failing on a check. Nuanced guidance the model should weigh contextually belongs in memory files, where a hook would be too blunt.

Do I need to memorise the CLI flags?

No. Know that `-p` / `--print` is the non-interactive mode, that `--output-format` offers `json` and `stream-json`, and that a JSON schema can constrain the printed result into a structured field. Beyond that, questions are about operating decisions — permission scoping, what a headless run inherits from a repository — rather than flag syntax.

Practise this domain

The CCDV-F bank is weighted to the blueprint above, so 3.1% of what you practise is this domain — and every option carries a written explanation, not just the correct one.

See CCDV-F

Other CCDV-F domains

Not affiliated with or endorsed by Anthropic. Domain names and weightings are taken from the published exam guide; always check the official guide before booking.