Claude Code

Claude Code is 20% of the CCAR-F blueprint — roughly 12 of the 60 official-simulation questions. It is tied with Prompt Engineering & Structured Output for second-largest domain after Agentic Architecture & Orchestration, and unlike that domain it rewards candidates who have actually used the tool on real engineering work. The exam does not ask you to install Claude Code or recite its CLI flags. It asks you to make decisions: where does a rule belong, what does a hook do, which permission model fits a CI job, how do you keep multi-file edits coherent, and what separates behavioural guidance from runtime configuration.

The single most-tested distinction in this domain is between CLAUDE.md and settings.json. CLAUDE.md holds behavioural rules — 'always run tests before committing', 'never touch the /config directory', 'match the existing file style'. settings.json holds configuration — which MCP servers to load, which tool permissions to grant, which hooks fire on which lifecycle events. Candidates who blur this line lose easy points. The other heavily-tested area is CI and non-interactive use: when Claude Code runs in a pipeline, you cannot rely on interactive approvals, so permissions, hooks, and prompt design have to do the work instead. Treat this domain as 'how do real engineering teams operate Claude Code responsibly', not as a vocabulary quiz.

What the exam actually tests

• Where behavioural rules live (CLAUDE.md) vs. where configuration lives (settings.json)
• What settings.json actually configures: permissions, MCP servers, hooks — not rules
• Hook lifecycle events and what hooks can and cannot do
• Reducing false positives in CI reviews via explicit criteria, not threshold tuning
• Multi-file editing: surgical context, verification after edits, avoiding orphaned code
• Sub-agents in Claude Code: when to delegate and how scope is partitioned

CLAUDE.md — the project's behavioural-rules file

CLAUDE.md at the project root is the canonical place for behavioural rules Claude Code must follow inside that project. It is read automatically whenever Claude Code is invoked in the project. It is the right home for: coding conventions, test-first workflow requirements, path restrictions ('never modify /config'), commit-message style, and verification baselines. It is the wrong home for: API keys, MCP server lists, or tool permissions — those are configuration, not rules. CLAUDE.md can also be placed in subdirectories for path-specific overrides; the closest CLAUDE.md wins. A common exam distractor invents files like .clauderc or .claude/rules/global.md — those are not the canonical mechanism. Project rules go in CLAUDE.md at the project root.

settings.json — configuration, not rules

settings.json controls how Claude Code is wired up: which tools and bash commands are allowed (the permissions allowlist), which MCP servers connect at startup, and which hooks fire on which lifecycle events. It does not hold behavioural instructions, and putting rules like 'always run tests' in settings.json is a classic wrong answer. There are typically multiple settings layers — user-level, project-level, and project-local — and project-local overrides win. On the exam, if an option talks about behavioural guidance living under a 'rules' key in settings.json, treat it as a distractor. settings.json is the plumbing; CLAUDE.md is the policy.

Hooks — shell commands on lifecycle events

Hooks let you run shell commands when Claude Code reaches a defined point in its lifecycle — for example before a tool call, after a tool call, on session start, or when Claude is about to stop. Hooks are configured in settings.json and execute on the host machine, which makes them powerful for enforcement (block a write to a protected path, run a formatter after every edit, post a notification when Claude stops). Because hooks are executed by the harness rather than the model, they are the right mechanism for hard guarantees: behaviours you cannot afford the model to forget. Behavioural preferences that the model should weigh contextually still belong in CLAUDE.md, not in a hook.

Multi-file editing and verification

Claude Code is designed for multi-file work — refactors, feature implementations, renames that cross module boundaries. The exam-correct workflow is surgical: read only the files relevant to the task, edit only what the task requires, and remove imports or symbols your change orphaned. After multi-file edits, verification is non-negotiable: run the focused test that proves the new behaviour, then the broader suite, then lint and build. 'Send the whole repository on every call' is always wrong — it wastes tokens, dilutes attention, and is a common distractor for context-management questions. Surgical context plus end-of-task verification beats brute-force inclusion every time.

CI integration and sub-agents

Claude Code runs non-interactively in CI for tasks like PR review, changelog generation, and migration scaffolding. In CI you cannot approve tool calls by hand, so permissions and prompt design carry the load: tightly scope the allowlist, define explicit review criteria, and prefer machine-readable output. False-positive review noise is fixed by clearer criteria in the prompt ('flag only security, broken logic, and missing error handling as blocking; style is a suggestion'), not by lowering confidence thresholds or sending more context. Claude Code also supports sub-agents — focused delegations the main agent dispatches for a bounded subtask. They inherit the same permission model and are useful for parallelising independent work, not for hiding state from the orchestrator.

Where candidates go wrong

How to study this domain

Spend most of your prep time on the CLAUDE.md vs. settings.json distinction. For every fact, ask yourself: is this a rule the model should follow, or is this configuration the harness needs to wire things up? Rules go in CLAUDE.md. Configuration goes in settings.json. If you can answer that question quickly under exam pressure, you will pick up several easy points.

Next, get hands-on with hooks and permissions on a small project. Add a pre-tool-call hook that blocks writes to a protected path, then add a post-edit hook that runs a formatter. Once you have done it once, the lifecycle-event questions become trivial. For CI integration, practise writing a review prompt that specifies blocking vs. informational issues — that one technique answers most CI-flavoured questions on the exam. Finally, do 20–30 practice questions from this domain and pay close attention to options that invent file names like .clauderc or .claude/rules/global.md; those are tells for distractor answers. The real mechanism is CLAUDE.md plus settings.json. Nothing else.

Common questions