CClaudeMentor
All articles
Architect
15 min read

CCA Domain 3 Study Guide: Claude Code Configuration and Workflows

Research-verified study guide for Domain 3 — choosing the right control, CLAUDE.md and rule scope, settings, permissions and hooks, skills and subagents, plan mode, CI/CD workflows, scenario traps, and a seven-day plan.

Purpose and accuracy note

This guide replaces generic API advice with the Claude Code decisions an architect is likely to make: where instructions belong, how settings and permissions are scoped, when to use plan mode, and how to make workflows repeatable and safe. Anthropic’s public certification announcement confirms a technical certification exam, but it does not publish domain percentages. Treat any unofficial weighting as provisional and follow the current candidate guide or partner portal if one is supplied to you.

1. The exam lens: choose the right control

Most scenario questions become easier when you classify the requirement first:

  • Persistent guidance for Claude: CLAUDE.md or a scoped rule.
  • Enforced behavior: settings, permissions, managed policy, or a hook.
  • Reusable user-invoked workflow: a skill.
  • Deterministic lifecycle automation: a hook.
  • Delegated work with isolated instructions/tools: a subagent.
  • External data or actions: MCP server or another tool integration.
  • Review before changes: plan mode.

The most common mistake is putting every requirement in CLAUDE.md. That file supplies context; it is not an enforcement boundary. “Never edit production secrets” is useful guidance, but an organization that must prevent the action should also deny the relevant operations or use a PreToolUse hook.

2. Instruction files and scope

CLAUDE.md is loaded as project context at session start. Put stable, project-specific facts there: build and test commands, architecture boundaries, naming conventions, repository layout, and non-obvious review rules. Keep it concise and concrete. Anthropic recommends specific instructions and suggests keeping each file under roughly 200 lines because bloated guidance reduces adherence.

Know the hierarchy:

  • Managed policy: organization-controlled instructions or settings.
  • User scope: personal defaults that apply across projects.
  • Project scope: files committed for the team.
  • Local scope: machine- or developer-specific settings that should not be shared.
  • Nested CLAUDE.md files: instructions for a subtree.
  • .claude/rules/: modular rules, optionally limited to file patterns.

Use the narrowest scope that matches the requirement. A Python testing rule for src/payments/** belongs in a path-scoped rule, not in a global personal file. A team-wide command belongs in a committed project file. A developer’s local sandbox URL belongs in local settings.

Useful diagnostics:

  • /init creates a starting CLAUDE.md from the repository.
  • /status shows active configuration and context.
  • /doctor checks installation and configuration problems.
  • /compact reduces accumulated conversation context.
  • /clear starts a clean conversation when the current history is no longer useful.

3. Settings, permissions, and security

Claude Code settings are layered. More specific or centrally managed scopes can override other values. For an exam scenario, distinguish preference from policy:

  • Preference: output style, personal defaults, convenience settings.
  • Project behavior: shared permissions and hooks committed with the repository.
  • Organization policy: managed settings that users cannot weaken.

Permission decisions commonly resolve to allow, ask, or deny. Favor least privilege: grant only the tools and command patterns needed for the workflow. A broad allow rule such as unrestricted shell access is rarely the best architecture for a sensitive repository.

Secrets do not belong in CLAUDE.md, prompts, committed settings, tool descriptions, or logs. Use the platform’s credential flow, environment injection, or an approved secret manager. Protect .env files and credentials through permissions as well as repository hygiene.

Hooks are deterministic controls around lifecycle events. A PreToolUse hook can approve, deny, ask, or defer before a tool runs. A PostToolUse hook can format, validate, record, or add context after an action. Choose a hook when the requirement says “always run,” “must block,” or “must record.” Choose a prompt instruction when judgment is required.

4. Workflow primitives

Plan mode is the right default for an unfamiliar repository, high-impact refactor, or task requiring approval before disk changes. It allows investigation and a proposed approach without immediately editing files. Direct execution is appropriate for small, well-scoped, reversible work when the user has already authorized the change.

Skills package repeatable workflows in a SKILL.md file. Use them for tasks such as release preparation, dependency review, or a company-specific code-review procedure. A good skill states when it applies, its sequence, required checks, and expected output. It should not carry secrets.

Subagents are useful when a bounded task benefits from its own prompt, tool restrictions, permissions, hooks, or skills. Delegate independent research, a targeted code review, or tests for one subsystem. Do not delegate merely to add complexity. The parent remains responsible for integrating and verifying results.

MCP connects Claude Code to external services and data. Prefer a maintained server when it already meets the need and security requirements. Build a custom server when the integration, authorization model, or business semantics are unique.

Plugins bundle related extensions for distribution. Think of a plugin as packaging; skills, hooks, subagents, and MCP servers remain the functional building blocks.

5. Sessions, parallel work, and automation

Resume a session when its history is still relevant. Fork a session when you want a new branch of work without modifying the original trajectory. Use a worktree for truly parallel code changes so agents or developers do not collide in the same checkout.

For command-line automation, prefer non-interactive invocation and machine-readable output. JSON output and a JSON schema make CI integration more reliable than scraping prose. Apply explicit permission constraints, capture exit status, set timeouts, and archive enough diagnostics to reproduce failures.

Do not confuse conversation continuity with durable project knowledge. A resumed session retains useful history; CLAUDE.md, rules, source files, and issue trackers preserve facts that future sessions must know.

6. High-frequency scenario traps

  • “Put it in CLAUDE.md” for a mandatory prohibition. Guidance is not enforcement; use permissions or hooks.
  • Putting API temperature advice in Claude Code configuration. Claude Code workflows are governed by its supported settings and model controls, not an invented temperature rubric.
  • One enormous root CLAUDE.md. Split stable guidance by scope and path.
  • Committing personal paths or secrets. Use local scope and secret management.
  • A hook for a task requiring nuanced judgment. Hooks are strongest for deterministic checks; let Claude reason where interpretation is necessary.
  • A skill for an automatic event. Skills express workflows; hooks react to lifecycle events.
  • Editing immediately in a high-risk repository. Start in plan mode and obtain approval.
  • Parallel agents in one working tree. Use separate worktrees or clearly separated file ownership.
  • Resuming a polluted session forever. Compact or clear when irrelevant history harms focus.
  • Parsing terminal prose in CI. Request structured output and validate it.
  • Granting broad shell permissions to avoid prompts. Narrow permission patterns are safer.
  • Treating /doctor as a design tool. It diagnoses environment/configuration issues; it does not replace architecture review.

7. Rapid decision framework

Ask these questions in order:

  • Is the requirement advice, reusable procedure, automatic event, or hard control?
  • Who should receive it: one user, one project, one directory, or the organization?
  • Is the action reversible and already authorized?
  • Does it need external data or side effects?
  • Must humans review before execution?
  • How will the result be verified and reproduced?

A strong exam answer usually selects the smallest mechanism that satisfies the requirement and makes enforcement explicit.

8. Seven-day revision plan

  • Day 1: Build a sample repository with root and nested CLAUDE.md files. Explain which rule wins and why.
  • Day 2: Practice settings scopes, allow/ask/deny permissions, secret handling, /status, and /doctor.
  • Day 3: Write one skill and one PreToolUse hook. Compare their purposes.
  • Day 4: Run the same refactor in plan mode and direct mode; document the authorization difference.
  • Day 5: Practice resume, fork, compact, clear, and worktrees.
  • Day 6: Design a CI command with structured output, schema validation, timeouts, and least privilege.
  • Day 7: Solve 20 scenario questions and justify each choice in one sentence.

Final checklist

  • I can distinguish CLAUDE.md guidance from enforced configuration.
  • I can choose user, project, local, managed, nested, or path scope.
  • I know when to use a skill, hook, subagent, plugin, or MCP server.
  • I can explain plan mode, resume, fork, compact, clear, and worktrees.
  • I can design a least-privilege automated workflow with structured output.
  • I can diagnose active configuration with /status and /doctor.

Official sources

Take the diagnosticBuild a study plan

Keep reading