Domain 2 — Claude Code Configuration & Workflows — accounts for 20% of the CCA Foundations exam, and it's the section most likely to reward people who've actually set Claude Code up for a team rather than just used it solo. The questions here aren't really about memorising file names. They're about understanding why the configuration layer is split the way it is, and what goes wrong when that split gets ignored.
It's one of five domains covered in our complete domain-by-domain breakdown — below, we go further into what it tests, how it plays out in a real setup, and the traps that tend to cost candidates marks.
What This Domain Actually Tests
- CLAUDE.md structure, and how project-level and user-level configuration relate to each other
- The practical difference between version-controlled settings and personal, local-only overrides
- Custom slash commands and hooks for turning repeatable work into one-step actions
- Connecting MCP servers so Claude Code can reach external tools and data sources
- Permission models — what gets allowed automatically, what requires confirmation, and why
The Configuration Layers Exist to Separate Two Different Problems
It helps to stop thinking of Claude Code's configuration as "a collection of files" and start thinking of it as an answer to two distinct questions that get tangled together if you don't separate them on purpose: what does this project need every contributor to know and do the same way? and what does this individual need, that nobody else should silently inherit?
CLAUDE.md is durable, shared project memory — the architectural context, conventions, build and test commands, and "things every contributor should know" that you'd otherwise have to repeat in every session. Project-level settings capture shared behavioural defaults: permission baselines, hooks that should run for everyone, the MCP servers the whole team relies on. Personal, local-only configuration is where individual credentials, any permissions an individual has expanded for themselves, and one-off preferences belong — specifically so they don't get committed, shared, or silently inherited by someone who never asked for them.
Worked Scenario: Setting Up Claude Code for a Six-Person Team
Picture a team adopting Claude Code on a shared monorepo. They want consistency — the same test commands, the same code-review expectations, the same baseline of what Claude Code can run without asking — but individuals differ: one engineer connects a personal project-tracker MCP server, another is comfortable granting broader file-system permissions on their own machine than the team's agreed baseline.
The shared pieces belong in version control: a CLAUDE.md describing the repo's structure, build/test/lint commands, and architectural conventions; a committed settings file with the team's baseline permission allowlist and any hooks that should run for every contributor (a pre-commit lint check, for instance); and project-level slash commands for the workflows everyone repeats — reviewing a pull request, scaffolding a test file, drafting a changelog entry.
The individual pieces stay local and out of version control: personal MCP server credentials, any permissions an individual engineer has chosen to expand for themselves, and preferences that would be noise to everyone else. Get this split right and the team gets consistency without anyone's personal setup leaking into — or being silently overwritten by — anyone else's.
Traps That Catch Candidates in This Domain
- Putting secrets or personal credentials into version-controlled config. CLAUDE.md and project-level settings are typically committed to the repository — anything that shouldn't be visible to the whole team, or to the whole internet if the repo is public, doesn't belong there.
- Treating CLAUDE.md as a scratchpad for one-off requests. It's meant to be durable context that stays true across sessions — build commands, conventions, architecture notes. Mixing in "for this session, focus on the auth module" instructions buries the durable signal under noise that misleads the next person, including your future self.
- Defaulting to the broadest permissions for convenience. A wide-open allowlist saves a few confirmation clicks today and creates a much larger blast radius for a mistake — or an injected instruction in untrusted content — tomorrow. The exam tends to favour the narrowest configuration that still gets the job done.
- Assuming every layer of configuration behaves identically. Scenario questions in this domain often hinge on knowing which layer takes precedence when two layers disagree — a detail that's easy to skim past when you're focused on what each file contains rather than how they actually interact at runtime.
If you've already configured a project this way, this domain will largely feel like common sense under exam conditions. If you haven't, that's worth fixing before test day — our practical guide to writing an effective CLAUDE.md file is a good place to start. From there, try our free practice questions or take the 10-question readiness diagnostic to see exactly where Domain 2 sits in your current preparation.