CCA Domain 3: Claude Code Study Guide

What Does CCA Domain 3 Cover?

The Claude Certified Architect exam launched on March 12, 2026. It's a 60-question, 120-minute proctored exam spread across five domains. Domain 3 — Claude Code — carries approximately 20% of the total exam weight, making it one of the most heavily tested areas alongside the API and Application Architecture domain.

Domain 3 is not a surface-level product overview. The exam tests your ability to architect Claude Code deployments in real enterprise environments — understanding how CLAUDE.md files cascade across repositories, how hooks intercept and modify agentic behaviour, how skills package reusable AI workflows, and how sub-agents handle task delegation. If you've only read the documentation but haven't shipped a Claude Code deployment, this domain will challenge you.

Our team at ClaudeImplementation.com has passed the CCA exam and runs the CCA Certification Prep programme. The breakdown below is based on our direct experience with the exam and the deployment patterns it tests.

Claude Code Architecture — What the Exam Tests

Before you can answer Domain 3 questions correctly, you need a clear mental model of how Claude Code actually works. The exam distinguishes between candidates who understand the architecture and those who've only used the surface-level interface.

The Execution Model

Claude Code runs as a terminal-based agentic coding tool. Unlike a simple chat interface, it maintains an agentic loop — meaning it can execute tools, read files, run bash commands, write code, and iterate on errors without waiting for explicit human instruction at each step. The model operates with access to your local filesystem (within defined boundaries) and can call external tools via MCP servers.

The key architectural distinction the exam tests is the difference between local tools (bash, read, write, edit, grep, glob — built-in capabilities), MCP servers (external tool providers declared in configuration), and skills (pre-packaged reusable instruction sets). Confusing these three will cost you marks. If you want to go deeper on MCP integration within Claude Code, our Claude Code MCP Servers guide covers the full pattern.

Context and Memory

Claude Code operates within a single context window per session. It does not have persistent memory across sessions by default — but CLAUDE.md files serve as a form of persistent, structured instruction that loads at session start. The exam will test your understanding of what persists (CLAUDE.md instructions, project state), what's ephemeral (conversation context, tool call results), and how large codebases should be broken up using sub-agents to avoid context exhaustion.

The /init Command

Running /init in a new project prompts Claude Code to analyse the codebase and generate a starter CLAUDE.md. The exam may ask what this command does, what the resulting file should contain, and how it differs from a manually authored CLAUDE.md. The answer: /init creates a descriptive file, not a governance file — human review and hardening is always required before enterprise deployment.

Mastering CLAUDE.md: The Configuration File That Controls Everything

CLAUDE.md is Claude Code's primary configuration mechanism. The CCA exam dedicates substantial coverage to it because getting CLAUDE.md wrong is the most common way enterprise deployments fail. Badly written CLAUDE.md files cause inconsistent behaviour, security gaps, and developer frustration.

The Three-Level Hierarchy

This hierarchy is almost certain to appear on the exam. Claude Code loads CLAUDE.md files from three distinct locations, each with a specific scope:

• Global (~/.claude/CLAUDE.md): Applies to all Claude Code sessions for this user on this machine. Used for personal preferences, global style rules, and user-level tool permissions.
• Project root (./CLAUDE.md): Applies to the entire repository. Used for project-specific architecture rules, tech stack instructions, approved library lists, and team coding standards.
• Subdirectory (./src/CLAUDE.md, etc.): Applies only when Claude Code is working in that subdirectory. Used for module-specific rules — e.g., a different test framework in the backend vs. frontend.

All three levels load simultaneously and are combined. Where instructions conflict, the more specific (lower-level) file takes precedence. The exam may present scenarios and ask which CLAUDE.md rule applies.

What Goes in CLAUDE.md

# Project: Payment Processing Service
# Environment: Node.js 20 / TypeScript / PostgreSQL

## Architecture Rules
- All database queries must go through the QueryBuilder abstraction
- Never write raw SQL strings — use parameterised queries only
- Payment amounts stored as integers (pence/cents), never floats

## Testing
- Every new function requires a unit test in the adjacent *.test.ts file
- Use Vitest, not Jest
- Minimum 80% coverage on payment-critical modules

## Security
- Never log card numbers, CVV, or full PAN data
- All API endpoints must validate JWT before accessing resources
- Secrets loaded from environment variables only — never hardcoded

## Bash Commands
- Run tests: npm run test
- Build: npm run build
- Lint: npm run lint --fix

## MCP Servers
- postgres: connect to dev database
- stripe-mcp: Stripe API integration (read-only in dev)

The exam tests whether you know what makes a CLAUDE.md effective. Security rules, tool constraints, coding standards, and environment context are all appropriate. Vague aspirational statements ("write clean code") are not — Claude Code ignores them in favour of specific, actionable instructions. Our detailed CLAUDE.md configuration guide covers this in depth.

Claude Code Hooks — Event-Driven Workflow Control

Hooks are one of the most powerful and most tested features in Domain 3. They allow you to intercept Claude Code's agentic loop at specific points and execute custom shell scripts — enabling validation, logging, security enforcement, and workflow automation without modifying Claude Code itself.

The Five Hook Events

Hooks are configured in .claude/settings.json (or settings.local.json for user-specific hooks that shouldn't be committed). Each hook specifies a matcher (which tool or tool pattern triggers it) and a command (the shell script to run).

{
  "hooks": {
    "PreToolCall": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "python /hooks/validate_bash.py"
          }
        ]
      }
    ],
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "npm run test && npm run lint"
          }
        ]
      }
    ]
  }
}

The exam will test scenarios where you must select the correct hook event. If you need to prevent a dangerous file deletion before it happens, that's PreToolCall. If you need to run tests every time Claude Code finishes a task, that's Stop. If you need to validate what a sub-agent produced before the orchestrating agent uses it, that's SubagentStop. Get these distinctions right. Our Claude Code Hooks deep-dive has worked examples for all five events.

Claude Code Skills — Reusable AI Workflow Packages

Skills are packaged instruction sets that Claude Code loads on demand. Think of them as reusable procedures: a "weekly-report" skill, a "deploy-to-staging" skill, a "code-review" skill. Users trigger them via the / command, and Claude Code follows the skill's SKILL.md instructions to execute the workflow.

Skill Structure

Every skill lives in a named directory under .claude/skills/ (for project skills) or ~/.claude/skills/ (for user-level skills). The directory must contain a SKILL.md file that describes the skill's purpose, required inputs, steps, and expected outputs. Supporting files — scripts, templates, reference data — can be placed in the same directory and referenced from SKILL.md.

.claude/
  skills/
    code-review/
      SKILL.md         ← Skill instructions
      checklist.md     ← Reference checklist Claude reads
      report-template.md ← Output template
    deploy-staging/
      SKILL.md
      deploy.sh        ← Script Claude can execute

The exam tests skill discovery (how Claude Code finds skills), skill activation (the slash command), skill scoping (project vs. global), and skill content (what makes a SKILL.md effective vs. vague). Skills can also be distributed as plugins — a topic that appears in Domain 3 questions related to enterprise-wide skill deployment. For a complete implementation walkthrough, see our Claude Code Skills guide.

Sub-Agents and Multi-Agent Architecture in Claude Code

Sub-agents are one of the most architecturally significant features in Claude Code — and one of the most tested in Domain 3. When Claude Code spawns a sub-agent, it creates a child instance with its own isolated context window, assigned a specific task, and returns only the result to the parent. This solves the context exhaustion problem that plagues large codebase work.

When Claude Code Uses Sub-Agents

Claude Code spawns sub-agents using the built-in Task tool. Sub-agents are used when: the task requires searching multiple areas of a large codebase simultaneously, the total work would exceed a single context window, tasks can be decomposed into independent parallel workstreams, or different parts of a task require specialised instructions. The orchestrating agent retains a high-level view and assembles the results.

Context Isolation

Each sub-agent starts with a fresh context. It receives a task description and any specific instructions from the parent agent, but it does not inherit the parent's conversation history. This is intentional — it prevents context contamination and keeps each agent focused. The exam may present questions about what a sub-agent can and cannot access, and how the parent should structure the task handoff to avoid information loss.

Orchestration Patterns

The exam tests two primary orchestration patterns. In the parallel pattern, the orchestrator spawns multiple sub-agents simultaneously for independent tasks (e.g., reviewing five separate modules in parallel), then aggregates results. In the sequential pattern, sub-agent outputs feed into subsequent sub-agents (e.g., a research agent produces a report, an analysis agent interprets it, a writer agent drafts the output). Understanding when to use each and how to structure the hand-off instructions is Domain 3 material. Our guide on Claude Code Sub-Agents has concrete examples of both patterns.

MCP Integration Within Claude Code

Model Context Protocol integration is covered in depth in Domain 2, but Domain 3 tests how MCP servers are specifically configured and used within a Claude Code context — which has its own configuration layer distinct from the Claude API or Claude Cowork.

MCP servers for Claude Code are declared in .claude/settings.json under the mcpServers key, or in a user-level ~/.claude/settings.json. Each server specifies a transport type (stdio or sse), a command to start the server, arguments, and environment variables. Claude Code automatically starts and stops MCP servers as needed during a session.

{
  "mcpServers": {
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": {
        "POSTGRES_CONNECTION_STRING": "${DATABASE_URL}"
      }
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_TOKEN": "${GITHUB_TOKEN}"
      }
    }
  }
}

Key exam distinctions: the difference between stdio (local process, lower latency) and sse (remote server, network required) transports; how to use environment variable substitution securely; the permission model for MCP tools (MCP tools require explicit user approval unless pre-approved in settings); and how MCP tools appear alongside built-in tools in Claude Code's tool list. For production-grade patterns, our MCP Server Development service covers the full implementation stack.

Enterprise Governance and Security Controls

The final portion of Domain 3 covers the administrative and governance layer that large organisations need before they can safely deploy Claude Code to thousands of developers. While this sub-domain carries less weight than the technical areas, getting it wrong on the exam is a red flag for any enterprise architect.

Permission Levels

Claude Code has three layers of permission control. Tool-level permissions control which tools Claude Code can use in a given context — you can restrict bash execution, file writes, or MCP tool access entirely. Directory-level permissions use the allowedDirectories setting to sandbox Claude Code to specific paths. Enterprise policy at the organisation level sets baseline rules that override individual CLAUDE.md files — important for compliance in regulated industries.

Audit and Observability

Enterprise deployments need to know what Claude Code did. Hooks are the primary mechanism for audit logging — a PostToolCall hook can record every tool invocation with its inputs and outputs to a central log store. The exam may ask you to design an audit architecture using hooks, or to identify what information is captured vs. lost at each point in the agentic loop.

For organisations in regulated sectors, our Claude Security & Governance service builds the full governance framework — policy templates, audit pipelines, access controls, and compliance documentation. For an enterprise-grade Claude Code deployment, see our Claude Code Enterprise service.

Domain 3 Practice Questions

These questions reflect the style and difficulty level of actual CCA exam questions. Work through them before looking at the answers.

Question 1

A developer's personal CLAUDE.md defines a coding style preference. The project root CLAUDE.md defines a different style standard. The team's subdirectory CLAUDE.md says nothing about style. Which rule applies when Claude Code is working in that subdirectory?

Answer: The project root CLAUDE.md style rule applies. The subdirectory file is silent on style, so it doesn't override the project level. The project root takes precedence over the global (personal) file. The more specific file wins only when it explicitly addresses the same instruction.

Question 2

You want to prevent Claude Code from executing any bash command that contains "rm -rf". Which hook event and approach do you use?

Answer: PreToolCall with a matcher for Bash. Your hook script inspects the tool_input JSON passed via stdin. If the command contains rm -rf, the script exits with a non-zero code and prints a block message to stderr, which Claude Code treats as a tool use rejection.

Question 3

A sub-agent spawned by the orchestrating Claude Code agent fails to complete its task. What happens to the parent agent?

Answer: The parent agent receives the failure result from the Task tool and can decide how to proceed — retry with different instructions, attempt the task itself, or report the failure to the user. Sub-agent failures are non-fatal to the parent by design. The parent's context is not polluted by the sub-agent's failed attempt.

For 50 full practice questions across all five CCA domains, see our CCA Practice Questions guide.

Related Articles