Hardest CCA-F Exam Topics: What 1,300+ Practice Attempts Show [2026]

Which parts of the Claude Certified Architect - Foundations (CCA-F) exam actually cost people points? We pulled the answer logs from 1,343 completed CCA-F practice attempts on preporato.com, split them by domain, question pattern, and attempt number, and read the eight lowest-scoring questions in full to see what candidates keep getting wrong. The short version: domain accuracy is flat, between 77% and 80% across all five domains, so there is no single weak domain to cram. The real signal sits in a few specific question patterns in Tool Design & MCP Integration, Claude Code Configuration & Workflows, and Agentic Architecture & Orchestration, where accuracy falls to 32-47%. This article teaches the concept behind each pattern and turns the learning-curve and score-distribution data into a plan for how many practice tests to schedule before exam day.

The headline finding: CCA-F difficulty is spread evenly

The strongest domain in the data, Context Management & Reliability, sits at 80.0% accuracy. The weakest, Prompt Engineering & Structured Output, sits at 77.1%. That is a 2.9-point spread across five domains, each backed by 12,000 to 21,000 recorded answers. The gap is real, but it is small enough that studying one domain harder than the others will not move your score much. CCA-F is built as a blueprint exam where every domain is tested at roughly the same altitude (foundations-level implementation decisions), and the data agrees with that design.

The picture changes when you drop from the domain level to the question level. The eight lowest-scoring questions on Preporato's CCA-F tests land between 31.8% and 47.2% accuracy, and they cluster around a small number of concepts: how Claude Code scopes instructions to parts of a repository, what a skill's frontmatter can and cannot declare, how the built-in Edit tool handles a non-unique match, how an orchestrator should detect a stalled subagent, and when decomposing work into subagents stops paying for itself. Four of the eight live in Claude Code Configuration & Workflows, and three of those four are the same monorepo scenario asked three ways. Fix five concepts and you have addressed the whole bottom of the table.

Two things stand out in that table. Domain weight has no visible relationship to accuracy: the heaviest domain (Agentic Architecture, 27%) scores in the middle and the lightest (Context Management, 15%) scores highest. And the last column shows where the pain is: the two questions tied at 31.8% sit in domains whose overall accuracy is a perfectly ordinary 78%. Averages hide the concepts that produce wrong answers.

Where the difficulty hides: the eight lowest-scoring questions

The table below lists the eight lowest-accuracy questions across all six CCA-F tests. The concept column paraphrases what the question tests; the questions themselves and their options are paid content and stay on the test.

Every row has fewer than 500 answers, so the ordering within a few points is noise. The clustering is the point. The next sections take the three weakest domains in order, then the two agentic questions that outrank everything in them.

Weakest domain: Prompt Engineering & Structured Output (77.1%)

This domain covers explicit criteria versus vague guidance, few-shot prompting (giving the model two to four concrete examples of the output you want), structured output through tool_use with a JSON schema (declaring a tool whose input schema is the shape you want back, so the model must fill it), validation and retry loops for extraction, Batch API constraints (asynchronous bulk requests with a 24-hour window and no multi-turn), multi-instance review, and nullable fields and enums for uncertain data. At 77.1% it is the weakest domain by a hair, and its lowest question (44.2%) is about the boundary between structure and idiom.

What trips people up: exact pattern matching in generated code

The scenario, paraphrased: a team uses Claude to generate new HTTP handlers. They wrote a careful prose specification of their conventions (which error class to throw, the response envelope, the middleware order), yet every generated handler drifts in small ways: a different constant name here, an envelope key nested one level off there. Which prompting technique closes the gap?

The winning move is to hand Claude one real, working handler from the codebase as a reference example, annotated to mark which lines are the pattern to copy and which are specific to that endpoint. Prose describes a pattern in the abstract, while a working example shows the exact constant, the exact import, and the exact try/catch shape. This is few-shot prompting applied to code, and it is the exam's default answer whenever a stem says "exactly matches" or "subtle deviations".

The alternatives that attract most of the wrong answers are reasonable techniques misapplied. A longer standards section in CLAUDE.md (the markdown instruction file Claude Code loads at session start) keeps the specification in prose, so the same drift persists. Forcing output through a tool_use JSON schema guarantees the structure of what comes back, such as the presence of an error handler field, but a schema has no way to require a particular error class or idiom inside a code block. And a two-pass approach, where Claude first summarizes the codebase's patterns and then generates from its own summary, inserts a lossy intermediate step: the summary can paraphrase away exactly the details that mattered.

The heuristic to carry into the exam: "must be valid JSON with these fields" points to a schema, and "must look like our code" points to an annotated example.

How to study it

Work through Structured Output & Prompt Engineering for Claude (CCA-F), which ranks the ways to get reliable JSON from best to worst and separates the format problem from the content problem. Then drill the domain's decision points with the CCA-F practice questions with explanations, which include fresh Prompt Engineering scenarios.

Second weakest: Claude Code Configuration & Workflows (78.4%)

This domain covers the CLAUDE.md hierarchy (user, project, and directory levels), skills and their frontmatter options, path-specific rules in .claude/rules/, Plan Mode (read-only exploration before any edits) versus direct execution, CI/CD integration with the -p headless flag, independent review sessions, and team-level versus user-level configuration. It contributes four of the eight hardest questions, split across two concepts.

What trips people up: the monorepo scoping cluster (31.8%, 46.8%, 47.2%)

Three of the eight hardest questions describe the same situation with small variations: one repository holds a React frontend, a Python backend, and sometimes a Terraform (infrastructure-as-code) directory. Each area has its own conventions. How do you configure Claude Code so that React rules apply during frontend work and stay out of the way during backend work?

There are two legitimate mechanisms, and both are on the exam blueprint. The first is a per-directory CLAUDE.md. Claude Code loads the CLAUDE.md files from your working directory up through its parent directories at launch, and it loads a CLAUDE.md that sits inside a subdirectory on demand, the moment it reads a file in that subdirectory. So frontend/CLAUDE.md enters context when Claude touches frontend files and stays out otherwise. The second is a path-scoped rule: a markdown file inside the project's .claude/rules/ directory whose YAML frontmatter (the header block between --- markers) has a paths: field listing glob patterns (wildcard path patterns such as frontend/**/*.tsx). A rule with paths: loads only when Claude works with a matching file; a rule without paths: loads every session.

Anthropic's own monorepo guidance draws the line like this. Reach for per-directory CLAUDE.md files when each directory's owners maintain their own conventions and want them versioned alongside the code they describe. Reach for path-scoped rules in .claude/rules/ when you want all conventions in one central place, or when the same rule applies to many scattered paths or specific file types (all test files, all .tsx files) regardless of directory. Both approaches layer on top of a root CLAUDE.md that carries repository-wide rules such as commit conventions. You can verify which files loaded in a session by running /context and checking the memory files list.

Accuracy on this cluster is low because candidates choose between the two by instinct. Read the stem for two signals: granularity and ownership. Whole-directory conventions owned by the team that lives in that directory point to a CLAUDE.md inside it. File-pattern precision, or a requirement to keep every rule in one place, points to .claude/rules/ with globs. Both mechanisms beat the three distractors that appear in every variant: splitting the monorepo into separate repositories to satisfy a configuration file, running one Claude Code session per directory (which breaks the cross-cutting refactor that touches a backend schema and its frontend type together), and stacking every convention into the root file behind "if you are in frontend, then..." conditionals, which loads every rule on every turn, spends context, and invites React patterns to leak into Python.

What trips people up: the skill argument field (43.7%)

The scenario, paraphrased: a team writes a skill (a SKILL.md file under .claude/skills/<name>/ that packages a reusable procedure and can be invoked with /name) for deploying to a staging environment. The skill only makes sense with a target environment supplied by the developer. Which frontmatter field tells the developer what to provide?

The answer is argument-hint. It is the frontmatter field that surfaces the expected arguments during autocomplete, for example [environment], and whatever the developer types after the command reaches the skill body through $ARGUMENTS (or $1, $2 for positional access, or named arguments declared with the arguments field). The distractors work by inventing plausible fields: there is no required-params key and no input-schema key in skill frontmatter, and an unknown key is simply ignored, so a skill that relies on one runs without ever asking for the environment. Writing "please specify the environment" in the skill body asks after the procedure has already started, which is the wrong moment for a deployment target.

The broader lesson is that Claude Code's frontmatter vocabulary is finite and specific. The documented SKILL.md fields include name, description, argument-hint, arguments, disable-model-invocation, user-invocable, allowed-tools, model, context, agent, hooks, and paths. Any option that names a field outside that list is a distractor.

How to study it

Read the CLAUDE.md context management guide for the loading order and the per-directory behavior, then Claude Code Skills & Slash Commands for the frontmatter reference and the $ARGUMENTS mechanics. The permissions and settings precedence guide covers the adjacent question of which settings file wins, and the hooks guide covers the point where advisory instructions stop and enforcement begins.

Third weakest: Tool Design & MCP Integration (78.8%)

This domain covers tool description writing, the four-to-five-tools-per-agent guideline, the three tool_choice values (auto, any, and a named tool, which tell the API whether the model may, must, or must-with-this-tool make a tool call), MCP (Model Context Protocol, the open standard for connecting Claude to external tools and data) configuration at project versus user level, environment variable expansion for secrets, structured error responses with a retryable flag, and the built-in tools Grep, Glob, Edit, Read, and Write. Its overall accuracy is unremarkable, and it owns the joint lowest-scoring question on the whole test set.

What trips people up: the Edit tool and a non-unique match (31.8%)

The scenario, paraphrased: Claude Code is asked to rename a function that appears many times in a single file. It calls the built-in Edit tool and the call fails, because the text it asked to replace occurs more than once. What should happen next?

Edit performs exact string replacement: it takes an old_string and a new_string and swaps one for the other, with no regex and no fuzzy matching. It enforces two invariants. The old_string must match the file character for character, and it must appear exactly once. When the string appears more than once, there are two documented escape hatches, and the scenario decides which one applies. If you want to change one occurrence, extend old_string with enough surrounding lines to pin down that occurrence. If you want to change every occurrence, which is what a rename means, set replace_all: true and let one call do the job.

The distractors are all things a careful engineer might do. Switching to Write, which replaces the whole file, is risky in exactly the way the exam likes to punish: any imperfection in the rewritten content silently destroys unrelated code, and Write is the fallback for creating files or for the rare edit that Edit cannot express. Running Grep to list every occurrence and then issuing one Edit per line reimplements replace_all by hand, slower and prone to drift if the file changes between the search and the edits. Padding context one occurrence at a time works for a single change and collapses into dozens of hand-curated calls for a rename.

Why does a question this mechanical score 31.8%? Because most candidates learn the uniqueness rule and stop there. The exam tests the escape hatch as much as the rule. For each built-in tool, know the constraint and the parameter that relaxes it.

How to study it

MCP Tool Design Best Practices for Claude Agents covers descriptions, schemas, and error responses, which carry most of this domain's weight. The built-in tools quick reference in the CCA-F cheat sheet is worth memorizing line by line, including the Edit and Write rows.

The agentic architecture questions that outrank all of them

Agentic Architecture & Orchestration is the heaviest domain at 27% of the exam and sits fourth in accuracy at 79.2%. It still produces the third and fourth hardest questions on the test set, both about the same instinct: adding structure to an agent system when the structure does not pay.

The coordinator that keeps re-asking (35.9%)

The scenario, paraphrased: an orchestrator agent (the coordinating agent that splits work and delegates it) hands a task to a subagent (a separate Claude instance with its own context window), gets back a vague "I need more information", re-sends the identical prompt, gets the identical reply, and repeats. The team already enforces an iteration cap of 20 turns (a hard limit on how many times the loop may run), and the system still wastes minutes and money before it hits the cap. What architectural change fixes it?

The cap is a backstop, and the fix belongs in the orchestrator's loop: progress detection. Compare each subagent response with the previous one, using a string similarity check or a structured progress field the subagent must fill in, and when consecutive responses are substantively the same, change strategy. Reformulate the task with more context, hand it to a different subagent, or escalate to a human with a summary of what was tried. This catches a stall on the second identical response instead of the twentieth, and it leaves genuinely long multi-step tasks alone because those produce changing outputs.

Each distractor fails on a specific axis. Cutting the cap from 20 to 5 bounds the waste but still cannot tell productive iteration from stagnation, so it also kills legitimate long tasks. Improving the subagent's prompt with examples of good clarifying responses raises quality at the leaf and leaves the coordinator blind, which is a layer mismatch. And running a second LLM over the logs to spot loops in real time spends model calls on a comparison that three lines of code can perform. The principle the exam wants stated: "no progress after multiple attempts" is an escalation trigger, and progress is measured objectively.

One agent or five (42.3%)

The scenario, paraphrased: a document pipeline reads a PDF, extracts key fields, checks them against a database, writes a summary, and files the result. A junior engineer proposes one subagent per step. What guidance should the architect give?

Keep it to one agent with five tools. Every step depends on the previous step's output, so each subagent boundary would re-serialize nearly the entire document context, add a round trip, and buy no isolation in return. Subagents earn their cost when the pieces of work are independent, need different tool sets or permissions, or can run in parallel. A strictly sequential, tightly coupled pipeline is the worst case for decomposition. The intermediate options fail for the same reason: a two-subagent split still hands nearly the whole payload across the boundary, and a queue-backed stage-per-process design brings message-queue infrastructure to bear on a single document.

Candidates miss this one because "single responsibility" and "microservices" are good instincts elsewhere. On CCA-F, the simplest architecture that meets the stated requirement wins, and decomposition needs a reason.

How to study it

Claude Code Subagents & Orchestration Patterns explains why delegation beats one big context when it does and what it costs when it does not. Mistake 1 in Common CCA-F Exam Mistakes to Avoid is this exact trap.

Single-answer versus multiple-response: what this dataset can say

Every one of the 87,295 recorded answers in this window comes from a single-answer multiple-choice question, at 78.6% overall accuracy, so the data cannot report a split between single-answer and "Select TWO" formats. Do not read that as a statement about the real exam's question mix; the CCA-F exam format guide covers what to expect on question styles. The practical advice stands regardless of the data: read any stem that asks for two answers twice, and mark exactly two.

Learning curve: how many practice tests to plan

Each completed attempt carries its position in that user's sequence (first, second, and so on), so we can look at how scores move with practice.

The shape is a step, then a plateau. The median jumps seven points between the first attempt (83) and the second (90), then holds at 89 through the third, fourth, and fifth attempts. The sixth attempt dips to 86, on 83 users, which is a small enough group that a handful of tired or rushed sessions moves the number; do not build a theory on it. About 71% of users came back for a second attempt and 42% reached a fourth.

The takeaway on planning: schedule three to four full-length attempts. The first is a diagnostic. The second captures almost all of the measurable gain, which is where reading the explanations for every wrong answer on the first test pays off. The third and fourth confirm the plateau under a timer. After that, the score data says a fifth or sixth attempt adds little on its own; the remaining gains come from drilling the specific patterns above and from the flashcard deck.

Score distribution: two populations

The median attempt scored 87 while the mean scored 78.1, and the table shows why. Three quarters of attempts land at 80 or above, and 82.8% clear the 72% line. Almost nobody sits in the 50-71 band (4.9% combined). Then 12.4% of attempts fall below 50. That is a bimodal distribution (two clusters): a large prepared population and a smaller cold population, with very little in between. The dataset does not say whether the sub-50 attempts are true first looks, abandoned sessions marked complete, or people using a test as a reading exercise, so treat the mean as a curiosity and the median as the number to compare yourself against.

One more number from the same logs: the median attempt took 58 minutes for 65 questions. The real exam gives you 120 minutes for 60. If your practice pace is anywhere near the median, the exam clock is generous, and the surplus is best spent re-reading stems for scoping words (whole directory or file pattern, one occurrence or all, independent steps or dependent ones), because that is where the eight hardest questions turn.

How to use this data: a three-week plan

The six CCA-F practice tests and the flashcard deck are included in Preporato Pro; see pricing for the current plan options, or start with the free sampler to check the question style first.

Frequently asked questions

Key takeaways

Next steps

Take a timed baseline on the CCA-F practice tests, then work the eight concepts above using the CCA-F cheat sheet and the 30-day CCA-F study plan as your schedule. When two consecutive attempts land at 85 or better with every miss explained, you are at the plateau this data describes, and it is time to book.

Sources:

• Claude Code docs: How Claude remembers your project (CLAUDE.md and .claude/rules/)
• Claude Code docs: Set up Claude Code in a monorepo or large codebase
• Claude Code docs: Extend Claude with skills (frontmatter reference)
• Claude Code docs: Tools reference (Edit and Write)
• Anthropic Partner Academy: Claude Certified Architect - Foundations certification