Claude Certified Architect \u2013 Foundations measures your ability to design useful, reliable systems with Claude. Learning a model’s terminology is only a starting point: the exam’s five domains call for choices about agentic workflows, tool interfaces, Claude Code, structured outputs and recovery when something fails. This article interprets the current published blueprint and shows how to practice those architecture decisions.<\/p>\n
Examtopics.biz labels its independent preparation listing CCA-F. Anthropic’s public credential name is Claude Certified Architect \u2013 Foundations, while some third-party study materials use CCAR-F. Those variations do not establish two separate Architect Foundations exams. For registration or official exam requirements, use Anthropic’s current program and exam guide rather than assuming that either abbreviation is authoritative. Architect Professional, Developer Foundations and Associate Foundations are separate credentials.<\/p>\n
The Architect role deals with decisions across a system: choosing single-shot versus agentic processing, making tool permissions narrow, preserving evidence across delegated research, assessing structured responses, and anticipating operational risk. A prompt can ask the model to behave carefully; an architecture must still define what the model is allowed to do, what is independently verified, and how the system recovers when a request is uncertain.<\/p>\n
For exam facts, treat Anthropic’s current certification listing and downloadable exam guide as the authority. For actual technical implementation, consult the current Claude Platform, Claude Code, and MCP documentation, because tool names, APIs and model compatibility can evolve after a blueprint is published.<\/p>\n
Anthropic’s certification FAQ<\/a>\u00a0says that exam registration is currently restricted to people working at Claude Partner Network organizations. Registration requires a recognized company email domain; a personal email address is not eligible. The FAQ also specifies a minimum age of 18. These are program access conditions, not merely suggestions about the experience of an ideal candidate.<\/p>\n Formal exam prerequisites should be checked against the latest issuer guide rather than inferred from the word \u201cFoundations.\u201d Eligibility is not the same as preparation. A solution architect who has already built with Claude’s API, performed repository work with Claude Code and designed a system that uses external tools will be better equipped to recognize trade-offs. Someone new to these tools can develop the same judgment through deliberate practice with bounded, testable exercises.<\/p>\n Certification validates specific assessed skills. It is not a substitute for software testing, privacy review, production monitoring, human accountability, or platform-specific implementation approval. Those remain necessary whether a practitioner holds the credential or not.<\/p>\n The Anthropic Academy listing for Architect Foundations<\/a>\u00a0specifies 60 multiple-choice and multiple-response questions and a 120-minute exam. Plan for approximately 135 minutes of seat time including the surrounding appointment process. It lists delivery through online proctoring or a Pearson test center, English-language content, a $125 USD standard fee before eligible partner discounts, and certification validity of 12 months.<\/p>\n The listed passing score is 720 on a scaled range of 100 to 1,000. That does not mean the requirement is 72% correct. A scaled score cannot be safely turned into a raw correct-answer percentage or a promised number of questions you can miss. Focus your preparation on explaining why an architectural decision satisfies a requirement; do not optimize for a guessed raw score.<\/p>\n Registration starts through the Partner Academy, with scheduling through Pearson. Anthropic says the examination is closed-book: notes, external documentation, translation tools and AI assistants are not permitted during testing. The certification FAQ also states that the Architect Foundations price changed from $99 to $125 effective June 30, 2026, so an older third-party price may be out of date. Cancellation or rescheduling must occur at least 48 hours before the appointment; separate retake rules apply. Verify current delivery policies, discounts and deadlines in the issuer’s portal before booking.<\/p>\n The official weights sum to 100%. Use them to spot priority areas, but don’t interpret each percentage as a fixed number of questions or a demand to read that proportion of articles. Your best preparation work involves explaining decisions under constraints.<\/p>\n This largest domain asks why an adaptive, tool-using agent is appropriate for some problems and unnecessary for others. A single request can summarize a supplied policy. A support case that requires order lookup, eligibility checks, approval and a verified refund outcome is a different problem: it needs state, tool execution boundaries, termination conditions and error handling. The architect should be able to justify the extra autonomy rather than assume more agents mean a better system.<\/p>\n Claude can request a client-executed tool<\/a>, but the application executes the operation and returns a tool result. A proposed action is not proof it occurred. If a downstream payment service times out, the agent must not infer that the refund completed. Delegating a task to a subagent adds a second boundary: what evidence and context does that specialist receive, and how does the coordinator know that the delegated work was really finished?<\/p>\n A useful exercise is to design a deterministic workflow and an agentic alternative for the same support task. Compare cost, failure modes, privileges, timing, auditability and the conditions under which each design should terminate.<\/p>\n Tool quality is a security and reliability issue as much as a model-selection issue. The Model Context Protocol<\/a> lets compatible clients discover and invoke tools made available by a server. It does not waive the need for authentication, scoped authorization, secret management or validation in the application or tool service.<\/p>\n A useful tool should have a bounded purpose, typed inputs, a clear description and predictable errors. An order reader might require a verified customer identity and order ID, returning only order status. A separate refund tool should enforce eligibility and authorization instead of accepting the model’s request as sufficient. Broad tools that execute arbitrary commands or retrieve every customer record are much harder to review and govern.<\/p>\n Practice diagnosing a bad tool description, mismatched response fields, an invalid protocol call and a business-level denial. Then explain how the client should handle the result without guessing success or retrying a side effect without checking whether it already occurred.<\/p>\n Claude Code works in the context of a repository, not in a vacuum. The engineering decision is how to give it the relevant conventions and tools without supplying uncontrolled authority or overwhelming context. Repository instructions<\/a>, scoped rules, skills, permissions, hooks and subagents can help organize the work, but their current syntax must be checked against the product documentation.<\/p>\n Consider a request to change validation logic used by three services. Read the relevant files and tests, identify the expected behavior, decide whether a plan-first pass will reduce risk, and make the smallest verifiable changes. Test the actual result. For a small reversible change, direct execution may be reasonable; for broad refactoring or a CI workflow, stronger boundaries and explicit checkpoints may be necessary.<\/p>\n In CI\/CD, an AI-assisted review should inform human decisions without replacing deterministic tests, required approvals or secret-protection controls. Evaluate false positives, missing failure paths and the consequences of granting unattended tools more access than the task demands.<\/p>\n For a structured extraction system, a polished natural-language answer is not enough. You need an output contract: required fields, types, how missing information is represented, acceptable evidence and independent validation. Few-shot examples can clarify unusual documents, but a prompt that merely says ‘output valid JSON’ does not replace schema validation.<\/p>\n Suppose an invoice contains an amount and supplier name but no purchase-order number. A credible extractor can return a missing or null PO field with provenance; it should not invent an identifier to satisfy an imagined completeness requirement. A downstream validator then checks types, numeric constraints and business rules, and routes uncertain records to review.<\/p>\n Compare two designs: a single prompt that emits plausible fields, and a pipeline that distinguishes parse errors, factual errors, missing evidence and recoverable exceptions. This reveals why structured output<\/a> is a system property rather than a cosmetic output preference.<\/p>\n A long workflow may lose important information when context changes, while a multi-agent research<\/a> chain can lose the source citation that made a claim verifiable. A reliable system preserves important state outside a transient model response: stable identifiers, completed steps, unresolved work, relevant evidence and permission decisions.<\/p>\n An interrupted refund or data update illustrates the problem. If a service times out after receiving a write request, the system needs to discover whether the side effect happened before retrying. Idempotency keys, external status checks and durable logs matter more than a confident completion message. For document research, keep claim-to-source identifiers together so a summary can be checked after handoff.<\/p>\n In practice, rehearse ambiguity: two sources disagree, an agent provides an answer without evidence, a tool returns a partial result, or a session runs out of context. Explain when to continue, when to retry, when to preserve a partial status and when a human must decide.<\/p>\n To prepare for architectural decisions across the five published domains, test six representative application scenarios below. Each calls for a concrete trust boundary, decision record and failure-recovery plan. These are illustrative learning exercises, not an official numbered scenario list, a prediction that any fixed number appears on an exam form, or a reconstruction of real examination questions.<\/p>\n 1. Customer support resolution. An agent must use account and order facts, apply policy and decide whether a request needs human escalation. The design question is how to prevent unauthorized actions and provide a recoverable outcome when an external service fails.<\/p>\n 2. Code generation with Claude Code. A coding assistant makes a change across files while respecting project conventions, permissions, tests and review practices. The question is what context and execution process will produce a controlled, correct change.<\/p>\n 3. Multi-agent research. A coordinator delegates retrieval, analysis and synthesis but must keep evidence connected to claims. What happens when an agent times out, two sources disagree, or one report contains an unsupported conclusion?<\/p>\n 4. Developer productivity. An assistant navigates and modifies a codebase. It should select necessary read\/search\/edit tools without drifting into unrelated files or losing the requirements during a lengthy investigation.<\/p>\n 5. Claude Code in CI\/CD. A bounded automated review or test-support process needs reproducible inputs, deterministic gates, limited credentials and observable failures. An AI observation must not automatically bypass a mandatory deployment approval.<\/p>\nExam format, score and delivery<\/h2>\n
Understand the five exam domains by the decisions they test<\/h2>\n
Agentic Architecture & Orchestration \u2014 27%<\/h3>\n
Tool Design & MCP Integration \u2014 18%<\/h3>\n
Claude Code Configuration & Workflows \u2014 20%<\/h3>\n
Prompt Engineering & Structured Output \u2014 20%<\/h3>\n
Context Management & Reliability \u2014 15%<\/h3>\n
Scenario-style preparation: six representative workloads<\/h2>\n