I Passed the CCA-F Exam on My First Try. Here Are the 5 Ideas That Did Most of the Work

By · · AI Engineering

I sat the Claude Certified Architect - Foundation (CCA-F) exam recently and passed on my first attempt. Going in, I expected a trivia quiz about API parameters. What I got instead was a scenario-heavy test of architectural judgment. Almost every question describes a broken agent system and asks you to diagnose why it broke.

Claude Certified Architect - Foundations badge

You can verify the credential on Credly.

This post is my brain-dump while it's still fresh: the handful of ideas that answered a surprising share of the questions, a walkthrough of each domain, and the question shapes that repeat often enough that you should recognize them instantly.

If you are short on time, read Part 1 and the table in Part 3; Part 2 is the syllabus map for when you sit down to study properly.

In this post

Part 1: The Five Ideas

While preparing across all five domains, I noticed the same principles resurfacing again and again in different costumes. If you internalize these, you have already earned a big chunk of the score.

1. Let stop_reason drive the loop, never the prose

When you build an agentic loop, the model's text output should never act as a control signal. The API hands you a machine-readable field for that purpose: stop_reason. A value of tool_use means run the requested tool and go around again, while end_turn means the work is finished.

The exam loves offering tempting distractors here, such as scanning the reply for a sentence like "task complete", or capping the loop at a hard-coded number of iterations. Both are traps. Any answer that infers loop state from natural language is wrong by design.

Example 1: the correct approach

Question 1. How can you tell if Claude wants to make another tool call in a conversation?

  • A. Parse the response text for phrases like "I need to use a tool"
  • B. Look at the stop_reason field for "tool_use"
  • C. Check whether the response contains a JSON code block
  • D. Count how many turns have elapsed in the conversation

Answer: B. The API returns a machine-readable stop_reason field. When Claude wants to invoke a tool it is set to tool_use, and when the work is done it is end_turn. Text output is generated prose and is never a reliable control signal.

Example 2: spot the wrong approach

Question 2. Your agentic loop occasionally exits before finishing multi-step tasks. The termination code is if "task complete" in response.text.lower(): break. A colleague suggests adding if iterations > 5: break as a safety net. What should the termination condition be?

  • A. Keep the text check but add more phrase variations ("done", "finished", "completed")
  • B. Use the iteration cap as the primary termination condition
  • C. Terminate when stop_reason == "end_turn", continuing (and executing tools) while it is "tool_use"
  • D. Ask Claude at the end of each turn "are you finished?" and parse the yes/no

Answer: C. Options A, B, and D are the same anti-pattern in different clothes: inferring loop state from natural language or arbitrary limits. A phrase check breaks the moment Claude words things differently, and a fixed cap either truncates real work or wastes turns.

2. Prompt instructions fail a small percentage of the time, and code doesn't

An instruction in a system prompt is probabilistic. You can write "ALWAYS verify the customer before issuing a refund" in bold capitals and it will still get skipped in a small percentage of runs. Expect to see this tested several times in one sitting.

For anything involving money, identity, or irreversible actions, the correct architecture puts a hard gate in code: a hook or precondition check that refuses to let the sensitive call execute until its prerequisite has happened. Whenever a question says a prompt rule usually works but occasionally fails, rewording the prompt is always the wrong answer, and moving the rule into programmatic enforcement is always the right one.

Example 1: the correct approach

Question 1. Your coordinator agent reasons correctly about delegation ("I should spawn a research subagent for this") but never actually spawns one. AgentDefinitions are configured correctly. What is the most likely cause?

  • A. The coordinator's system prompt doesn't list the available subagent types
  • B. The coordinator's allowedTools configuration doesn't include Task, so it cannot invoke the tool required to spawn subagents
  • C. The max_tokens setting truncates the Task tool invocation
  • D. Subagent spawning requires a separate API key scope

Answer: B. This shows enforcement working as designed. allowedTools is a programmatic gate, and no amount of reasoning in the prompt gets past it; the capability has to be granted in configuration, not described in text.

Example 2: spot the wrong approach

Question 2. Your refund agent's system prompt says "ALWAYS call get_customer to verify identity before calling process_refund." In production, 3% of refunds still process without verification. What is the correct fix?

  • A. Rewrite the instruction in stronger language with capitalization and repetition
  • B. Move the instruction to the top of the system prompt where it gets more attention
  • C. Add a PreToolUse hook on process_refund that blocks execution unless get_customer succeeded earlier in the session
  • D. Add few-shot examples demonstrating the verify-then-refund sequence

Answer: C. Options A, B, and D can all reduce the failure rate but cannot make it zero, because prompt instructions are probabilistic. For money, identity, and irreversible actions, the exam always wants the programmatic gate. Stronger wording is the designated wrong answer whenever a question mentions a residual failure percentage.

3. A subagent knows nothing you didn't tell it

Spawning a subagent creates a blank slate. It does not see the coordinator's conversation, its earlier findings, or anything another subagent produced, unless the coordinator explicitly copies that material into the subagent's prompt.

This bites people constantly in real systems, which is exactly why the exam keeps probing it. Any scenario where a worker agent ignores previous results or starts over from zero has one root cause: the coordinator failed to hand the context over explicitly.

Example 1: the correct approach

Question 1. Your agent spent 25 minutes exploring a game engine's rendering subsystem. An engineer now asks it to explore how the physics engine integrates with rendering. Recent responses reference "typical rendering patterns" instead of the specific VulkanPipeline and FrameGraph classes discovered earlier. What's the most effective approach?

  • A. Continue in the current context with more targeted prompts referencing the classes by name
  • B. Summarize key rendering findings, then spawn a subagent for physics exploration with that summary in its initial context
  • C. Spawn a subagent to explore physics independently, then manually synthesize its findings afterward
  • D. Clear the context completely and start fresh from the file paths listed in CLAUDE.md

Answer: B. The context has degraded, so a fresh subagent is right, but only if the accumulated findings are distilled and handed over explicitly. Option C is the trap: the independent subagent starts blind and duplicates 25 minutes of work.

Example 2: spot the wrong approach

Question 2. A coordinator researches a company, finds its latest earnings report, then spawns an analysis subagent with the prompt "Analyze this company's financial health." The subagent responds that it has no financial data and searches from scratch. Why?

  • A. The subagent's model tier is too small to retain financial data
  • B. Subagents share the coordinator's conversation history, so this indicates a session bug
  • C. Subagents start with a blank context; the coordinator must include the earnings findings in the subagent's prompt
  • D. The subagent needs the Read tool enabled to access the coordinator's memory

Answer: C. Option B is the trap, because it describes an inheritance model that doesn't exist. There is no shared memory or automatic context forwarding; whatever the subagent needs must be written into its prompt.

4. Claude picks tools by reading their descriptions, so write them like documentation

Tool selection works by comparing the request against each tool's description text. If get_customer and get_account_info both say "retrieves customer data", Claude has no basis to choose correctly, and it won't. The same problem shows up with near-twins like analyze_content versus analyze_document.

The remedy the exam always points to is richer descriptions rather than fewer tools: state what the tool covers, when to reach for it, when to avoid it, the edge cases it handles, and how it differs from its lookalike siblings.

Example 1: the correct approach

Question 1. After adding an MCP server with refactoring tools (extract_function, rename_variable, inline_function), the agent still uses Bash sed for refactoring. The server is healthy. Each MCP tool has a minimal description like "extract_function: Extracts a function from code." What's the most effective fix?

  • A. Implement a request classifier that routes refactoring requests to the MCP server automatically
  • B. Remove the Write tool so the agent must use the MCP tools
  • C. Accept it, since simpler tools like sed are more predictable
  • D. Enhance the MCP tool descriptions to explain when each tool is preferable to text manipulation and clarify expected inputs and outputs

Answer: D. Claude selects tools by reading their descriptions, and a one-line description gives it no reason to prefer the specialized tool over familiar text manipulation. Richer descriptions fix selection at the source, while A and B fight the symptom with external machinery.

Example 2: spot the wrong approach

Question 2. A multi-agent research system gives every subagent access to all 18 tools across search, analysis, and report generation. Tool selection is unreliable. What is the primary cause?

  • A. The agents' role descriptions conflict with having access to tools outside that role
  • B. Choosing from 18 tools instead of 4-5 relevant ones increases decision complexity beyond reliable selection thresholds
  • C. The coordinator cannot track which capabilities each subagent has
  • D. The tool definitions consume too much context window space

Answer: B. The anti-pattern here is over-provisioning: giving every agent every tool. Selection accuracy degrades as the option set grows, especially when descriptions overlap, so scope each subagent to the handful of tools its role needs.

5. Keep numbers and IDs somewhere summarization can't touch

Long conversations get compressed. Compression turns "$89.99 refund on order #48213 for a defective blender" into "a refund was handled", and the specifics your agent still needs are now gone.

The pattern the exam wants is a dedicated facts block containing order numbers, amounts, dates, and statuses. It lives outside the summarized transcript and gets injected verbatim into every prompt. Narrative history can afford to be lossy; transactional facts cannot.

Example 1: the correct approach

Question 1. In extended 30+ minute exploration sessions, the agent gives inconsistent answers about code structure it discussed earlier, and engineers must repeat context. What's the most effective approach?

  • A. Have the agent maintain a scratchpad file that records key findings, referencing it for subsequent questions
  • B. Create summaries of all source files before exploration begins and load only those
  • C. Switch to a higher-capacity model tier for more context window space
  • D. Implement automatic context clearing every 15 minutes

Answer: A. Verified facts get externalized to a persistent store that sits outside the noisy, growing conversation history. This is the same principle as the case-facts block: durable facts live where compression and drift cannot touch them. C only delays the problem, and D destroys useful history.

Example 2: spot the wrong approach

Question 2. A support agent uses progressive summarization for long conversations. After 40 turns, a customer asks "what was the refund amount again?" and the agent answers "a refund was processed" without the amount. The original turn said "$89.99 refund on order #48213." What went wrong, and what is the fix?

  • A. The summarization prompt needs an instruction to "keep important details"
  • B. Transactional facts (amounts, order numbers, dates, statuses) were summarized away; store them in a case-facts block outside the summarized history and inject it verbatim into every prompt
  • C. Summarization should be disabled entirely for support conversations
  • D. The agent should re-ask the customer for the order number when details are missing

Answer: B. Option A is the trap, because "keep important details" is itself a prompt instruction with a failure rate, and the summarizer cannot reliably know which details are load-bearing. The expected design separates lossy narrative history from a verbatim facts store. C throws away the benefit of context management entirely, and D pushes the system's failure onto the customer.

Part 2: The Exam, Domain by Domain

Domain 1: Agentic Architecture (27%)

Over a quarter of the questions live in this domain. Loop mechanics get tested most directly: call the model, check stop_reason, execute tools, and append the tool results back into the message history before the next call. Forgetting that last append step is a named anti-pattern, alongside text-based completion detection and fixed iteration ceilings.

Multi-agent coordination questions favor a hub-and-spoke topology, where one coordinator owns routing and error handling. A recurring scenario gives you a research report with a glaring blind spot, such as a whole region missing or an entire category ignored. The expected diagnosis is nearly always that the coordinator decomposed the task too narrowly rather than that a subagent malfunctioned. Context handoff questions come down to mental model #3 above: pass it explicitly, every time.

Hooks round out the domain. PreToolUse and PostToolUse hooks enforce policy, normalize outputs, and produce audit logs, and well-designed ones tolerate nulls and unexpected formats gracefully instead of throwing exceptions.

Domain 2: Tool Design & MCP (18%)

This domain asks how you make Claude reliable through the tools you give it.

Know where MCP servers run: local stdio transport suits desktop use, while remote HTTP/SSE suits web deployments. You should also understand how resources and prompts differ from tools and where each fits.

Tool descriptions are the most-tested concept in the domain, covered in mental model #4. Vague descriptions cause wrong tool calls, and the fix is always more context in the description.

Error handling has a clear expected answer too: tools should hand back structured error payloads rather than raising exceptions, because Claude can only recover from a failure it can read. And validate and sanitize input parameters before executing anything, which matters for correctness and for security at the same time.

Domain 3: Claude Code (20%)

This is product-specific knowledge, so hands-on time pays off more than reading does.

Headless operation comes up often: the --print flag runs Claude Code non-interactively for CI/CD, --resume continues a prior session, and exit codes make it scriptable.

CLAUDE.md files provide project context that loads automatically and resolves hierarchically across the repository root, subdirectories, and your home directory. Keep them maintained, because outdated instructions actively mislead and are worse than having none.

Permission scoping with --allowedTools restricts the tool surface, and this is the mechanism for safely constraining automated runs. Custom slash commands live in .claude/commands/, with $ARGUMENTS for parameterized input. Hooks also reappear here, applying the Domain 1 concept to Claude Code's own tool-execution lifecycle.

Domain 4: Prompt Engineering (20%)

This is the craft domain, covering what separates a prompt that mostly works from one that always works.

Know the split between system and user turns: persistent role and behavior belong in the system prompt, while anything dynamic, such as retrieved documents or user records, goes in the user turn.

Pin down the output format explicitly. Saying "return a list" leaves too much open; saying "return a JSON array of objects with fields id, score, and reason" gives the model a contract to satisfy, and the exam rewards the latter.

Few-shot examples shape behavior more dependably than instructions alone, especially for format compliance and tricky edge cases. Chain-of-thought reasoning boosts accuracy on genuinely complex multi-stage problems, and the exam also checks that you know when it adds nothing but token cost.

For injection defense, treat everything external as untrusted data: user input, scraped pages, and tool output alike. Fence it off structurally, for example with XML tags, so it can never masquerade as instructions.

Domain 5: Context & Reliability (15%)

This domain covers what happens in production when conversations get long and context windows get tight.

The expected approach to window management pairs progressive summarization of the narrative with the verbatim facts block from mental model #5 for anything transactional.

Parallel versus sequential processing also comes up: emitting several tool calls in a single response runs them concurrently, while spreading them across turns serializes them. The exam tests whether you know which fits which workload.

Graceful degradation questions ask what gets compressed and what gets preserved word-for-word when context runs low. Make that decision deliberately rather than letting the summarizer decide for you.

Part 3: Answer on Reflex

Throughout my preparation, the same setups kept reappearing in practice questions. Train yourself to answer these on reflex:

When the scenario says... The answer is...
"It still fails ~3% of the time despite the prompt instruction" Programmatic enforcement, never stronger wording
"The subagent disregarded earlier findings" The coordinator never passed the context explicitly
"Claude keeps invoking the wrong tool" Descriptions are too similar; make them specific and contrastive
"The final report omits an obvious area" The coordinator's task decomposition was too narrow
"The order number / amount vanished mid-conversation" Summarization consumed it; use a verbatim case-facts block
"How do subagents run in parallel?" Multiple tool calls emitted in one response

Closing thoughts

More than memorization of the docs, the CCA-F tests whether you have built or debugged enough agent systems to recognize the failure mode from the symptom. If you can read "works 97% of the time" and immediately understand that the remaining 3% is the whole problem, you are most of the way there.

Build a small agent loop yourself, break it in each of the ways above, and the exam will feel less like a test and more like a highlights reel of bugs you have already fixed. Good luck, and if you are sitting it soon, remember to check stop_reason.

As for me, I have already started preparing for the next level: the CCA-P (Claude Certified Architect - Professional) exam. Once I sit it, I will write up how it differs from the Foundation level and what I would study differently the second time around. If you are working toward either level, I would genuinely like to hear which of these five ideas showed up in your questions.