What the CCA-F Exam Covers

Claude Certified Architect: Foundations is Anthropic’s foundation-level credential for solution architects who design and build production applications with Claude. ExamSnap’s existing exam page and sales reporting use the label CCA-F, while the current published exam guide uses the official exam code CCAR-F. That distinction matters when researching the certification: the site URL remains the established CCA-F exam, but candidates should recognize CCAR-F when they encounter current Anthropic exam materials.

The certification is not a general test of artificial intelligence terminology. Anthropic positions the credential around the practical work of designing Claude-based systems. The exam expects candidates to understand agentic control flow, tool design, Model Context Protocol integration, Claude Code configuration, prompt engineering, structured outputs, context management, and reliability decisions. In other words, it tests whether an architect can choose an appropriate implementation pattern when a production system has competing requirements.

Anthropic’s broader certification program now includes several role-based credentials, and the foundation architect credential sits specifically on the technical architecture side of that program. Candidates comparing it with other Anthropic certifications should therefore treat it as an applied architecture exam rather than a model-facts exam.

The exam is built around production decisions

The most important way to understand the CCA-F/CCAR-F exam is to stop thinking of it as a checklist of isolated definitions. The current blueprint is organized around realistic production scenarios. A candidate may be asked to reason about an agent that calls tools, a multi-agent research workflow, Claude Code in a development environment, automated review in CI/CD, or structured extraction from documents.

Those scenarios force several concerns to interact at once. A tool description may affect whether Claude selects the correct action. A context-management decision may determine whether a subagent receives enough information to complete a task. A prompt may reduce false positives, but a policy that must never be bypassed may need programmatic enforcement instead. The exam rewards that ability to separate probabilistic guidance from deterministic control.

This architecture-first framing is why generic memorization is weak preparation. Candidates need to know how pieces such as tool calls, schemas, hooks, session state, prompts, and handoffs behave when they are combined.

Domain 1: Agentic Architecture and Orchestration

Agentic Architecture and Orchestration is the largest domain in the current blueprint at 27 percent. It covers the control structures that allow Claude to work through a task across multiple steps rather than simply returning one response.

A core pattern is the agentic loop: send a request, inspect Claude’s stop reason, execute any requested tool calls, return the tool results, and continue until the model signals that the turn is complete. The surrounding application is responsible for transporting messages, executing tools, preserving the necessary state, and enforcing hard constraints. Claude decides which modeled action to take next within the tools and context it has been given.

The domain also covers coordinator-subagent architecture, explicit context passing, workflow handoffs, hooks, task decomposition, and session state. The broader concepts in AI agent fundamentals—goals, state, tools, and feedback loops—also apply, but the certification goes further by testing concrete Claude architecture decisions rather than generic descriptions of agents.

Architects should be comfortable deciding when one agent is sufficient, when work should be split among specialized subagents, what context each subagent needs, and how the coordinator should collect results without allowing the system to become an uncontrolled web of dependencies.

Domain 2: Tool Design and MCP Integration

Tool Design and MCP Integration accounts for 18 percent of the blueprint. This domain is about giving Claude useful external capabilities without making those interfaces vague, unsafe, or difficult for the model to select correctly.

Strong tool design starts with precise descriptions and well-bounded responsibilities. If two tools appear interchangeable, the model may select inconsistently. If a single tool performs too many unrelated actions, its arguments and failure modes become harder to reason about. The architecture should make the valid action space understandable to both the model and the application.

The exam also expects candidates to understand structured error responses and MCP integration. An MCP tool should not return an undifferentiated failure string when the calling agent needs to know whether the problem is transient, caused by invalid input, blocked by permissions, or the result of a business rule. Clear error semantics let the agent recover locally when appropriate and escalate when it cannot.

Reliable tool use and function calling depends on clear schemas, permissions, failure handling, and controlled side effects. CCA-F narrows those principles to the tool-selection and MCP decisions described in the exam blueprint.

Domain 3: Claude Code Configuration and Workflows

Claude Code Configuration and Workflows represents 20 percent of the exam. This is not simply a question of knowing that Claude Code exists. Candidates need to understand how project instructions, scoped rules, skills, commands, plan mode, iterative refinement, and CI/CD integration affect behavior.

One recurring architectural issue is scope. Instructions that belong to an entire repository should not be duplicated across every task. Rules that apply only to particular paths should load conditionally. A reusable workflow may deserve a skill or command rather than a long prompt copied into each conversation.

Candidates should also understand the difference between planning and direct execution. Some changes benefit from a reviewable plan before edits begin; others are sufficiently bounded that direct execution is more efficient. The exam tests judgment about those trade-offs rather than a blanket preference for one mode.

CI/CD scenarios add another constraint: automated review must be actionable and consistent enough to be useful in a pipeline. That naturally connects Claude Code configuration with the prompt-engineering domain.

Domain 4: Prompt Engineering and Structured Output

Prompt Engineering and Structured Output is another 20 percent of the blueprint. The emphasis is on production reliability rather than clever wording. Candidates should know how explicit criteria reduce ambiguity, how few-shot examples help with difficult classification or review tasks, and when structured output should be enforced with a schema rather than merely requested in prose.

A useful distinction is that prompt engineering guides model behavior, while schemas and application validation can enforce properties the downstream system requires. A prompt saying “return valid JSON” is not the same thing as a structured-output mechanism that guarantees schema conformance.

Core prompt engineering fundamentals include instructions, context, examples, constraints, and output contracts. CCA-F connects those fundamentals to blueprint decisions such as false-positive reduction, few-shot prompting, validation and retry loops, batch processing, and multi-pass review.

Domain 5: Context Management and Reliability

Context Management and Reliability accounts for the remaining 15 percent. It deals with what happens when a system must preserve important information across long interactions, recover from ambiguity or failures, and produce results that can be trusted enough for downstream use.

The exam is not asking candidates to memorize a model’s current token limit. Context limits can change by model and platform. The architectural question is how to preserve the information that must survive across steps while avoiding a transcript that becomes noisy, expensive, and difficult to reason about.

This domain also includes escalation, error propagation, large-codebase context, human review, confidence calibration, and information provenance. A multi-agent research system, for example, is only as trustworthy as its ability to preserve which source supported which claim. A support agent should know when ambiguity exceeds its authority and the workflow should escalate rather than improvise.

These concerns also intersect with AI evaluation fundamentals: representative test sets and system-level metrics can expose failures that polished demonstrations hide.

The current exam guide describes a scenario-based assessment with 60 items and a 120-minute time limit. The current passing standard is a scaled score of 720 on a 100–1,000 scale. The guide also describes multiple-choice and multiple-response items, so candidates need to read the selection instruction on each question rather than assume every item has a single answer.

The scenario model changes how preparation should work. Studying definitions in isolation is useful only as a foundation. Candidates also need to practice choosing between several plausible designs when the question gives constraints about reliability, permissions, scale, failure behavior, or workflow complexity.

A strong answer is often not the most elaborate architecture. If a clearer tool description fixes tool-selection confusion, building another routing service may be unnecessary. If a rule must be guaranteed for compliance or financial safety, however, putting it only in the prompt is usually too weak. The exam repeatedly rewards matching the enforcement mechanism to the risk.

The published exam material uses six production scenario families, with a subset presented on an exam form. They include customer support, code generation with Claude Code, multi-agent research, developer productivity, Claude Code in continuous integration, and structured data extraction.

Those scenarios are useful because they reveal why the five domains are connected. Customer support naturally combines agentic loops, tools, escalation, and reliability. Multi-agent research combines delegation, context passing, provenance, and synthesis. CI/CD connects Claude Code with prompt criteria and multi-pass review. Structured extraction connects schemas, validation, retries, and handling uncertain or missing fields.

Rather than trying to predict which scenario will appear, candidates should use each one as a way to rehearse the same architectural principles in a different environment.

Several popular AI topics are outside the exam scope

A topical-authority site can cover many subjects around Claude, but CCA-F preparation should not imply that every Claude topic belongs on this exam. The current guide explicitly excludes areas such as fine-tuning custom models, details of Claude’s internal training architecture, embedding models and vector databases, computer use, vision/image analysis, and cloud-provider-specific deployment configuration.

That distinction matters for both candidates and content planning. Retrieval-augmented generation, vector search, multimodal applications, or provider-specific hosting may be valuable Claude subjects, but they should be treated as broader Claude architecture topics rather than presented as direct CCA-F objectives unless the current guide changes.

Keeping the boundary clear prevents candidates from spending study time on attractive but low-value material while underpreparing for tool design, Claude Code, structured output, and context reliability.

Who is ready to take CCA-F seriously

The target candidate is a practitioner who can reason about production applications rather than merely operate a chat interface. The current program describes Claude Certified Architect: Foundations as a credential for solution architects who design and build agent systems with Claude, and current exam guidance assumes hands-on familiarity with the Claude API, Agent SDK, Claude Code, and MCP.

That does not mean a candidate needs years of Claude-specific experience. It does mean that reading documentation without building anything creates a weak foundation. If you have never implemented a tool call, handled a structured error, configured project instructions, passed context into a subagent, or validated structured output, those are better places to begin than memorizing terminology.

The certification is best understood as a test of architectural judgment. Learn the five domains, build the behaviors they describe, and practice explaining why one implementation fits a scenario better than another. That approach matches what the exam is designed to validate and creates skills that remain useful after the exam itself changes.