CCA Domain 3: Claude Code Configuration & Workflows Explained

Domain 3 of the CCA-F exam, Claude Code Configuration & Workflows, is 20% of the score and tests whether you can put the right instruction in the right file (user, project, or directory CLAUDE.md; rules with path globs; commands versus skills), pick the right working mode (plan, explore, direct), and run Claude Code correctly in CI. Almost every question reduces to “who needs this, when should it load, and what guarantees it”.

Below: what the domain covers, why it earns 20%, the concepts to know cold, how questions are phrased, a worked team scenario, and the traps. It is built on our 26-article Domain 3 study guide, with a link to the source article for each idea.

What does CCA Domain 3 cover?

Six task areas, with an anchor article for each:

Task	What it tests	Start here
3.1 Config hierarchy	User, project, and directory CLAUDE.md; @import; .claude/rules/	Put Team Standards Where the Team Can Actually Get Them
3.2 Commands vs skills	Plain prompt files vs SKILL.md with frontmatter (context: fork, allowed-tools, argument-hint)	Commands Are Prompts. Skills Are Configured Workflows.
3.3 Frontmatter paths and globs	paths: globs on rules files; glob rules vs directory CLAUDE.md	86% of Your Rules Context Is Wasted Without Path Globs
3.4 Plan mode and exploration	When to plan, when to just fix it, Explore sub-agents	55% Rollback Rate When You Skip Planning on Complex Tasks
3.5 Examples over descriptions	Concrete examples, tests first, interview mode, issue classification	Text Descriptions Hit an Ambiguity Ceiling at 63%. Examples Reach 91%.
3.6 CI and non-interactive mode	-p, --output-format json, CLAUDE.md as the CI agent’s only context, independent review	Without -p, Your CI Job Hangs Until Timeout Kills It

New to Claude Code entirely? Skim the Foundations pieces first: Claude Code: A CLI Tool, Not an IDE and Four Permission Modes.

Why is Domain 3 weighted at 20%?

Claude Code is the product most CCA-F candidates will actually operate day to day, and configuration is where teams either get consistent behaviour or a “works on my machine” mess. The blueprint gives it a fifth of the exam because the decisions are numerous and each has a clear right answer: there is a correct file for team standards, a correct mechanism for restricting tools, a correct flag for CI. On a 60-question form that is roughly 12 questions (confirm the current weights on the official Anthropic / Pearson VUE page before you register). It is also, in our experience, the domain where hands-on time converts to points fastest.

The concepts you must know cold

Three levels stack; they do not replace each other. ~/.claude/CLAUDE.md is personal and never leaves your machine. .claude/CLAUDE.md in the repo is version-controlled and reaches everyone who clones. A CLAUDE.md inside a subdirectory loads only when files under it are being edited. Team standards in the user-level file is the classic mistake, because cloning a repo does not clone a colleague’s home directory.

Mentioning a file is not loading it. “See docs/style.md” is text the model reads and ignores. @docs/style.md imports the content. Mentioning a File Is Not the Same as Loading It also warns against cross-importing everything, which defeats the scoping the hierarchy exists to provide.

Rules need paths: or they load for every edit. Twelve unscoped rules files load Terraform conventions into a Python edit (Twelve Unscoped Rules Files Waste 78% of Your Context Budget). Overlapping globs both load, by design. Choose glob rules when scope is a file type (**/*.test.ts) and a directory CLAUDE.md when scope is a location, per File TYPE or File LOCATION — That Decides Which Mechanism to Use.

Frontmatter guarantees, instructions guide. A skill’s allowed-tools: Read, Write, Edit makes Bash physically unavailable. A sentence saying “do not execute commands” is probabilistic. context: fork isolates the skill’s memory (not the filesystem, see Fork Isolates Memory, Not the Filesystem). If a workflow needs none of the three frontmatter capabilities, a plain command is simpler. And an always-on rule belongs in CLAUDE.md while an on-demand workflow belongs in a skill (CLAUDE.md Is Always-On. Skills Are On-Demand.).

Plan mode is for uncertainty, not size. Multiple valid approaches, unfamiliar code, or cross-module blast radius call for plan mode. A stack trace that points at line 42 does not (If You Already Know the Fix, Just Fix It). On big repos, delegate reading to an Explore sub-agent so the main context stays small (120 Files Explored, 12% Context Used); the combined flow is in Plan → Explore → Direct.

CI is -p plus --output-format json, and CLAUDE.md is all the agent knows. There is no --batch, no CLAUDE_CI=true. A prompt that says “output JSON” gets JSON most of the time; the flag gets it reliably (Prompt Says “Output JSON” → 73%. Schema Flag → 99%.). Reviews should run in a separate session from generation (Claude Reviewing Its Own Code Is Barely a Review) and should see prior comments and existing tests to avoid duplicates.

How does the exam test Domain 3?

Scenarios describe a team, a config layout, and a symptom. Typical shapes:

• “New hires ignore the naming convention; the senior engineer’s machine works fine.” (Standards are in ~/.claude/CLAUDE.md; move to .claude/CLAUDE.md.)
• “Editing a React component loads database migration rules.” (Unscoped rules or a monolithic root file; add paths: or a directory CLAUDE.md.)
• “The /migrate-db skill executed a DROP TABLE despite instructions.” (No allowed-tools; restrict to Read/Write/Edit.)
• “The nightly CI job hangs and exits 137.” (Missing -p.)
• “Claude’s PR reviews repeat the same comment on every push.” (Give it prior review context, see 62% of Review Comments Were Duplicates. Prior Context Dropped It to 4%..)
• “Which is the fastest way to know what is actually loaded right now?” (/memory, per /memory Tells You What Is Actually Loaded — MEMORY.md Does Not.)

Worked scenario: a six-person team with a monorepo

Setup. Frontend in web/ (TypeScript/React), backend in api/ (Python), infra in infra/ (Terraform). Two engineers wrote 600 lines of standards into their own ~/.claude/CLAUDE.md. Everyone else has nothing. The Jira MCP server works for one person only. A /deploy-preview command sometimes runs terraform apply when it should only generate a plan.

Options.

A. Have every engineer copy the 600-line file into their home directory and document the Jira setup in the wiki. B. Move all 600 lines into a single root .claude/CLAUDE.md, put the Jira server in .mcp.json with a hardcoded token, and add “NEVER run apply” to the deploy command. C. Root .claude/CLAUDE.md with only the cross-cutting standards; .claude/rules/ files scoped with paths: for web/**, api/**, infra/**; Jira in .mcp.json with ${JIRA_TOKEN}; convert /deploy-preview to a skill with allowed-tools that excludes Bash and a documented plan-only tool. D. Keep user-level files but add a pre-commit check that fails if the two files diverge.

Reasoning. A and D leave the wrong-level mistake in place. B fixes distribution but wastes context on every edit, commits a secret, and relies on wording to prevent a destructive command. C puts each concern where the hierarchy intends: shared standards in the repo, scoped rules by path, secrets out of git, and a deterministic tool restriction on the risky workflow. C is the least bad option, and each element maps to an article: Section Headers Do Not Enforce Scope — Path Rules Do, Three Fields That Turn a Prompt Into a Safe Workflow, and the Domain 2 piece on ${ENV_VAR} expansion.

Common traps in Domain 3 questions

• Believing a section header scopes rules. ”## Backend rules” in a root file still loads for frontend edits. Only paths and directories scope.
• Choosing a skill for everything. context: fork adds latency; a two-second /lint should be a plain command.
• Confusing user-level and project-level skills. Personal variants live in ~/.claude/skills/ and should be named differently to avoid shadowing (Personal Skills Live in ~/.claude/skills/).
• Planning by file count. A one-file change in unfamiliar code may need plan mode; a twenty-file mechanical rename may not.
• Describing instead of showing. When output format matters, a concrete example beats a paragraph, and writing tests first converges faster (Tests First: 3 Iterations to 15/15). Ask clarifying questions before large tasks (Three Rounds of Rework Because Nobody Asked About Deployment Topology).
• Assuming CI inherits your local context. It only has the repo, so CLAUDE.md must carry the standards (CLAUDE.md Is Your CI Agent’s Only Source of Project Standards).
• Picking a fictional flag. If an option names an environment variable or flag you have never seen in the docs, it is probably the distractor.

Next step

Read the six anchor articles, open a real repo and create the files as you go (a root CLAUDE.md, one scoped rules file, one skill with allowed-tools), then run the Domain 3 practice questions. When you are steady there, take the free CCA-F mock exam. The complete list is on the Domain 3 study guide page, and the study-order companion is CCA Study Tips for Domain 3.