← Blog

Claude Code Architecture Certification: What the CCA-F Tests

August 7, 2026

A knowledge map of Claude Code's agent loop, tool permissions, and MCP integration for the Claude Certified Architect exam.

The Claude Certified Architect — Foundations (CCA-F) exam tests Claude Code architecture at the design level: agent loops, tool-permission flows, and MCP server integration are all fair game. Daily Claude Code experience maps directly to much of what is tested — but precise terminology and tradeoff reasoning is what earns passing marks.

What Does the CCA-F Exam Actually Test About Claude Code Architecture?

The exam treats Claude Code not as a product to use but as an architecture to reason about. Candidates pursuing a Claude Code architecture certification need to explain how the model receives context, how tools are dispatched and their results returned, how permissions gate sensitive actions, and how MCP servers extend the agent's capabilities through a standardized protocol.

The CCA-F focuses on design-level understanding rather than line-by-line coding. A developer who has spent months building agentic Claude Code workflows has likely absorbed most of the underlying mechanics through practice. What the exam adds is precise terminology, formal tradeoff analysis, and the ability to choose between architectural patterns given a described scenario — the difference between "it works" and "I can explain why it is designed this way."

Independence notice: Plinth Prep is an independent study resource and is not affiliated with, endorsed by, or sponsored by Anthropic. Exam coverage assessments on this page are based on publicly available exam information and practitioner observation — not insider knowledge of exam content. Verify current exam scope against Anthropic's official resources before you sit the exam.

How Is Claude Code's Agent Loop Represented in Exam Questions?

The agent loop mechanics tested on the CCA-F span two layers: the standard Messages API stop reasons (tool_use, end_turn, pause_turn) that Claude Code is built on, and the Managed Agents session-event layer (session.status_idle, user.tool_confirmation) that your client application actually interacts with.

Every Claude Code session runs an agent loop: the model receives input, decides whether to call a tool, receives the tool result as a user-role message, and loops until it returns a stop_reason of end_turn. That loop — and its exceptions — is a recurring theme across Anthropic certification courses and the CCA-F itself.

The exam probes the agent loop at three levels:

  • Loop continuation and termination. The loop continues when stop_reason is tool_use. It ends naturally at end_turn or pauses at pause_turn — the signal that a server-side tool loop hit its iteration limit and can be resumed. Candidates must distinguish these and know that resuming a pause_turn means appending the assistant turn and re-sending without inserting an extra user message.
  • Tool result structure. Results return as user-role messages containing tool_result content blocks, each matched to the originating tool_use block by ID. The exam tests whether you know this structure rather than treating results as arriving out-of-band.
  • Multi-tool turns. Claude can request multiple tool calls in a single response. All results must return together in a single user message before the loop can continue. Sending results one at a time is architecturally incorrect and will stall the session.

Developers who have debugged hung sessions or unexpected stops in Claude Code have lived these mechanics. The exam asks you to name them and explain the design rationale.

What Does the Exam Expect You to Know About Tool Permissions and Safety Layers?

Claude Code's permission model lets you control whether each tool executes automatically or waits for explicit approval. Two policies sit at the center of exam questions in this area:

always_allow — the tool executes without pausing the session. Appropriate for read-only or low-risk operations: file reads, pattern matching, web searches with no side effects.

always_ask — the tool fires a session.status_idle event and suspends execution until your application sends a user.tool_confirmation event with result: "allow" or "deny". The design intent is human-in-the-loop oversight for actions with significant side effects: bash commands that write to disk, git pushes, external API calls with real-world consequences.

The exam asks you to choose the right policy for a described scenario. A common pattern: an agent that can run tests (low risk, always_allow appropriate) and also deploy to a staging environment (high risk, always_ask appropriate). Answering correctly requires knowing that policies are configurable per tool via the configs array — not just as a blanket default_config setting.

A point the exam emphasizes that surprises many candidates: always_ask does not mean the tool is denied. It means the session pauses and waits for your client to respond. Silence is not a deny. A session sitting in requires_action idle state remains there until your application sends a confirmation event — or the session times out.

How Is MCP Integration Tested in a Claude Code Context?

The Model Context Protocol extends Claude Code with standardized third-party capabilities — GitHub, Linear, Notion, and similar services. The exam draws heavily on the architectural separation that makes MCP work securely, and that separation is one area where candidates who have wired up Claude Code integrations often realize they understood the "how" without examining the "why."

Two constructs the exam expects you to distinguish clearly:

  • Server declaration belongs on the agent configuration, not the session. You declare {type: "url", name: "github", url: "..."} in the agent's mcp_servers array. This definition carries no credentials — it is a pointer to a capability, not an authenticated connection.
  • Authentication belongs in a vault, attached at session creation via vault_ids. The vault holds OAuth credentials — access token, refresh token, and token endpoint. Anthropic's infrastructure auto-refreshes these before they expire; the session container never sees them.

Three scenario types built on this architecture appear frequently in CCA-F preparation material:

  • What happens if a vault credential is invalid when a session starts? Session creation succeeds; a session.error event is emitted when the agent first attempts to use the tool.
  • Where are credentials injected into MCP tool calls? On Anthropic's orchestration layer, not inside the container — the container cannot read or exfiltrate them even under prompt injection.
  • Why separate server declaration from authentication? So agent configurations can be versioned and reused across sessions with different credential sets — different users, organizations, or permission scopes.

Developers who have wired up an MCP integration in Claude Code have encountered this pattern. The exam adds the "why" layer on top of the "how" they already know. For a deeper reference, the Managed Agents tools and MCP integration documentation covers this architecture in full.

Which Architecture Tradeoffs Separate Passing Answers from High-Score Answers?

Scenario questions on the CCA-F often have two plausible answers. The difference between a passing response and a high-score response is the ability to name the tradeoff explicitly and state the condition under which each choice is correct.

Three tradeoff frames that appear frequently, based on the published exam domain structure:

Bash vs. dedicated tools. Bash gives Claude broad programmatic leverage but hands your harness an opaque command string — the same shape for every action. A dedicated custom tool gives the harness a named action with a typed schema it can gate, log, or approve selectively. The exam asks when you would promote an action from bash to a dedicated tool. The answer centers on reversibility, auditability, and whether you need per-action approval workflows — not general risk level.

always_allow vs. always_ask. The exam expects more than "use always_ask for risky actions." It expects you to articulate that always_ask adds round-trip latency, requires your application to handle requires_action idle states, and can stall a session if your client never responds. The architectural tradeoff is correctness and control versus throughput and simplicity.

Compaction vs. context editing. Both manage long-running sessions, but differently. Compaction summarizes earlier conversation history when the session approaches the context window ceiling. Context editing prunes stale tool results and thinking blocks at the turn level without summarizing. The exam asks you to match the mechanism to the problem: compaction for conversation-length management, context editing for pruning data that has served its purpose within a turn.

Worked Scenario: Tool Permission Design

Scenario: An agent can run tests and deploy to staging. Which permission policy applies to each tool, and what session events must the client handle?

Model answer: Use always_allow for the test runner — it is low-risk and read-oriented, so no pause is needed. Use always_ask for the deploy tool — it fires a session.status_idle event with stop_reason: "requires_action"; the client must send a user.tool_confirmation event with result: "allow" or "deny" before the session resumes. Set both policies per tool via the configs array.

How Do You Convert Claude Code Experience into CCA-F Exam Credit?

If you are building with Claude Code and working toward becoming a Claude Certified Architect, daily experience is a strong foundation — but the exam rewards two additional competencies that do not always emerge from practice alone: vocabulary precision and tradeoff articulation.

Vocabulary precision means using the official term, not a close paraphrase. The loop mechanic where a tool result comes back is not just "the response arrives" — it is a tool_result content block in a user-role turn, matched to its originating block by tool_use_id. The permission model is not "ask before dangerous tools" — it is always_ask with a user.tool_confirmation response event. Exam questions test whether you can use these terms correctly in context.

Tradeoff articulation means explaining why an architectural choice is correct, not just what it is. If you know that MCP credentials are never exposed inside the session container, the exam-ready version also includes why: prompt injection in the container cannot exfiltrate the credential because it is injected by Anthropic's proxy layer after the request leaves the sandbox.

A practical bridge exercise: for each architectural concept you use in your Claude Code work — a tool permission policy, an MCP server configuration, a session idle event — write one sentence explaining why it is designed that way. That habit of explanation maps directly to how the CCA-F frames its highest-point questions. Our Agent SDK and agentic patterns guide and our exam domains breakdown can help you structure that preparation systematically.

Frequently asked questions

What does the CCA-F exam test about Claude Code architecture?
The CCA-F tests Claude Code architecture at the design level, covering the agent loop, tool-permission flows, and MCP server integration. Exam questions focus on naming constructs correctly, explaining their tradeoffs, and choosing the right architecture for a described scenario — not on hands-on implementation. Daily Claude Code experience covers most of the underlying mechanics.
How does Claude Code's agent loop appear on the CCA-F exam?
On the CCA-F, the agent loop is tested through scenarios involving stalled sessions, multi-tool responses, and resumable pauses. You need to know the loop continues on tool_use, ends at end_turn, and pauses on pause_turn. You also need to know all tool results for a multi-tool turn must return together in one user-role message.
What tool permission knowledge does the CCA-F require?
The CCA-F requires understanding always_allow and always_ask permission policies. always_allow executes tools automatically; always_ask pauses the session awaiting a user.tool_confirmation event from your application. The exam also tests that policies are configurable per-tool via the configs array — not just as a global default — and that always_ask does not deny; it waits.
How is MCP integration tested on the CCA-F exam?
The CCA-F tests the separation between MCP server declaration on the agent (URL only, no credentials) and authentication in a vault attached at session creation. Exam questions ask what happens when a vault credential is invalid, why credentials are injected by Anthropic's proxy layer rather than exposed in the container, and why the two concerns are separated.
Which Claude Code architectural tradeoffs appear most on the CCA-F?
Based on practitioner observation, the CCA-F tests three tradeoffs: bash commands versus dedicated custom tools (auditability and gate-ability), always_allow versus always_ask (throughput versus control), and compaction versus context editing (conversation-length management versus turn-level pruning). Scenario questions require choosing one approach and naming the architectural rationale.

Share this post

Plinth Prep is an independent study resource and is not affiliated with, endorsed by, or sponsored by Anthropic. Practice material is written by Plinth Prep and does not reproduce real exam content.