How many questions on the CCA-F exam are from Claude Code?

Claude Code is 20% of the blueprint — the second-largest domain after Agentic Architecture. On the 60-question Official Simulation that maps to roughly 12 questions.

What's the single most-tested distinction in this domain?

CLAUDE.md vs. settings.json. CLAUDE.md is for behavioural rules the model should follow ('run tests before committing', 'never edit /config'). settings.json is for configuration the harness needs ('permissions allowlist', 'MCP servers', 'hooks'). Mixing them up is the most common way candidates lose easy points.

Do hooks replace CLAUDE.md rules?

No. Hooks are for hard guarantees enforced by the harness — block a write, run a formatter, fail on a check. CLAUDE.md is for behavioural guidance the model weighs contextually. Use hooks when you cannot afford the model to forget. Use CLAUDE.md for everything else.

How do I stop Claude Code from being too noisy in CI reviews?

Define explicit review criteria in the prompt: what is blocking, what is informational, and what should be ignored. Few-shot examples calibrate further. Do not try to fix noise by sending more context, lowering a confidence threshold, or switching to plan mode — those do not change the criteria Claude uses.

Do I need to memorise every Claude Code CLI flag?

No. The exam tests configuration and workflow decisions, not flag syntax. Know what Claude Code is, what CLAUDE.md and settings.json each control, what hooks do, how multi-file editing should be scoped, and how non-interactive CI use changes the permission and prompt model.

Claude Code

20%

Claude Code is 20% of the CCA-F blueprint. It tests how you configure and use Anthropic's terminal-based agentic coding tool — CLAUDE.md behavioural rules, settings.json configuration, hooks, multi-file workflows, and CI integration.

Claude Code is 20% of the CCA-F blueprint — roughly 12 of the 60 official-simulation questions. It is the second-largest domain after Agentic Architecture, 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 tests in this domain

·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

Key concepts

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.

Common traps and distractor patterns

Trap 1 — 'Put the behavioural rules in settings.json'

Distractors frequently suggest a 'rules' key in settings.json or a .clauderc file in the home directory. Both are wrong. Behavioural rules — run tests before committing, never edit /config, match existing style — belong in CLAUDE.md at the project root. settings.json is for permissions, MCP servers, and hooks. If an option puts behaviour under settings.json, it is the distractor.

Trap 2 — 'Lower the confidence threshold to reduce false positives'

When CI reviews flag too many trivial issues, the tempting wrong answer is to dial down a confidence threshold or use plan mode to 'think harder'. Neither addresses the root cause. False positives come from unclear criteria. The right answer is to specify in the prompt what counts as blocking vs. informational and to provide few-shot examples. Clearer criteria, not tuning, fix noisy reviews.

Trap 3 — 'Send the full repository on every call'

Some options frame a maximally large context as a quality improvement. In Claude Code it is the opposite: more irrelevant context dilutes attention, increases cost, and makes hallucination more likely. Multi-file work should be surgical — read the files the task touches, plus anything they directly depend on. 'Increase the context window by sending the entire repo' is almost always the wrong answer.

Trap 4 — 'Use a hook for soft behavioural preferences'

Hooks are for hard guarantees enforced by the harness: block a write, run a formatter, fail the session if a check fails. They are the wrong tool for nuanced behavioural guidance like 'prefer functional style' or 'explain reasoning before editing'. Those belong in CLAUDE.md, where the model can weigh them contextually. Choosing a hook for a soft preference is a common distractor pattern.

Sample questions with explanations

Question 1
A team wants Claude Code to always run tests before committing and to never modify files in the /config directory. Where should these rules be placed?
- A.In the Claude Code settings.json under 'rules'
- B.In a .claude/rules/global.md file that applies to all projects
- C.In a .clauderc file in the user's home directory
- D.In the CLAUDE.md file at the project root✓ Correct
Why D is correct: Project-specific rules and constraints belong in CLAUDE.md at the project root. This file is automatically read by Claude Code when working in that project and can contain both behavioral rules (run tests before committing) and path-specific restrictions (never modify /config). CLAUDE.md files can also be placed in subdirectories for path-specific overrides. settings.json handles configuration like MCP servers and permissions, not behavioral rules.
Question 2
You are integrating Claude Code into a CI pipeline to review pull requests. The reviews are generating too many false positives on style issues. Which approach best reduces false positives?
- A.Increase the context window by sending the full repository on every review
- B.Lower the confidence threshold so Claude flags fewer issues overall
- C.Define explicit review criteria in the prompt specifying what constitutes a blocking issue versus a suggestion✓ Correct
- D.Use plan mode for all CI reviews to force more careful consideration
Why C is correct: Explicit review criteria in the prompt directly address false positives by telling Claude what should be flagged as blocking versus informational. For example, specifying 'Only flag security vulnerabilities, broken logic, and missing error handling as blocking issues. Style and naming are suggestions.' Few-shot examples of good and bad reviews further calibrate the output. Lowering confidence thresholds, increasing context, or using plan mode don't directly address the criteria Claude uses to classify issues.
Question 3
What is Claude Code?
- A.An agentic coding tool that runs in the terminal, enabling developers to interact with Claude for coding tasks✓ Correct
- B.A visual programming language developed by Anthropic
- C.A web-based IDE similar to VS Code
- D.A Chrome extension for AI-assisted writing
Why A is correct: Claude Code is Anthropic's agentic coding tool that runs directly in the terminal. It enables developers to interact with Claude for a wide range of coding tasks including writing code, debugging, understanding codebases, and managing git workflows — all from the command line.

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.

Frequently asked questions

How many questions on the CCA-F exam are from Claude Code?: Claude Code is 20% of the blueprint — the second-largest domain after Agentic Architecture. On the 60-question Official Simulation that maps to roughly 12 questions.
What's the single most-tested distinction in this domain?: CLAUDE.md vs. settings.json. CLAUDE.md is for behavioural rules the model should follow ('run tests before committing', 'never edit /config'). settings.json is for configuration the harness needs ('permissions allowlist', 'MCP servers', 'hooks'). Mixing them up is the most common way candidates lose easy points.
Do hooks replace CLAUDE.md rules?: No. Hooks are for hard guarantees enforced by the harness — block a write, run a formatter, fail on a check. CLAUDE.md is for behavioural guidance the model weighs contextually. Use hooks when you cannot afford the model to forget. Use CLAUDE.md for everything else.
How do I stop Claude Code from being too noisy in CI reviews?: Define explicit review criteria in the prompt: what is blocking, what is informational, and what should be ignored. Few-shot examples calibrate further. Do not try to fix noise by sending more context, lowering a confidence threshold, or switching to plan mode — those do not change the criteria Claude uses.
Do I need to memorise every Claude Code CLI flag?: No. The exam tests configuration and workflow decisions, not flag syntax. Know what Claude Code is, what CLAUDE.md and settings.json each control, what hooks do, how multi-file editing should be scoped, and how non-interactive CI use changes the permission and prompt model.
Where do sub-agents fit in Claude Code?: Sub-agents are focused delegations dispatched by the main agent for a bounded subtask. They inherit the same permission model and are useful for parallelising independent work. They are not a way to hide state from the orchestrator or to bypass permissions — the same settings.json scoping applies.

Practice Claude Code questions

$24.99 lifetime access. 1,000+ scenario-based questions across all 5 domains, adaptive difficulty, written explanations, 7-day refund.

Get Lifetime Access — $24.99

Or try 15 free questions first, or see 10 free sample questions.