Jonathon's AI Wiki

CCA-F Study Guide

15 min read

Source: ai-research (web research, 2026-04-11), raw/instructor-8lsy243ftffjjy1cx9lm3o2bw-public-1773274827-Claude+Certified+Architect+–+Foundations+Certification+Exam+Guide.pdf, raw/guide_en.MD

A practical study guide for the Claude Certified Architect — Foundations (CCA-F) exam. Organized by the 5 exam domains in recommended study order, with the key principles, patterns, and tradeoffs you need to internalize. This guide synthesizes the official exam guide, the Architect’s Playbook, community prep materials, and architectural patterns that recur across exam questions. For the complete task-by-task breakdown, see the Official Exam Guide.

Study the highest-weighted domains first, but do not skip any — the exam draws from all five:

  1. Agentic Architecture (27%) — largest weight, most complex
  2. Tool Design & MCP Integration (18%) — tightly coupled with agentic patterns
  3. Prompt Engineering & Structured Output (20%) — foundational for everything else
  4. Claude Code Configuration (20%) — practical setup knowledge
  5. Context & Reliability (15%) — smallest weight but tests subtle production issues

The reason to study Tool Design before Prompt Engineering: agentic systems depend on well-designed tools, so understanding tool patterns first makes the prompt engineering domain easier to absorb.

Domain 1: Agentic Architecture (27%)

This is the make-or-break domain. Anthropic weights it highest because agentic failures are the costliest in production. The official exam guide defines 7 task statements for this domain.

Official Task Statements

  • Task 1.1: Design and implement agentic loops (stop_reason = "tool_use" vs "end_turn", tool results in conversation, anti-patterns like NL parsing for termination)
  • Task 1.2: Orchestrate coordinator-subagent patterns (hub-and-spoke, isolated context, risks of overly narrow decomposition)
  • Task 1.3: Configure subagent invocation (Task tool, allowedTools, AgentDefinition, fork_session, context must be explicitly passed)
  • Task 1.4: Implement multi-step workflows (programmatic prerequisites vs prompt guidance, structured handoff summaries)
  • Task 1.5: Apply Agent SDK hooks (PostToolUse for transformation/compliance, deterministic hooks vs probabilistic prompts)
  • Task 1.6: Design task decomposition (fixed pipelines vs dynamic adaptive, prompt chaining for predictable tasks, dynamic for open-ended)
  • Task 1.7: Manage session state (--resume, fork_session, starting fresh with summaries vs resuming with stale context)

See Official Exam Guide for complete knowledge/skill items for each task.

What to know

  • Subagent spawning patterns — when to use parallel workers vs. sequential chains vs. orchestrator patterns. Understand the tradeoffs: parallel is faster but harder to coordinate; sequential is simpler but slower
  • Workflow decomposition — how to break a complex task into subtasks that can be independently completed. Know when decomposition adds value vs. when it introduces unnecessary overhead
  • Tool selection and decision complexity — an agent with 50 tools performs worse than one with 5 well-chosen tools. Dynamic scoping (giving an agent only the tools relevant to its current subtask) is a key pattern
  • Fallback loop design — what happens when an agent step fails? Design for graceful degradation, not silent failure. Know the difference between retry, fallback to alternate tool, and escalation to human
  • Cost management — Batch API for non-urgent work at 50% discount; real-time API for latency-sensitive paths. Know when each is appropriate
  • Hooks for compliance — PostToolUse hooks provide deterministic enforcement; prompts are probabilistic. The Playbook shows that even emphatic prompts (“CRITICAL POLICY: NEVER”) fail ~3% of the time

Key tradeoffs to understand

  • Autonomy vs. control: more autonomous agents are more capable but harder to debug
  • Parallelism vs. coordination: parallel subagents are faster but may produce conflicting outputs
  • Tool breadth vs. precision: more tools increase capability but decrease reliability
  • Cost vs. latency: Batch API is cheaper but slower; real-time is immediate but expensive

Hands-on practice

Run these cookbooks: customer_service_agent.ipynb, orchestrator_workers.ipynb, basic_workflows.ipynb, evaluator_optimizer.ipynb

Domain 2: Tool Design & MCP Integration (18%)

Tools are how agents interact with the world. Poorly designed tools are the #1 cause of agent failures after bad prompts. The official exam guide defines 5 task statements for this domain.

Official Task Statements

  • Task 2.1: Design effective tool interfaces (descriptions are the primary selection mechanism, ambiguous descriptions cause misrouting, keyword-sensitive system prompts)
  • Task 2.2: Implement structured errors (isError flag, transient/validation/business/permission categories, errorCategory + isRetryable + human description)
  • Task 2.3: Distribute tools across agents (too many tools degrades reliability — 18 instead of 4-5, scoped access, tool_choice auto/any/forced)
  • Task 2.4: Integrate MCP servers (.mcp.json project-level vs ~/.claude.json user-level, env variable expansion, MCP resources as content catalogs)
  • Task 2.5: Apply built-in tools effectively (Grep for content search, Glob for file patterns, Read/Write/Edit, Edit fails on non-unique matches → Read+Write fallback)

See Official Exam Guide for complete knowledge/skill items for each task.

What to know

  • JSON schema for semantic validation — use schema constraints to prevent invalid inputs before they reach your backend. Enums, pattern matching, and required fields are your first line of defense
  • Enum constraints for ambiguous inputs — when a field could be interpreted multiple ways, constrain it to an enum. status: enum["active", "inactive", "pending"] not status: string
  • Machine-readable identifiers — always use IDs, never natural language names, in tool parameters. customer_id: "cust_abc123" not customer: "Acme Corp"
  • Lookup/action tool pairs — instead of one tool that takes a name and performs an action, split into: (1) a lookup tool that returns matching IDs, and (2) an action tool that operates on an ID. This eliminates ambiguity
  • Pagination — never return all results. Return a page with metadata (total count, next cursor, has_more). Agents need to know they have not seen everything
  • Error handling — tools should return structured error objects, not raw error strings. Include error code, message, and suggested recovery action. The Playbook shows the correct pattern: return error in tool result with isError: true, errorCategory, and isRetryable — never throw exceptions or return empty strings
  • Tool chaining reliability — when tool B depends on tool A’s output, validate A’s output before passing it to B. Do not assume success
  • MCP tool specificity — the Playbook warns that agents default to built-in tools (Grep) over broad custom tools. Split monolithic tools into granular single-purpose tools with detailed descriptions

Key patterns

  • Normalize before presenting — if your agent calls 3 different external APIs that return data in different formats, normalize the responses into a consistent schema before the agent sees them
  • Dual-field validation — have the model output both the result and a confidence/verification field. If they disagree, trigger review
  • Idempotent tools — design tools so calling them twice with the same input produces the same result. This makes retry logic safe

Hands-on practice

Run these cookbooks: calculator_tool.ipynb, tool_choice.ipynb, parallel_tools.ipynb, programmatic_tool_calling_ptc.ipynb

Domain 3: Prompt Engineering & Structured Output (20%)

The exam tests prompt engineering as an architectural tool, not a creative exercise. The focus is on reliability and structure. The official exam guide defines 6 task statements for this domain.

Official Task Statements

  • Task 4.1: Design prompts with explicit criteria (vague instructions fail, explicit criteria > “be conservative”, categorical > confidence-based filtering)
  • Task 4.2: Apply few-shot prompting (most effective for consistent formatting, demonstrate ambiguous cases with reasoning, show varied document structures)
  • Task 4.3: Enforce structured output via tool_use (JSON schemas, tool_choice auto/any/forced, schemas prevent syntax but not semantic errors, optional/nullable fields prevent fabrication)
  • Task 4.4: Implement validation/retry loops (append specific errors on retry, retries ineffective for missing info, detected_pattern fields for analysis)
  • Task 4.5: Design batch processing strategies (Message Batches API 50% savings, 24hr window, no multi-turn tool calls in batch, custom_id for correlation)
  • Task 4.6: Design multi-instance review (self-review limitations, independent instances more effective, per-file + cross-file integration passes)

See Official Exam Guide for complete knowledge/skill items for each task.

What to know

  • Structured output schemas — define the exact JSON structure you expect. This is not optional for production systems; it prevents hallucinated fields and missing data
  • JSON schema to prevent hallucinations — when the model must choose from known options, use enum constraints in the output schema. The model cannot hallucinate a value that is not in the enum. Add "other" + detail string for extensible categories (the Playbook’s “Resilient Catch-All” pattern)
  • Prompt refinement methodology — the exam tests a specific principle: optimize the prompt before scaling. If your prompt works 80% of the time, fix the prompt before adding retry logic or fallback chains
  • Chain-of-thought vs. direct prompting — know when each is appropriate. CoT is better for complex reasoning; direct is better for simple extraction. CoT adds latency and cost
  • Self-correction patterns — have the model check its own output against the input constraints. The Playbook defines the schema redundancy pattern: extract calculated_total alongside stated_total to detect extraction errors
  • Limits of retry — the Playbook demonstrates that retries work for formatting errors but are useless for missing information. Know when to fail fast
  • Multi-instance review — self-review is limited because the model retains its reasoning context. Independent review instances without prior context are more effective

Key principle

The exam prioritizes structural/deterministic solutions over probabilistic ones. If you can enforce a constraint via JSON schema, that answer beats a prompt-based approach every time. Prompts are probabilistic; schemas are deterministic.

Hands-on practice

Run these cookbooks: extracting_structured_json.ipynb, batch_processing.ipynb, building_evals.ipynb, tool_choice.ipynb

Domain 4: Claude Code Configuration (20%)

Practical knowledge of how to set up and manage Claude Code for production use. The official exam guide defines 6 task statements for this domain.

Official Task Statements

  • Task 3.1: Configure CLAUDE.md hierarchy (user/project/directory levels, @import for modularity, .claude/rules/ for topic-specific)
  • Task 3.2: Create custom slash commands and skills (.claude/commands/ project-scoped, ~/.claude/commands/ personal, SKILL.md frontmatter with context: fork, allowed-tools, argument-hint)
  • Task 3.3: Apply path-specific rules (.claude/rules/ with YAML paths glob patterns for conditional loading)
  • Task 3.4: Determine plan mode vs direct execution (plan mode for complex/multi-file/architectural, direct for simple/clear-scope)
  • Task 3.5: Apply iterative refinement (concrete I/O examples, test-driven iteration, interview pattern, batching interacting vs sequential independent issues)
  • Task 3.6: Integrate into CI/CD (-p flag for non-interactive, --output-format json + --json-schema, session context isolation for independent review)

See Official Exam Guide for complete knowledge/skill items for each task.

What to know

  • CLAUDE.md configuration — how project-level instructions work, what goes in them, how they override defaults. The hierarchy is: user-level (~/.claude/CLAUDE.md), project-level (.claude/CLAUDE.md or root), directory-level (subdirectory files)
  • Permission and environment setup — tool permissions, allowed/denied commands, environment variables
  • Hook configuration — pre-commit hooks, automation triggers, quality gates
  • Model selection — when to use different Claude models (cost vs. capability tradeoffs)
  • Session management — how context persists across sessions, compaction behavior, context window limits. The Playbook covers the scratchpad pattern and dynamic environment resumption
  • Cost optimization — prompt caching, Batch API usage, token management
  • Path-specific rules — .claude/rules/ files with YAML frontmatter paths fields are more efficient than multiple directory-level CLAUDE.md files for cross-cutting conventions
  • CI/CD integration — the -p flag prevents interactive hangs; --output-format json + --json-schema produces machine-parseable output; session context isolation means independent review instances catch more issues

Key principle

Configuration should make the right thing easy and the wrong thing hard. Good CLAUDE.md files encode team conventions so the agent follows them automatically.

Hands-on practice

Examine the cookbooks repo’s own .claude/ directory structure: root CLAUDE.md, .claude/commands/, .claude/skills/, and .claude/agents/ for real-world examples

Domain 5: Context & Reliability (15%)

The smallest domain by weight but tests subtle issues that only show up in production. The official exam guide defines 6 task statements for this domain.

Official Task Statements

  • Task 5.1: Implement context preservation (progressive summarization risks, “lost in the middle”, tool result accumulation, case facts blocks)
  • Task 5.2: Design escalation patterns (customer request/policy gap/no progress triggers, immediate vs investigation-first, sentiment-based unreliable)
  • Task 5.3: Implement error propagation (structured error context, access failure vs empty results, suppress errors = anti-pattern)
  • Task 5.4: Navigate large codebases (context degradation, scratchpad files, subagent delegation, state exports for crash recovery, /compact)
  • Task 5.5: Design human review workflows (aggregate metrics mask field-level issues, stratified random sampling, field-level confidence scores)
  • Task 5.6: Maintain information provenance (claim-source mappings, conflicting sources annotated not arbitrarily selected, temporal data needs dates)

See Official Exam Guide for complete knowledge/skill items for each task.

What to know

  • “Lost in the middle” effect — models pay more attention to the beginning and end of their context window. Critical information placed in the middle gets lower attention. Know how to structure context to mitigate this
  • Context bloat prevention — every token in the context window costs money and reduces quality. Prune aggressively: summarize old messages, remove completed subtask details, never load an entire codebase. The Playbook defines the Tool Context Pruning pattern: application-side filters extract only relevant fields from verbose API responses
  • Data provenance — in multi-step agent workflows, track where each piece of information came from. Claim-source mappings are required. Conflicting sources must be annotated, not arbitrarily selected
  • Session resumption — when an agent resumes after a pause, the external world may have changed. The Playbook recommends filtering out previous tool_result messages on resumption, keeping only human/assistant turns to force re-fetching current data
  • Reliability patterns — retries with backoff, circuit breakers for flaky tools, health checks, graceful degradation
  • Escalation design — the Playbook shows two paths: immediate escalation for explicit human requests (honor immediately, do not ask for clarification) vs context-gathering for policy issues (call get_customer before escalating)
  • Human review calibration — aggregate metrics mask field-level issues. A 95% overall accuracy can hide 60% accuracy on a specific field. Analyze by document type AND field before reducing review

Key tradeoffs

  • Context size vs. quality: more context is not always better; irrelevant context degrades performance
  • Freshness vs. cost: re-fetching data ensures freshness but costs tokens; caching is cheaper but may be stale
  • Observability vs. overhead: logging everything aids debugging but adds latency and cost

Hands-on practice

Run these cookbooks: prompt_caching.ipynb, session_memory_compaction.ipynb, automatic-context-compaction.ipynb, using_citations.ipynb

Cross-Domain Principles

These principles apply across all 5 domains and are the most frequently tested concepts:

  1. Deterministic over probabilistic — if you can solve it with code/schema/rules, that beats a prompt-based solution
  2. Optimize before scaling — fix the prompt before adding retries; fix the tool before adding fallbacks
  3. Machine IDs over natural language — structured identifiers prevent ambiguity
  4. Paginate everything — never return unbounded result sets
  5. Normalize inputs — agents should see consistent data formats regardless of source
  6. Fail loudly — silent failures compound; structured error responses enable recovery
  7. Scope dynamically — give agents only the tools and context they need for the current step

Out-of-Scope Topics

The following are explicitly NOT on the CCA-F exam (per the study guide source). Use this to narrow your study focus:

  • Fine-tuning or training custom models
  • API authentication, billing, or account management
  • Detailed language/framework implementation (beyond tool/schema config)
  • Deploying or hosting MCP servers (infrastructure, networking)
  • Claude internals (architecture, training process, model weights)
  • Constitutional AI, RLHF, or safety training methodologies
  • Embedding models or vector database implementation details
  • Computer use, Vision, or Streaming API
  • Rate limiting, quotas, OAuth, API key rotation
  • Cloud-provider-specific configurations (AWS, GCP, Azure)
  • Performance benchmarks or model comparison metrics
  • Token counting algorithms or tokenization specifics

Study Tips from the Community

Based on patterns from community prep materials and early test-takers:

  • Build a real project — the exam tests architectural judgment that comes from hands-on experience, not memorization
  • Practice tradeoff reasoning — for every pattern, know when it is the wrong choice. The exam rarely asks “what is X” — it asks “given these constraints, which approach is best”
  • Focus on the ‘why’ — understanding why a pattern exists is more valuable than memorizing how to implement it
  • Study the scenario format — the exam presents 4 production scenarios and asks questions within those contexts. Practice reading a system description and identifying architectural decisions
  • Time management — 60 questions means roughly 1-2 minutes per question. Scenario-based questions take longer; factor that in

Key Takeaways

  • Agentic Architecture (27%) and Tool Design (18%) together account for 45% of the exam — they deserve the most study time
  • The exam tests tradeoff thinking, not definitions — prepare by understanding when patterns apply and when they do not
  • Deterministic solutions (schemas, enums, machine IDs) are consistently preferred over probabilistic solutions (prompts, retries)
  • Build something real to internalize the patterns — reading about architecture is not the same as doing it
  • The 4-random-scenario format means you need broad coverage, not deep expertise in one area
  • Community resources (GitHub repo, claudecertifications.com) supplement the official Anthropic Academy courses well

Try It

  1. Complete Anthropic Academy courses — all 13, starting with Agentic Architecture and Tool Design
  2. Work through practice questions — see certification-practice-questions for domain-by-domain patterns
  3. Build a multi-agent Claude Code project — include subagents, MCP tools, structured output with JSON schemas, and explicit context management. Touch all 5 domains
  4. Practice scenario analysis — take any production system you have worked on and identify: what are the agent boundaries, what should be deterministic vs. prompt-based, where are the failure modes
  5. Review the GitHub exam prep repo — github.com/avidevelops/claude-architect-exam-prep for scenario-style questions

Open Questions

  • Does Anthropic publish an official study guide or reading list beyond the Academy courses? Answered: Yes. The official exam guide PDF and The Architect’s Playbook PDF are now available. See official-exam-guide and architects-playbook
  • How closely do the community practice questions match the actual exam difficulty?
  • Are the Anthropic Academy courses updated as the exam evolves?
  • What hands-on experience level is assumed? Answered: The official guide specifies 6+ months of practical experience building with Claude APIs, Agent SDK, Claude Code, and MCP

Graph View

Backlinks