CCA-F (Claude Certified Architect – Foundations) is an architecture exam, not a vocabulary quiz. The emphasis is on production trade-offs: when to execute a tool, how to delegate responsibly, where to enforce non-negotiable rules, and how to recover when context becomes unreliable. This CCA-F learning center brings the exam-specific guides into one practical study route.
Begin with the decisions you cannot yet explain. A strong study session should end with a design, a failure case and a reasoned alternative—not merely a page of highlighted definitions. The guides below deliberately separate exam facts, hands-on preparation, and the five blueprint domains so each has a distinct purpose.
Start with the right kind of preparation
Three resources have separate jobs. The exam overview explains what the certification measures and how the exam is structured. The study plan turns the weighted blueprint into a sensible learning sequence. The hands-on practice guide tells you what to build or test so architecture principles become decisions you can defend.
New to tool-based agents? Start with the message-and-tool cycle, then learn explicit tool schemas before coordinating multiple agents. Already deploying Claude Code? Begin with project instructions and deterministic hooks, then test an unattended review workflow. Comfortable with the platform but uncertain about exam scenarios? Use the worked decisions below to compare competing designs and write down why you rejected plausible alternatives.
The material is educational and independently authored; it does not claim to reproduce Anthropic’s protected certification questions. Use Anthropic’s published guide for the authoritative exam scope and confirm current eligibility before planning a sitting.
Learn the five exam domains
Use the weights to balance study time, not to justify ignoring any domain. The underlying architecture crosses boundaries: tool integration affects agent design, Claude Code workflows require correct permissions, and structured outputs are useful only when context and validation remain sound.
1. Agentic Architecture and Orchestration — 27%
The largest domain is about control flow rather than the number of agents in your diagram. Start with the exact loop: receive Claude’s response, inspect any tool-use requests, execute only authorized actions, send corresponding results and continue until the protocol indicates completion. The surrounding application—not the model’s reassuring language—owns permissions and stopping rules. Adding subagents helps when separate work can actually be delegated and checked; it is not a default quality upgrade.
Decision to rehearse: A research coordinator has delegated three independent subtasks, but one result conflicts with the source material. Do you add more subagents, rewrite the prompt, or stop the synthesis and preserve provenance? Explain what would make the final answer trustworthy, not merely fluent.
- Agentic loops — trace tool-use messages, stopping conditions and the application’s execution boundary
- Multi-agent architecture — choose when independent roles deserve separate context and work
- Workflow enforcement — protect hard prerequisites while leaving judgment flexible inside the safe path
- Task decomposition — decide between a fixed chain and discovery-led subtasks
- Error propagation — keep questionable subagent output from becoming shared fact
- Ambiguity and escalation — recognize when further autonomous work would amplify uncertainty
2. Tool Design and MCP Integration — 18%
A good tool is not simply callable; it has an unambiguous purpose, a clear input contract, a meaningful error path and an appropriate permission boundary. MCP supplies a standard integration surface for capabilities, but it does not decide who may use them or what side effects are acceptable. On a scenario question, distinguish a tool-selection problem from a workflow-authorization problem before changing the design.
Decision to rehearse: An agent chooses the wrong customer tool because two descriptions overlap. Improve the tool names and schemas before adding elaborate prompting. If the tool can issue a refund, the application should still enforce identity, amount limits and auditability independently of what the model requests.
- Tool design — separate descriptive clarity, argument schema and authorized execution
- MCP integration — follow client/server discovery, authentication, errors and capability scoping
3. Claude Code Configuration and Workflows — 20%
Claude Code questions are often about choosing the right layer. Stable repository conventions belong in appropriately scoped project instructions; a specialized review or deployment procedure is better treated as an on-demand Skill. Rules that must execute predictably belong in deterministic controls rather than a hopeful prompt. Unattended CI/CD adds another constraint: the process must return machine-readable results and fail safely without an interactive approval dialog.
Decision to rehearse: A pull-request review should inspect code but never deploy it. Decide which instructions belong in the repository, which workflow should be invoked when needed, and which tool permissions must be mechanically denied. A good answer names a test that would prove the boundary holds even when the model makes an unexpected suggestion.
- Claude Code configuration — understand project instructions, settings and precedence
- Reusable Skills — distinguish on-demand procedures from always-loaded context; current Claude Code has unified custom commands with Skills
- Path-specific rules — apply instructions only where a file or directory truly requires them
- Plan mode — select an exploration-and-approval boundary for uncertain work
- CI/CD workflows — use noninteractive runs, structured output and constrained permissions
- Deterministic hooks — enforce rules at a control point rather than trust wording alone
4. Prompt Engineering and Structured Output — 20%
The practical question is whether the failure comes from underspecified intent, inconsistent examples or an invalid downstream contract. Few-shot examples can teach judgment where prose is ambiguous. When software consumes the answer, use a predictable schema and validate both its shape and its meaning. A syntactically valid object can still contain a fabricated identifier or an unsupported business decision.
Decision to rehearse: A document extractor returns parseable JSON, but sometimes invents missing invoice dates. Should you add more examples, strengthen output validation, or change the product workflow? Describe how the system represents an unknown date without silently converting it into false certainty.
- Prompt engineering — make task, examples, inputs and trusted instructions explicit
- Structured output — separate schema conformance from business validity and fallback behavior
- Iterative refinement — choose when examples, tests or a targeted diagnostic will fix the actual error
5. Context Management and Reliability — 15%
A long conversation is not a trustworthy database. Preserve the durable facts and provenance that a future step needs; do not assume a compressed summary carries every caveat, timestamp or permission. Resuming old work requires checking whether external state has changed. Reliability also demands explicit review thresholds, recoverable async operations, and identifiers that let the application pair responses with the correct requests.
Decision to rehearse: A code investigation is resumed after a production deployment changed the repository. Reusing the earlier result may be faster but wrong. Identify which facts remain durable, which tool outputs must be rechecked and which uncertainty should trigger a human decision.
- Context reliability — choose what belongs in active context versus durable state
- Session resumption — avoid treating stale tool results as current after a fork or restart
- Human review — route high-risk and ambiguous decisions to explicit approval
- Message Batches API — design stable request identifiers, result retrieval and asynchronous recovery
- Information provenance — keep sources and disagreement visible after summarization
- Large-codebase context — navigate repositories by useful landmarks instead of dumping every file
Five production decisions worth practicing
The official blueprint uses realistic scenarios to combine several domains. These independent exercises are not recalled exam items; they are design prompts that expose whether you can identify the failure mechanism, choose a control and explain a trade-off. Sketch the workflow, name the application-enforced boundary and describe the evidence that would tell you whether your change worked.
Customer support: a tool request is not an authorization
A support assistant can read an order and propose a refund. A customer says, “Please refund the whole account today,” but the system has not checked ownership or amount limits. A longer instruction telling Claude to be careful is inadequate. Separate a read-only lookup from the side-effecting refund action. Require application-level identity verification, policy checks, a clear approval or exception path, and a stable identifier that prevents duplicate refunds on retries. The model can recommend a resolution; the application must decide whether the action is allowed. For an end-to-end implementation, the CCA-F support-agent lab follows this authorization boundary through identity checks, a scoped approval and an idempotent refund attempt.
Test: Replay an ambiguous identity match, an amount outside policy, a repeated tool request and an unavailable billing service. A good design yields a predictable refusal or escalation, not an enthusiastic but unauthorized tool call.
Document extraction: a clean schema does not guarantee truth
A workflow extracts invoice fields for downstream accounting. The output passes JSON parsing, yet missing dates are silently guessed and supplier identifiers are sometimes copied from the wrong document. Establish a schema with explicit missing-value representation, attach source references where available and validate business constraints independently of the model. Separate structural validation from claims about the real document: both are needed. A retry should use a specific failure explanation; repeated retries with no new evidence are not a substitute for escalation. The CCA-F invoice extraction lab turns these principles into a checkable document pipeline with source quotations, decimal arithmetic and exception handling.
Test: Run low-quality scans, two suppliers with similar names, contradictory amounts and a deliberately absent date. Preserve uncertainty rather than manufacturing a plausible answer.
Claude Code review: AI judgment inside a deterministic pipeline
A team wants automatic pull-request feedback. The agent should read diffs, flag risks and emit structured findings, but it must not commit code, change production configuration or deploy. Keep the workflow noninteractive and the runtime permissions genuinely read-only. A later human or test-driven stage can make the final decision. Treat the review result as one signal alongside tests and static analysis, rather than an authority that merges its own recommendations.
Test: Supply a malicious comment inside a repository file that asks the reviewer to ignore its instructions and run a release command. The expected outcome is an ordinary review finding, with no privileged action.
Multi-agent research: preserve disagreement
A coordinator asks separate research agents to investigate the same policy from different sources. One result is old; another is incomplete. Combining both into a fluent summary destroys the distinction between verified facts and uncertain interpretation. Give agents bounded questions, require source locations and timestamps when appropriate, and keep the coordinator responsible for reconciling contradictions. More agents can add coverage but also increase propagation risk when their outputs are trusted without review.
Test: Make one subagent return a confident claim without evidence. The synthesis must identify the missing support, not invent a consensus.
Long investigation: context is not durable state
A debugging session spans several days. The context window is compressed, a build has changed and an external service returned a temporary error during the earlier run. Before continuing, distinguish stable decisions from state that may have expired. Save the investigation’s evidence, hypotheses and unresolved questions in a durable record; recheck the repository revision and external outputs that can change. If an ambiguity affects a production action, make the next step an explicit review decision.
Test: Resume after replacing the configuration file under investigation. A reliable workflow notices the revision change and revisits only the invalidated evidence.
Use evidence to judge your readiness
For each domain, pick one real or simulated failure and write a short design review. State the observed symptom; identify the model-facing behavior versus the application-enforced control; choose the smallest responsible fix; explain why two tempting alternatives are worse; and describe one negative test. If you cannot explain the failure without appealing to “the model should know,” revisit the corresponding field guide.
Spend some practice time in mixed scenarios rather than answering twenty questions on one topic in isolation. In production, a context problem can look like a tool-selection problem; a schema can validate shape while missing business meaning; and a subagent can return a polished summary that lacks evidence. Seeing those overlaps early is more useful than memorizing isolated terms.
When you want to test the full architecture rather than one isolated concept, the CCA-F scenario practice test provides 20 original cases with an explanation of each correct and incorrect choice. The site’s separate CCA-F preparation resources offer another study option. These independent educational materials do not reproduce Anthropic’s protected exam items, and no practice set substitutes for hands-on work or the issuer’s current guide.
Exam access, format and currentness
As of October 2026, the official exam guide describes CCA-F (Claude Certified Architect – Foundations) as a 60-question, 120-minute assessment with a passing standard of 720 on a scaled score. The scaled score is not a 72 percent raw-answer requirement. The stated standard fee is $125 before any eligible partner discounts, and certification validity is 12 months. Check the issuer’s guide for changes.
Eligibility matters: Anthropic currently allows registration only through organizations in the Claude Partner Network using recognized business email domains. Registration leads to scheduling through Pearson. Being able to study the material or purchase third-party preparation does not itself establish exam eligibility. See Anthropic’s current certification FAQ before making plans. The exam guide—not a blog post—is the controlling source if the blueprint, prices or access rules change.
Use this center as a working map: return to the guide that explains the next decision you cannot defend, test it with a real counterexample, and continue when you can explain both the chosen design and the simpler alternative you rejected.
