Claude Code Configuration (CCA-F Domain 3) — Claude Cert Academy

Claude Code Configuration carries 20% of the CCA-F exam. This domain is about how you shape Claude Code's behaviour for a specific project or team: what it is allowed to do autonomously, what context it has about the codebase, what skills it can invoke, and how it fits into automated workflows like CI/CD pipelines. Candidates who have used Claude Code in production but have not thought carefully about its configuration often underestimate this domain.

What this domain covers

CLAUDE.md is the primary configuration mechanism for Claude Code. It is a Markdown file that Claude reads at the start of every session to understand the project. The file can live at multiple levels: a global file (in the user's home directory) that applies to all projects, a project-root file checked into the repository, and sub-directory files that apply only when Claude is working in that part of the tree. This hierarchy is called the CLAUDE.md cascade. The exam tests whether you know which level takes precedence and how rules at different levels interact.

Path-scoped rules let you apply different constraints to different parts of the codebase. A common pattern is to allow Claude to edit files freely under src/ but to require human confirmation before modifying database migrations or infrastructure-as-code files. The exam will present scenarios where a developer applied a rule at the wrong level of the cascade and ask you to diagnose the unintended behaviour.

Custom skills (also called slash commands defined in CLAUDE.md) extend Claude Code with project-specific workflows. A skill is a named procedure that Claude can invoke with /skill-name. Well-designed skills have a single, clearly described purpose, accept explicit arguments, and produce deterministic outputs. The exam will ask you to compare skill definitions and identify which one is most likely to produce consistent results.

CI/CD integration questions ask you to reason about how Claude Code operates in a non-interactive context. In a CI environment there is no human to approve a confirmation prompt, so the configuration must be explicit about what Claude is allowed to do without approval. The exam will present pipeline configurations where Claude Code either blocks on an unexpected prompt (too restrictive) or deletes production data (too permissive) and ask you to choose the correct configuration.

Common exam traps

Worked example

Scenario: A team's global CLAUDE.md grants Claude permission to run git commands. The project-root CLAUDE.md does not mention git. A sub-directory CLAUDE.md for the database/migrations/ path explicitly disallows running any commands that modify the database. A developer invokes Claude Code from the database/migrations/ directory and asks it to create and apply a new migration. Claude creates the migration file but refuses to run the apply command, even though the global file permits git commands.

The correct interpretation is that the sub-directory rule restricts database-modifying commands for that path, and running the migration apply command falls within that restriction. The sub-directory rule does not override the global git permission for git operations (like git add), but it does block the apply command because that command modifies the database. The developer needs to either run the apply command from outside the restricted directory or explicitly enumerate the apply command as permitted in the sub-directory CLAUDE.md. The distractor — editing the global CLAUDE.md to be more permissive — would have no effect because the sub-directory rule takes precedence for that path.

Continue to Claude Cert Academy