CCA-F Practice Questions With Explanations: 20 Free Scenarios [2026]

Here are twenty free CCA-F practice questions written the way the Claude Certified Architect - Foundations exam asks them: a short production scenario, an implementation decision to make, four options that all describe real Claude features, and one option that fits this situation best. Every question carries a domain tag, an answer, and an explanation that covers why the right option wins and why each distractor loses. The set follows the published blueprint (five questions on agentic architecture, four each on Claude Code, prompt engineering, and tool design, three on context management), and five of the twenty are "Select TWO" items, close to the share you should expect on the real exam. Work through them untimed first, then use the scoring rubric to decide where to study next.

How to use these 20 questions

CCA-F items are best-fit questions. Every option is usually a real feature or a real pattern; the wrong ones are wrong for the scenario in front of you, so read the stem for constraints (a shared team, a hard "never", a user waiting on the result) before you look at the options. When two options both seem defensible, the reliable tiebreaker across all five domains is that programmatic enforcement (a schema, a hook, a stop_reason check, a manifest file) beats prompt-based guidance.

Score yourself honestly, counting a "Select TWO" item as correct only when both picks are right:

• 17 or more out of 20: you are ready for timed full-length practice; book once you clear that consistently.
• 14 to 16: borderline. Read the explanations for every miss, then study the domains you missed most.
• Under 14: work through the complete guide and the topic articles linked in the closing table before more questions.

The real exam gives you 60 questions in 120 minutes, about two minutes each, so a reasonable target for this set is 40 minutes.

Agentic Architecture & Orchestration (27%): questions 1-5

Question 1

Domain: Agentic Architecture & Orchestration (27%)

An insurance company runs a claims-intake system as a hub-and-spoke (a coordinator agent that routes work to specialized subagents). The coordinator collects the policy number and incident details from the customer, then delegates to a fraud-screening subagent. In testing, the subagent repeatedly reports "no policy number provided" even though the coordinator confirmed it two turns earlier. What is the likely cause and the correct fix?

• A. Subagents start with a fresh context; the coordinator must include the policy number and incident details in the delegation prompt.
• B. The coordinator's context was truncated; raise its max_tokens so the earlier turns stay in the conversation history it sends.
• C. The subagent lacks the lookup tools; grant it the coordinator's full tool set so it can re-query the policy system itself.
• D. Fraud screening is too small a task for delegation; fold it back into the coordinator so the hand-off never has to happen.

Answer: A

Subagents do not inherit the parent's conversation. Context isolation is deliberate: it keeps each worker's window clean and predictable, and it means everything the worker needs must be passed explicitly in the task prompt. Option B misdiagnoses the problem, since max_tokens limits output length and has nothing to do with what a subagent sees. Option C adds tools and repeated lookups where a single passed value would do, and pushes the subagent's tool count up. Option D removes a sound separation of concerns to work around a bug that one line in the delegation prompt fixes.

Question 2

Domain: Agentic Architecture & Orchestration (27%)

A compliance team's agent produces a weekly regulatory digest. A coordinator delegates three research jobs (EU, US, and UK rule changes) to subagents, then a fourth subagent writes the digest from all three sets of findings. The current design runs the four subagents strictly one after another and takes forty minutes. Which TWO changes are correct? (Select TWO)

• A. Emit the three regional research tasks in a single coordinator turn so they run concurrently.
• B. Have the coordinator wait for all three regional results before launching the digest-writing subagent.
• C. Let whichever regional subagent finishes first start the digest, and patch in the remaining regions later.
• D. Pass the coordinator's full conversation to each regional subagent so they can align their findings.

Answer: A and B

The three regional jobs are independent, so they belong in one coordinator turn as parallel task calls; wall-clock time drops to roughly the slowest region. The digest depends on all three results, so it stays sequential behind them, which is option B. Option C launches a dependent step before its inputs exist and produces a digest that must be rewritten. Option D breaks context isolation: subagents should receive only the scoped brief they need, and sharing the whole conversation adds cost and noise without improving coordination, because merging results is the coordinator's job.

Question 3

Domain: Agentic Architecture & Orchestration (27%)

An IT helpdesk agent resets passwords, unlocks accounts, and assigns software licenses. The operations lead wants a policy for when the agent hands a ticket to a human. Tickets sometimes stall when the agent retries the same unlock call with the same arguments and nothing changes. Which escalation trigger should be implemented programmatically?

• A. Escalate when the same tool is called repeatedly with identical arguments and no observed state change.
• B. Escalate when the model's self-reported confidence for its next action drops below a fixed threshold you set.
• C. Escalate when a sentiment classifier flags negative tone in two consecutive messages from the customer.
• D. Escalate whenever resolving the ticket requires calling more than one tool during a single session.

Answer: A

No progress after N attempts is one of the three reliable triggers (with an explicit request for a human and an ambiguous policy), and it is observable from the tool log without asking the model anything. Option B relies on self-reported confidence, which is poorly calibrated. Option C uses sentiment, which fires on informal language and misses polite frustration. Option D confuses complexity with ambiguity: a multi-tool ticket that sits inside clear policy is exactly the work the agent should finish on its own.

Question 4

Domain: Agentic Architecture & Orchestration (27%)

A support operation runs one Claude Code investigation session per fraud case. Day-shift analysts stop mid-investigation, and the night shift must continue from the exact point where they left off, with the full history of tool calls and findings intact. Separately, a senior analyst wants to test an alternative theory on one case without disturbing the main line of investigation. Which pairing is correct?

• A. Continue with --resume on the named session; use fork_session for the alternative theory.
• B. Start a fresh session and paste a summary for the night shift; use --resume for the alternative theory.
• C. Use fork_session for the night-shift hand-off; start a fresh session for the alternative theory.
• D. Keep one long-running process open across both shifts; use --resume for the alternative theory.

Answer: A

Resuming a named session restores the conversation history exactly, which is what a shift hand-off needs. Forking creates an independent branch from the same baseline, so the alternative theory can diverge without writing back to the main line. Option B throws away tool history and uses resume for a job that needs isolation. Option C reverses the two: a fork for the hand-off creates a second branch nobody merges, and a fresh session for the theory loses the shared baseline. Option D depends on a process never dying, a fragile assumption for a multi-day case.

Question 5

Domain: Agentic Architecture & Orchestration (27%)

A logistics company's agent re-plans routes when a truck breaks down. The agentic loop (send a message, run any tool Claude requests, send the result back, repeat) calls a routing tool, a driver-notification tool, and a fleet database. In production it sometimes stops before drivers are notified, and sometimes keeps calling the routing tool after a plan is final. How should the loop decide when to continue and when to stop?

• A. Continue while stop_reason is tool_use, stop on end_turn, and treat max_tokens as a truncation case to handle separately.
• B. Stop when the assistant text contains a phrase such as "route finalized", with a cap of eight iterations as the fallback.
• C. Stop after a fixed number of iterations chosen from the average tool-call count observed during load testing.
• D. Ask the model at the end of each turn whether the plan is finished, and stop the loop when it answers yes.

Answer: A

The Messages API returns a deterministic stop_reason on every response, and it is the supported signal for loop control: tool_use means run the tool and continue, end_turn means the model is done, and max_tokens means the output was cut off and needs continuation handling. Option B parses free text, which is why drivers sometimes go unnotified (the phrase appears mid-task) and the loop sometimes runs on (the phrase never appears). Option C caps on an average, so long incidents get truncated. Option D turns a self-report into control flow, the same fragility as B with an extra call. Keep an iteration or token budget as a logged safety net only.

Tool Design & MCP Integration (18%): questions 6-9

Question 6

Domain: Tool Design & MCP Integration (18%)

An HR team's pipeline sends every incoming resume to Claude with three tools defined: extract_candidate, check_duplicate, and notify_recruiter. Every resume must produce a structured candidate record on the first call, yet about one response in twenty comes back as a prose summary instead of an extract_candidate call. Which change fixes this most reliably?

• A. Set tool_choice to {"type": "tool", "name": "extract_candidate"} for the extraction call so that tool is always invoked.
• B. Set tool_choice to "any" so the model must call one of the three tools instead of answering in prose.
• C. Keep tool_choice on "auto" and add a system-prompt line stating that every resume must be extracted first.
• D. Remove the other two tools from the request and ask for JSON in the prompt so only extraction is left.

Answer: A

tool_choice controls whether and which tool Claude calls, and forcing a named tool is the programmatic guarantee: the response will be an extract_candidate call that conforms to its input schema. Option B removes prose but still lets the model pick check_duplicate or notify_recruiter on a resume that has not been extracted yet. Option C is prompt-based guidance and remains probabilistic, which is the current failure. Option D drops schema enforcement entirely and relies on prompt-only JSON, which the exam treats as the weakest structured-output approach.

Question 7

Domain: Tool Design & MCP Integration (18%)

A platform team is standardizing Claude Code for twelve engineers. Everyone needs the same Jira MCP server (an external tool server speaking the Model Context Protocol), which authenticates with a token that must never be committed. Several engineers also run personal MCP servers (note-taking, music) that teammates should not inherit. Which TWO configuration decisions are correct? (Select TWO)

• A. Define the Jira server in the project's .mcp.json and reference the token as ${JIRA_TOKEN} from the environment.
• B. Define personal servers in each engineer's user-level ~/.claude.json, outside version control.
• C. Put the real Jira token in .mcp.json and add that file to .gitignore so it stays off the remote.
• D. Have every engineer add the Jira server to their own ~/.claude.json so the token stays on their machine.

Answer: A and B

Project-level .mcp.json is the shared, version-controlled scope, and ${VAR} expansion keeps the secret out of the file, so option A gives the whole team one definition and no leaked token. User-level configuration is the right home for servers only one person wants, which is option B. Option C makes the shared file unshareable and still leaves a plaintext secret on disk. Option D duplicates the team server twelve times and lets it drift; variable expansion already keeps the secret local while the server definition stays shared.

Question 8

Domain: Tool Design & MCP Integration (18%)

A retail support agent has two tools: lookup_customer, described as "Gets customer info", and find_customer, described as "Finds customer data". The first takes an exact customer ID; the second does a fuzzy search on name and email. The agent frequently calls the ID tool with a name and gets a not-found error. What should you change first?

• A. Rewrite each description to name its input (exact ID versus partial name or email), its output, and when the other tool applies.
• B. Rename the tools to get_customer_by_id and search_customers, and leave both descriptions exactly as they are today.
• C. Add a paragraph to the system prompt listing which tool the model should prefer for each kind of customer question it might receive.
• D. Set tool_choice to "any" so the model must commit to one of the two tools instead of guessing between them on every call.

Answer: A

Tool descriptions are the primary routing signal, and these two are near-identical, so the model has nothing to choose on. A description that states input format, output, and a boundary ("for partial names use find_customer") fixes selection at the source. Option B helps only marginally: names carry far less weight than descriptions. Option C moves routing logic into the system prompt, where it competes with everything else and drifts away from the tool definitions. Option D forces a tool call but does nothing to help the model pick the right one.

Question 9

Domain: Tool Design & MCP Integration (18%)

You are writing an MCP tool that charges a card through a payments gateway. The gateway returns HTTP 429 when the merchant is rate-limited and HTTP 403 when the API key lacks the charge permission. Today the tool returns an empty result in both cases, and the agent tells customers the payment "did not go through". How should the tool respond instead?

• A. Return a structured error with an error type, an isRetryable flag (true for 429, false for 403), and what was attempted.
• B. Return a plain string such as "payment error" so the model can explain the failure to the customer in its own words.
• C. Retry inside the tool until the gateway succeeds, so the agent only ever sees a completed charge or a final timeout.
• D. Return an empty result for 429 but raise an exception for 403 so permission problems stop the loop immediately.

Answer: A

Structured errors let the agent decide the next action: back off and retry a transient 429, or stop and escalate a permanent 403. Both outcomes differ from an empty result, which the model reads as "the operation completed and found nothing". Option B is unstructured, so the retry decision falls to free-text interpretation. Option C hides a permission failure behind endless retries and can hang the loop. Option D keeps the silent-empty anti-pattern for the retryable case and crashes the loop on the case that should be reported and escalated cleanly.

Claude Code Configuration & Workflows (20%): questions 10-13

Question 10

Domain: Claude Code Configuration & Workflows (20%)

A platform lead wrote the repository's testing conventions (which runner to use, how to name fixtures) into ~/.claude/CLAUDE.md on their laptop. CLAUDE.md is the instructions file Claude Code loads at start; teammates' sessions ignore the conventions. The lead also keeps a personal preference for terse responses that should never affect anyone else. Which TWO placements are correct? (Select TWO)

• A. Move the testing conventions into the project-root CLAUDE.md (or .claude/CLAUDE.md) and commit it to the repository.
• B. Keep the terse-response preference in ~/.claude/CLAUDE.md, where it applies only to the lead's own sessions.
• C. Have each teammate copy the lead's ~/.claude/CLAUDE.md into their own home directory to pick up the conventions.
• D. Wrap the conventions in a skill that engineers invoke before writing tests, so the file stays out of the repo.

Answer: A and B

User-level CLAUDE.md is personal and never travels with the repository, which is exactly why teammates see nothing. Shared conventions belong at project level, where every clone loads them (A), and personal preferences belong at user level (B). Option C copies files by hand and drifts the moment the lead edits the original. Option D makes always-on conventions depend on someone remembering to invoke a skill, and skills are meant for on-demand procedures, while standing rules belong in CLAUDE.md.

Question 11

Domain: Claude Code Configuration & Workflows (20%)

A fintech team has two hard requirements for Claude Code in its payments repository: the agent must never edit files under migrations/, and the black formatter must run after every edit to a Python file. A CLAUDE.md line for each already exists, and both requirements are still violated in long sessions. Which mechanism enforces them?

• A. A PreToolUse hook matching Edit|Write that exits 2 for migrations/ paths, plus a PostToolUse hook that runs black.
• B. A .claude/rules/ file with paths: migrations/** stating that files in that directory must never be modified.
• C. Moving both requirements to the top of CLAUDE.md, where instructions receive the most attention during a session.
• D. A permission ask rule on Edit so a human approves every file change before Claude Code is allowed to make it.

Answer: A

Hooks are shell commands the Claude Code harness runs at lifecycle events, outside the model's discretion. A PreToolUse hook that exits 2 blocks the tool call and feeds the reason back to Claude, and a PostToolUse hook runs the formatter after every real edit. Option B is still prose, loaded conditionally; it advises and cannot block. Option C improves compliance but stays probabilistic, which is the failure being reported. Option D stops the wrong edits only if the human catches them, slows every change, and does nothing to run black.

Question 12

Domain: Claude Code Configuration & Workflows (20%)

A CI pipeline invokes Claude Code on every pull request to produce a list of review findings that a later job turns into GitHub comments. Some runs hang until the job times out, and on runs that do finish, the parsing step fails on the output. Which invocation fixes both problems?

• A. Run with -p for non-interactive mode and --output-format json, validating the findings against a JSON schema before parsing.
• B. Run interactively under an expect script that answers prompts, and parse the markdown output with regular expressions.
• C. Run with -p and ask in the prompt for "clean JSON only", then parse whatever text comes back on standard output.
• D. Raise the job timeout and keep the current invocation, since the hangs are load-related and unrelated to configuration.

Answer: A

The -p (print) flag makes Claude Code non-interactive, so it never waits for input a pipeline cannot give, and --output-format json produces machine-readable output that a downstream job can parse deterministically; a schema check turns any malformed output into a clear failure. Option B keeps an interactive session alive in a headless job and parses prose. Option C fixes the hang but relies on prompt-only JSON. Option D treats a configuration problem as capacity and leaves the parsing failure in place.

Question 13

Domain: Claude Code Configuration & Workflows (20%)

A security team wants a /dependency-audit skill (a reusable, on-demand instruction set for Claude Code) that scans lockfiles, runs an audit command, and produces a long report. Two constraints: the report's volume must not fill the main conversation, and the skill must never be able to modify files. Which frontmatter satisfies both?

• A. context: fork so the skill runs in an isolated subagent, with allowed-tools limited to Read, Grep, Glob, and Bash.
• B. context: fork with no tool restriction, and a line in the skill body instructing the model to avoid Edit and Write.
• C. Default context with allowed-tools limited to Read and Grep, so the audit output stays in the main conversation.
• D. Default context and no tool restriction, plus a PostToolUse hook that reverts any file changes the skill makes.

Answer: A

context: fork runs the skill in its own context, so the audit's verbose output never lands in the parent conversation, and allowed-tools is the least-privilege boundary that makes file modification impossible where an instruction would only discourage it. Option B leaves the file-writing tools available and asks nicely. Option C removes Bash (needed to run the audit) and keeps every line of output in the main window. Option D lets the edits happen and cleans up afterward, which is both riskier and noisier than preventing them.

Prompt Engineering & Structured Output (20%): questions 14-17

Question 14

Domain: Prompt Engineering & Structured Output (20%)

A procurement platform extracts purchase-order fields with Claude. Two defects recur: about 2% of responses are not parseable JSON, and in another few percent the line-item amounts do not add up to the stated total. The current prompt says "return valid JSON with these fields" and includes six examples. What is the right design?

• A. A tool_use schema for structure, programmatic checks for business rules such as totals, and a retry loop that feeds errors back.
• B. A tool_use schema alone, since schema enforcement guarantees both the shape of the output and the arithmetic inside it.
• C. A stronger prompt instruction about JSON validity, with the example count raised from six to twelve to cover more cases.
• D. A second Claude instance that re-extracts every order, with a rule that accepts a result only when both extractions agree exactly.

Answer: A

Three layers map to the defects: the schema (a JSON Schema attached to a tool definition, so the response must match it) removes malformed JSON, validation code catches totals that do not reconcile, and the retry sends the specific validation error back so the correction is targeted. Option B overstates what a schema does; it enforces syntax (fields and types), never semantics such as sums. Option C keeps the prompt-only approach that is already failing and pushes examples past the 2-4 range where they help. Option D doubles cost on every order and still cannot say which of two disagreeing outputs is right.

Question 15

Domain: Prompt Engineering & Structured Output (20%)

A publisher has two workloads: re-tagging 400,000 archived articles, due within two days, and a writer's assistant that suggests tags in a multi-turn chat while an article is being drafted. Finance wants the Batch API's 50% saving applied wherever it is safe. Which TWO decisions are correct? (Select TWO)

• A. Send the archive re-tagging through the Batch API, since nothing downstream waits on any single result.
• B. Keep the writer's assistant on the real-time Messages API, because it is interactive and multi-turn.
• C. Move the writer's assistant to the Batch API and show a spinner until each tag suggestion returns.
• D. Run the archive through the real-time API with high concurrency so the job finishes in a few hours.

Answer: A and B

The Batch API (asynchronous submission of many requests, processed within a 24-hour window at half price) fits the archive: it is a background job with a two-day deadline, and no user is waiting on it. The assistant fails both Batch constraints at once: someone is waiting on the result, and it needs multi-turn conversation, which the Batch API does not support. Option C blocks a live user on a job that might return in minutes or many hours. Option D pays full price for a workload that gains nothing from real-time delivery.

Question 16

Domain: Prompt Engineering & Structured Output (20%)

A community platform uses Claude to flag posts for moderator review. The prompt says "be careful not to over-flag harmless posts", yet moderators report that most flagged items are benign, and the queue has become unmanageable. Which revision most directly reduces the false positives?

• A. Replace the vague instruction with explicit, testable criteria per flag category, plus 2-4 examples that include borderline posts left unflagged.
• B. Strengthen the wording to "be very conservative and only flag when certain", and repeat it at the start and end of the prompt.
• C. Add fifteen examples covering every category and every edge case the moderation team has recorded this quarter.
• D. Move the classifier to a larger model tier so it can interpret the existing instruction with better judgment on its own.

Answer: A

Vague guidance ("be careful") gives the model nothing measurable, so its threshold floats. Explicit criteria ("flag only if the post contains X, Y, or Z") make each decision checkable, and a few examples showing acceptable borderline content teach what should stay unflagged. Option B is more of the same vagueness, louder. Option C overshoots the 2-4 example range, consumes context, and often produces inconsistent pattern-matching. Option D spends money to compensate for an unclear specification that a bigger model will still read as unclear.

Question 17

Domain: Prompt Engineering & Structured Output (20%)

A real-estate extraction schema has a parking_type enum with garage, street, and none. Listings that say only "parking available" get labeled garage, and downstream valuations are skewed. Some listings say nothing about parking at all, and those must stay distinguishable from the ambiguous ones. How should the schema change?

• A. Add an unclear enum value for ambiguous mentions, keep the field nullable for listings that never mention parking, and route unclear to review.
• B. Make the field nullable and instruct the model to return null whenever the parking type is not stated in exact words in the listing.
• C. Add a system-prompt rule to choose the most common parking type in the listing's neighborhood whenever the text is ambiguous.
• D. Replace the enum with a free-text field so the model can copy the listing's own wording without guessing at a category.

Answer: A

Two different signals need two different values: null for absent information and unclear for information that is present but ambiguous. Giving the model a legitimate way to say "mentioned, type unknown" stops it from forcing a wrong category, and routing those rows to review keeps the valuation clean. Option B collapses both cases into null, so downstream cannot tell "no parking mentioned" from "parking mentioned, type unknown". Option C manufactures data from a plausible-sounding guess. Option D throws away the enum's consistency and hands the classification problem to whoever consumes the free text.

Context Management & Reliability (15%): questions 18-20

Question 18

Domain: Context Management & Reliability (15%)

A due-diligence agent reads vendor contracts of 60 to 90 pages and answers a fixed checklist. Reviewers find that indemnity and limitation-of-liability clauses in the middle third of a contract are missed far more often than clauses near the start or the end. Which change addresses the cause?

• A. Process the contract in per-section passes that extract clause data into a compact record, then run the checklist over the extracted record.
• B. Switch to a model tier with a larger context window and load each full contract plus all of its exhibits in a single call.
• C. Add an instruction to "pay particular attention to the middle sections" and raise the response max_tokens for the checklist.
• D. Ask the model to list every section heading first, then answer the checklist in the same call from the full contract text.

Answer: A

This is the lost-in-the-middle effect: attention is strongest at the start and end of a long context, and material in between is under-weighted. Reducing the context per call (section passes, then a synthesis over the extracts) removes the middle instead of asking the model to try harder. Option B enlarges the very thing causing the problem. Option C is prompt-based guidance against a positional bias, and max_tokens governs output length only. Option D adds structure but keeps the whole contract in one call, so the middle stays the middle.

Question 19

Domain: Context Management & Reliability (15%)

A nightly agent enriches 20,000 product records by calling Claude and two catalog APIs. Records are independent, and the run must finish before the store opens. Last week the process crashed at record 12,400, restarted from record 1, and doubled the night's spend. Which TWO changes give the job reliable crash recovery? (Select TWO)

• A. Write a manifest listing every record ID and its status, and update it as each record completes.
• B. On restart, read the manifest and process only the records not yet marked complete.
• C. Wrap the whole run in a single retry so a failure reruns the batch from the start automatically.
• D. Keep progress in the model's context by asking it to remember which records it has finished.

Answer: A and B

A manifest is the durable, external record of what was done: the task list, per-item status, and any partial results. Reading it on restart is what makes recovery skip completed work instead of repeating it, and the two halves only work together. Option C is what the team effectively has today, and it guarantees the doubled cost. Option D stores state inside a context window that disappears with the crash and asks the model to track something code should track.

Question 20

Domain: Context Management & Reliability (15%)

A claims-adjudication system issues 50,000 automated decisions a day; roughly a third are denials. Ten reviewers can check about 500 decisions daily and currently sample 1% at random. An audit found that denials above a monetary threshold carry four times the error rate of everything else. What should change?

• A. Stratify by risk (high-value denials, novel claim types) and oversample those strata, feeding observed error rates back into sampling and prompts.
• B. Route every denial to human review and let approvals pass through unreviewed, since approvals are the lower-risk half of the volume.
• C. Double the random sample to 2% so more high-value denials are caught without changing the selection rule the reviewers use.
• D. Ask the model to flag the decisions it is unsure about and send only those flagged decisions to the review team each day.

Answer: A

A fixed review budget buys the most quality assurance when it is aimed where errors concentrate, and the audit has already located them. Stratified sampling (reviewing a high share of high-risk outputs and a low share of routine ones) plus error tracking per stratum turns review into a feedback loop for prompts and validation. Option B is over 16,000 items a day for a team that can do 500. Option C stays random, so most of the extra effort lands on low-risk decisions. Option D is self-reported confidence, which is poorly calibrated and skips the errors the model is confident about.

Score yourself and pick your next read

Tally your misses by domain, then use the table. Two or more misses in a domain means that domain gets the next study block; a single miss usually means one concept, so read the explanation again and move on.

The linked articles: subagents and orchestration patterns, MCP tool design best practices, Claude Code hooks explained, CLAUDE.md context management, permissions and settings precedence, and structured output and prompt engineering. For the numbers on where candidates actually lose points, see the hardest CCA-F topics from practice attempt data.

Frequently asked questions

Next steps

Once you have your domain tallies, take the free 20-question CCA-F sampler for a second data point, then move to the full CCA-F practice tests, which are weighted to the same five domains and explain every distractor. If you need a schedule to hang the study blocks on, the 30-day CCA-F study plan maps them week by week. All six tests, the flashcard deck, and the graded tasks are included in Preporato Pro; see pricing for the current options.

Sources:

• Anthropic Partner Academy: Claude Certified Architect - Foundations
• Claude Docs: Tool use overview (tool_choice, input schemas)
• Claude Docs: Message Batches
• Claude Code Docs: Manage Claude's memory (CLAUDE.md)
• Claude Code Docs: Hooks
• Claude Code Docs: Subagents