Claude Code Skills Guide: Master Domain 3 for CCA-F

Domain 3 of the CCA-F exam, Claude Code Configuration and Workflows, carries a 20% weight, making it one of the two heaviest domains alongside Prompt Engineering. This claude code skills guide maps every skill the exam tests in that domain, explains the underlying mechanics, and shows you how those mechanics connect to the four other domains you will also be scored on. Per Anthropic's exam guide, the exam contains 60 scenario-based questions scored on a 100-to-1000 scale, with 720 as the passing mark.

We have structured this guide around the questions candidates actually get wrong, not a flat recitation of features.

What configuration hierarchy does Claude Code enforce, and why does it matter for the exam?

Claude Code uses a three-level configuration hierarchy: system-level settings, project-level CLAUDE.md files, and user-level personal customisations. Each level can override or extend the one above it, but the rules of precedence are strict. Exam scenarios frequently present a conflict between a project-level instruction and a user-level preference and ask which takes effect.

The practical rule: project-level CLAUDE.md files govern shared, version-controlled behaviour; user-level settings govern personal workflow preferences that should not be committed to source control. The exam rewards candidates who can identify which layer is the correct intervention point for a given problem.

Understanding version control implications is not optional: the exam has tested scenarios where a candidate must decide whether a new rule belongs in the committed CLAUDE.md or in a personal config file that stays off the repository.

How does Plan Mode change the way Claude approaches a task?

Plan Mode (activated in the Claude Code interface before execution begins) instructs Claude to produce a structured plan and wait for human approval before writing or modifying any code. This is the correct pattern whenever the task path is not predefined: complex refactoring, tech-spec drafting, security audits, or any migration where an incorrect first step is expensive to reverse.

The exam consistently rewards deterministic solutions over probabilistic ones when stakes are high. Plan Mode is the canonical example of that principle in Domain 3. A scenario that presents a senior engineer beginning a multi-service database migration should route to Plan Mode, not direct execution.

What Plan Mode is not: a universal default. For well-understood, low-risk tasks such as adding a unit test to an already-tested module, direct execution is faster and equally safe. The exam will present both cases; the skill is knowing which is which.

What is the role of CLAUDE.md in scaling skills across a team?

A CLAUDE.md file at the repository root is the primary mechanism for persisting workflow behaviour across team members and CI runs. It can encode coding conventions, tool-use permissions, context about the codebase architecture, and references to external documentation. Because it is version-controlled, every team member and every CI agent reads the same instructions.

The exam tests two failure modes here:

1. Over-specification: a CLAUDE.md so long that Claude's attention is diluted across hundreds of rules, degrading the quality of responses to any individual rule. This connects directly to the attention dilution problem covered in Domain 1.
2. Under-specification: a CLAUDE.md that omits critical context, forcing Claude to infer conventions it should have been told explicitly.

The correct posture is a concise, high-signal CLAUDE.md that states the most consequential constraints and links out to longer reference documents rather than inlining them.

For teams running Claude Code in CI pipelines, the non-interactive -p flag is the standard invocation pattern. It allows a scripted prompt to be passed directly without requiring a human at the terminal.

# Run Claude Code non-interactively in CI
claude -p "Run the full test suite and report failures as structured JSON" \
  --output-format json

The output format flag matters for downstream parsing. Exam scenarios that involve CI integration almost always require structured output, not free-form prose.

How do dynamic workflows differ from fixed sequential pipelines?

Fixed sequential pipelines execute a predetermined chain of steps in order. They are appropriate when the task structure is fully known in advance and each step's output is a well-defined input to the next. They are fast, auditable, and easy to test.

Dynamic adaptive decomposition is the alternative: Claude decides at runtime which sub-tasks to spawn, in what order, and with what inputs, based on what it discovers as it works. This is the correct pattern for debugging an unfamiliar codebase where the path is not predefined, or for a security audit where the scope of findings determines the next investigative step.

The exam does not reward a preference for one pattern over the other. It rewards the ability to match the pattern to the scenario. A question presenting a well-specified ETL pipeline should route to a fixed sequential pipeline. A question presenting an open-ended legacy codebase investigation should route to dynamic decomposition.

How should sub-agents be scoped when humans must stay in the loop?

When a workflow involves two to five sub-agents operating in parallel, the coordinator must define explicit human-in-the-loop checkpoints. The exam tests this in Domain 1 (Agentic Architecture) but the configuration of those checkpoints lives in Domain 3 skills: specifically, how CLAUDE.md and tool permissions constrain what sub-agents can do without approval.

The principle is subagent context isolation: each sub-agent should receive only the context it needs for its specific task, not the full conversation history of the coordinator. This keeps token usage proportionate and prevents one sub-agent's verbose output from polluting another's context window.

For high-stakes operations such as production deployments or security remediations, the correct pattern is a structured handoff to human agents before any irreversible action. The exam will present scenarios where a sub-agent has completed its analysis and the question is whether it should act autonomously or surface a structured summary for human review. The answer is almost always the latter when the action is irreversible.

{
  "handoff_type": "human_review_required",
  "sub_agent": "security-audit-agent",
  "findings_count": 7,
  "critical_count": 2,
  "recommended_action": "Review critical findings before remediation proceeds",
  "findings_summary_path": "audit/findings-2026-06-11.json"
}

How does MCP integration interact with Claude Code configuration?

The Model Context Protocol (MCP) extends Claude Code's tool surface by connecting external servers that expose resources, tools, and prompts. From a Domain 3 perspective, the configuration skill is knowing where MCP server definitions live in the hierarchy and how scoping affects which agents can call which tools.

MCP server configuration can be scoped at the project level (shared across the team) or at the user level (personal). The MCP scoping hierarchy determines which tools are visible to Claude in a given session. A common exam trap: a candidate assumes an MCP tool is available to a sub-agent because it is defined globally, but the sub-agent's session was initialised with a narrower scope.

Environment variable expansion in MCP config is a related skill. Credentials should never be hardcoded in a committed config file; they should be referenced as environment variables that are injected at runtime. The exam has tested scenarios where a team's MCP config is committed to source control with a literal API key, and the question asks for the correct remediation.

{
  "mcpServers": {
    "data-warehouse": {
      "command": "npx",
      "args": ["-y", "@company/mcp-warehouse"],
      "env": {
        "WAREHOUSE_API_KEY": "${WAREHOUSE_API_KEY}",
        "WAREHOUSE_REGION": "${WAREHOUSE_REGION}"
      }
    }
  }
}

The ${} expansion syntax ensures the key is read from the runtime environment, not stored in the file. This is the pattern the exam expects.

How do hooks enforce compliance without relying on prompt instructions alone?

Hooks are programmatic intercepts that run before or after tool calls. They are the correct mechanism when a compliance requirement must be enforced deterministically, not probabilistically. The hooks vs prompts decision framework is a Domain 1 concept, but the implementation of hooks is a Domain 3 skill.

A PostToolUse hook, for example, can normalise the output of every file-write operation to ensure it meets a formatting standard, regardless of what Claude produced. This is more reliable than a prompt instruction that says "always format output as X" because it cannot be overridden by a downstream instruction or forgotten in a long context window.

The exam distinguishes between three enforcement mechanisms: prompt instructions (lowest reliability, highest flexibility), tool-level constraints (medium reliability), and hooks (highest reliability, lowest flexibility). Matching the mechanism to the stakes of the requirement is the tested skill.

What does the exam actually test in Domain 3 scenarios?

Across the five domains, Domain 3 questions tend to present a realistic engineering situation and ask which configuration change, workflow pattern, or tool invocation resolves it. The distractors are usually plausible but wrong in a specific, instructive way.

Common distractor patterns we have observed in practice questions:

• Choosing a dynamic workflow when a fixed pipeline would be more auditable and equally effective
• Placing a team-wide rule in a personal config file instead of CLAUDE.md
• Using a prompt instruction to enforce a compliance requirement that should be a hook
• Hardcoding credentials in an MCP config instead of using environment variable expansion
• Spawning sub-agents without defining human-in-the-loop checkpoints for irreversible actions

The Claude Code Configuration and Workflows concept library on our platform covers 174 atomic concepts mapped to all five domains. If you are scoring below 720 on practice exams, the adaptive engine will surface the specific concepts driving your gap rather than asking you to re-read everything.

As of 3 June 2026, more than 10,000 individuals have passed the CCA-F. The exam launched on 12 March 2026 at $99 per attempt, and Anthropic has announced further certifications planned for later in 2026. Getting Domain 3 right is not just an exam strategy; the configuration and workflow skills it tests are the ones production teams reach for every day.