all posts

Claude CCAR-F Certification: High Probability Questions, Cheat Sheet and Anti-Patterns

23 min read
  • claude
  • anthropic
  • certification
  • ai agents

I cleared the Claude CCAR-F certification on my second attempt. These are sample questions I practised with, and questions like these may hit your exam. Each one has the answer and a short reason. Try each question first, then open the answer.

The questions are grouped in three areas: a multi-agent research system, Claude Code in a CI/CD pipeline, and structured data extraction with tool use. After them come a cheat sheet to revise from and the anti-patterns that most wrong options are built on.

Multi-agent research system

Most of these questions use the same scenario: a coordinator agent with four subagents (web search, document analysis, synthesis and a report generator).

1. Too many tools per agent

You've configured the system so that all four subagents have access to the complete set of 18 tools. During testing, agents frequently call tools outside their specialization: the synthesis agent attempts web searches, and the report generator tries to analyze documents. What is the primary cause of this poor tool selection behavior?

  1. Choosing from 18 tools instead of 4-5 relevant ones increases decision complexity beyond reliable selection thresholds.
  2. The agents' role descriptions in their system prompts conflict with having access to tools outside that role.
  3. The tool definitions consume too much context window space, leaving insufficient room for task content.
  4. The coordinator cannot track which capabilities each subagent has, leading to misrouted tasks.
Show answer

A. The more tools an agent can choose from, the less reliably it picks the right one. Give each subagent only the few tools its role needs.

2. Delegation that never happens

The coordinator agent has AgentDefinitions configured for all four specialized subagents, each with appropriate descriptions, prompts, and tool restrictions. During testing, you notice the coordinator correctly reasons about when to delegate (it generates messages like "I'll ask the web search agent to find sources on this topic") but no subagent execution ever occurs. The coordinator then proceeds as if the delegation happened and continues with incomplete information. Logs show no errors. What is the most likely cause?

  1. The coordinator's max_tokens setting is too low, causing the Task tool invocation to be truncated before the subagent type parameter can be specified.
  2. The coordinator's allowedTools configuration doesn't include "Task", so while it can reason about delegation, it cannot invoke the tool required to spawn subagents.
  3. Subagent context isolation means task descriptions from the coordinator don't automatically reach subagents; you need to configure explicit context forwarding in ClaudeAgentOptions.
  4. The AgentDefinitions are configured correctly, but the coordinator's system prompt doesn't explicitly list the available subagent types, preventing the model from knowing they can be invoked.
Show answer

B. Subagents are spawned through the Task tool. If Task is not in the coordinator's allowedTools, it can only talk about delegating. Nothing fails, so the logs stay clean.

3. Giving the synthesis subagent its input

After the web search and document analysis subagents complete their tasks, the coordinator needs to spawn the synthesis subagent to synthesize the findings. What is the correct approach for providing the synthesis subagent with the information it needs?

  1. Provide the subagent with tool definitions that allow it to request outputs from other subagents via callbacks.
  2. Include the complete findings from both subagents directly in the synthesis subagent's prompt.
  3. Pass reference identifiers and configure the subagent with read access to a shared memory store where other subagents deposited their results.
  4. Spawn the subagent with only a brief task description, relying on automatic context inheritance from the coordinator.
Show answer

B. A subagent starts with a fresh context and inherits nothing from the coordinator. Everything it needs goes into its prompt.

4. How subagents share results

The web search agent has gathered several relevant sources for a research topic. The document analysis agent now needs to examine these sources. How does information typically flow between these two specialized subagents?

  1. The agents communicate through an event-driven message queue, with the document analysis agent subscribing to web search completion events.
  2. The web search agent directly invokes the document analysis agent, passing the discovered sources as parameters.
  3. The coordinator agent receives the web search agent's output and includes relevant findings in the prompt when invoking the document analysis agent.
  4. Both agents access a shared memory store where the web search agent writes findings and the document analysis agent reads them.
Show answer

C. Subagents do not talk to each other. Results go back to the coordinator, which passes what is relevant to the next subagent.

5. Lost source attribution

In production, final reports frequently contain claims without proper source attribution. Investigation shows that while the web search and document analysis agents correctly attach citations to their outputs, the synthesis agent loses track of which sources support which conclusions when combining findings. What's the most effective architectural change?

  1. Add a verification step where the report generator uses semantic similarity matching against original sources to reconstruct which claims came from which documents.
  2. Have the coordinator inject source identifier prefixes into text before each handoff, then parse these prefixes at report generation to reconstruct citations.
  3. Maintain complete transcripts of all subagent interactions and add a citation-resolution agent to analyze logs and determine attributions before report generation.
  4. Require all subagents to output structured claim-source mappings that the synthesis agent must preserve and merge when combining findings from multiple sources.
Show answer

D. Keep attribution as structured data through every handoff. The other options try to rebuild it after it is lost.

6. Simple queries run the whole pipeline

In production, you observe that simple fact-checking queries (e.g., "What year was the Paris Climate Agreement signed?") traverse all four subagents sequentially, consuming 40+ seconds and significant tokens per query. Complex comparative research benefits from the full pipeline. Your query distribution is diverse and evolving as users discover new applications. What's the most effective approach to optimize for varying query complexity?

  1. Have the coordinator analyze each query and dynamically decide which subagents to invoke based on its assessment of query requirements.
  2. Train a query complexity classifier on labeled historical data to predict optimal subagent combinations, retraining periodically as query patterns evolve.
  3. Create a fast-path for factual questions that bypasses subagents entirely, routing all other queries through the complete pipeline to ensure research thoroughness.
  4. Implement pattern-based routing that categorizes queries by structure (single-fact vs. comparative vs. analytical) and maps each category to a predefined combination.
Show answer

A. The query mix keeps changing, so fixed routes and trained classifiers fall behind. Let the coordinator decide per query which subagents it needs.

7. Conflicting findings and uncertainty

Production reviews reveal inconsistent handling of uncertainty in final reports. Sometimes conflicting subagent findings are synthesized into a single confident statement (losing nuance), while other times reports over-hedge with excessive qualifications (becoming unhelpful). When the web search agent returns "industry analysts estimate $50B market size (methodology varies)" and the document analysis agent returns "peer-reviewed study estimates $35B (±$7B, 95% CI)," the coordinator either picks one arbitrarily or produces vague statements like "the market may be $35B-$50B depending on factors." What systematic approach best addresses this?

  1. Implement a confidence calibration layer that normalizes subagent uncertainty expressions to standardized probability scores (0.0-1.0), then weight-average findings by their calibrated confidence.
  2. Instruct the synthesis agent to structure reports with explicit sections distinguishing well-established findings from contested ones, preserving original source characterizations and methodological context.
  3. Configure subagents to only report findings meeting a high-confidence threshold, filtering uncertain information before it reaches the coordinator.
  4. Add a verification subagent that cross-references findings across sources, only passing claims to synthesis that are corroborated by at least two independent sources.
Show answer

B. Show the conflict with each source's method, so the reader can judge. Averaging or filtering removes exactly the context the reader needs.

8. Every output turned into bullet points

A user expands the research system beyond its original web-search agent by adding specialized data sources. A financial API agent returns structured JSON containing revenue, margins, and growth rates. A news-monitoring agent returns prose summaries of recent developments. A patent-analysis agent returns structured lists of technology areas. The synthesis agent combines these results into executive briefings. Currently, it converts everything into bullet points, causing financial comparisons to lose tabular clarity and news summaries to lose their narrative flow. What change would most improve briefing quality?

  1. Standardize all subagent outputs as prose summaries with inline citations.
  2. Standardize all subagent outputs as JSON containing fields for claim, evidence, source, and confidence.
  3. Update the synthesis agent to render each content type appropriately: financial data as tables, news as prose, and technology areas as structured lists.
  4. Add a format-conversion layer that transforms every subagent result into a common intermediate representation before synthesis.
Show answer

C. The problem is in synthesis, so fix it there. Each content type keeps the format that suits it. Forcing one format on all of them is the problem you started with.

Claude Code in CI/CD

9. Capping turns and cost per run

You are integrating Claude Code into your CI/CD pipeline. The system runs automated code reviews, generates test cases, and provides feedback on pull requests. You need to design prompts that provide actionable feedback and minimize false positives. During initial testing of the automated review pipeline, you notice that reviews on large pull requests containing more than 50 changed files sometimes take over 20 minutes and cost $8-$12 per run because of extensive agentic loops. Claude reads files, runs analysis tools, and iterates many times. Your team needs each invocation to abort once it reaches both a fixed iteration count and a fixed dollar amount, enforced by Claude Code itself rather than by the surrounding job runner. Which configuration change directly enforces both per-invocation caps?

  1. Switch the --model flag to a smaller, less expensive model so each iteration uses fewer tokens and has a lower per-call cost.
  2. Set timeout-minutes: 5 on the GitHub Actions job step and monitor per-run costs through the Anthropic Console usage dashboard.
  3. Add --max-turns 10 --max-budget-usd 2.00 to the claude -p invocation to cap iterations and spending.
  4. Set --permission-mode dontAsk to automatically deny tool-permission requests not included in the explicitly allowed set.
Show answer

C. --max-turns caps iterations and --max-budget-usd caps spend, and Claude Code enforces both. A job timeout is the runner's limit, and a cheaper model caps neither.

10. Review that ignores the rest of the repo

You are setting up a non-interactive automated code review pipeline using Claude Code. You want Claude to analyze a pulled Git diff (git diff) against the main branch and apply a custom set of code review instructions. However, you notice that when you run the pipeline, Claude only looks at the raw diff text itself and completely stops using its file-reading or code navigation tools. As a result, it fails to inspect the broader codebase repository context, which is critical because the diff modifies a core function called by many other external modules. Which change to the CLI invocation will cause Claude to read related files in the repository while still successfully applying your custom review instructions?

  1. Replace --system-prompt with --append-system-prompt so your review instructions are added to Claude Code's default prompt instead of overwriting the built-in guidance for using file-reading and code navigation tools.
  2. Keep --system-prompt and add --allowedTools "Read, Glob, Grep" so that the non-interactive mode permits file system tools that it otherwise disables.
  3. Stop piping the diff via stdin and instead embed the diff contents inside the prompt string, so Claude Code treats the invocation as an agentic session rather than a stream-processing one.
  4. Remove --system-prompt entirely and place the review instructions in a CLAUDE.md file at the repo root, since --system-prompt is incompatible with tool use under -p.
Show answer

A. --system-prompt replaces Claude Code's whole default prompt, including its guidance on using tools. --append-system-prompt keeps that guidance and adds your instructions.

Structured extraction and tool use

These questions use a system that extracts information from unstructured documents, validates it against JSON schemas and passes it to downstream systems.

11. Unparseable JSON

Your extraction pipeline occasionally receives responses that cannot be parsed as valid JSON, causing downstream processing failures. The current implementation prompts Claude to return JSON in the response text and then parses it. What is the most reliable approach to ensure Claude returns valid, schema-compliant structured data?

  1. Add explicit formatting instructions to the prompt with JSON examples, emphasizing that Claude must return only valid JSON with no surrounding text.
  2. Use regular expressions to locate and extract JSON from the response text, handling cases where Claude includes explanatory text around the JSON block.
  3. Define a tool with a JSON schema specifying the expected structure, using tool use to constrain Claude's output to schema-compliant JSON.
  4. Implement a retry loop that catches JSON parsing errors and re-prompts Claude with the error details, asking it to correct the malformed output.
Show answer

C. A tool's input schema makes Claude return structured arguments that match the schema. Prompt instructions, regex and retries treat the symptom.

12. Forcing the first tool call

Your pipeline uses a tool called extract_metadata with a JSON schema for paper details. You've also defined lookup_citations and verify_doi tools for enrichment. During testing, you notice that when users include requests like "extract the metadata and tell me how cited it is," Claude sometimes calls lookup_citations first, which fails because it needs the DOI that extract_metadata would provide. What's the most effective way to ensure structured metadata extraction happens first?

  1. Set tool choice to {"type": "tool", "name": "extract_metadata"} and process the enrichment requests in subsequent turns after receiving the extracted metadata.
  2. Set tool choice to "any" so Claude must use a tool, combined with system prompt instructions prioritizing extract_metadata.
  3. Set tool choice to {"type": "tool", "name": "extract_metadata"} for every API call in the pipeline, ensuring Claude always extracts metadata before any enrichment can occur.
  4. Set tool choice to "auto" and reorder the tool definitions so extract_metadata appears first in the tools array, since Claude prioritizes earlier-listed tools.
Show answer

A. Force extract_metadata on the first call only, then let later turns use the enrichment tools. Forcing it on every call (C) means the enrichment tools never run. "any" doesn't say which tool, and tool order sets no priority.

13. Batch or real-time

Your extraction system processes two document types: standard monthly reports, which are archived after processing, and urgent exception reports, which must trigger business alerts within 30 minutes of receipt. Both use the same JSON schema. You want to minimize API costs while meeting the latency requirements. How should you architect the processing pipeline?

  1. Submit all documents to the Message Batches API with custom_id values for tracking. When results arrive, immediately process urgent documents and trigger delayed alerts for exceptions.
  2. Route standard reports to the Message Batches API for 50% cost savings, and route urgent exception reports to the real-time Messages API.
  3. Queue all documents and submit hourly batches, flagging urgent documents for expedited handling when batch results return.
  4. Submit all documents to the real-time Messages API to ensure consistent processing latency across document types.
Show answer

B. Batches cost half as much but can take up to 24 hours, with no latency guarantee. Batch the reports that can wait and send the urgent ones in real time.

14. Valid JSON, empty fields

After implementing tool use with strict schema definitions, JSON syntax errors are eliminated, but 5% of extractions still have valid JSON with empty arrays or null values for required fields like citations and methodology. Spot-checking reveals that source documents contain this information, but in varied formats: inline citations vs. bibliographies, methodology sections vs. details embedded in introductions. What's the most effective way to address these failures?

  1. Modify your schema to make citations and methodology optional, and flag incomplete records for manual review rather than failing validation.
  2. Build a regex-based post-processing layer that scans source documents for citation patterns and methodology keywords, populating empty fields when the model fails to extract.
  3. Add few-shot examples demonstrating extractions from documents with varied structures, showing how to identify citations in different formats and locate methodology details across section types.
  4. Implement retry logic that re-sends requests when validation detects empty required fields.
Show answer

C. The information is in the documents, so the model doesn't recognise it in unfamiliar layouts. Examples of each layout fix that. Retries repeat the same miss.

15. Inconsistent values in one field

Your extraction system parses e-commerce product descriptions to extract specifications like dimensions, weight, and materials into JSON. Despite having a well-defined schema, the model inconsistently extracts the "materials" field: sometimes returning "cotton blend", other times "Cotton/Polyester mix", and occasionally omitting the field when material information is clearly present in the source. What's the most effective way to improve extraction consistency?

  1. Set temperature to 0 to eliminate randomness and ensure deterministic outputs.
  2. Switch to a more capable model tier since inconsistent extraction indicates insufficient model capability.
  3. Make the "materials" field required instead of optional in the schema to force the model to always extract a value.
  4. Add few-shot examples showing 2-3 complete input-output pairs with standardized material description formats.
Show answer

D. The model has no standard to follow. Examples show it the format you want. Temperature 0 makes output repeatable, not standardised.

16. A skills array with three problems

Your schema includes a skills: string[] field. Production monitoring reveals three consistency issues: (1) compound phrases like "Python and SQL" are sometimes kept as one entry, sometimes split; (2) implied but unstated skills occasionally appear in extractions; (3) similar documents produce wildly different array lengths (5-10 vs 40+ entries). Your prompt currently says "Extract all skills mentioned." What's the most effective improvement?

  1. Add few-shot examples demonstrating compound phrase handling, explicit mention criteria, and appropriate entry granularity.
  2. Add constraints: "Extract 10-20 skills maximum, one skill per entry, only explicitly named skills."
  3. Add post-extraction normalization that maps skills to a canonical taxonomy and deduplicates similar entries.
  4. Enrich the schema to skill: string, confidence: float, source_quote: string to capture extraction confidence.
Show answer

A. A few examples fix all three problems at once. A hard count (B) cuts real skills from long documents, and post-processing (C) can't remove skills the model invented.

Cheat sheet

The facts I kept coming back to while revising, one line each.

Messages API

State
The API is stateless. Send the full conversation history, the system prompt and the tools on every request.
system
A separate field, not a message. It sets the role, rules and output format for the whole conversation.
stop_reason
tool_use: run the tool and send back a tool_result. end_turn: done. max_tokens: the reply was cut off.
Long inputs
Details in the middle of a long context get missed. Put key facts at the start or end, and trim tool results to the fields you need.

Tools and structured output

Descriptions
Claude picks a tool by its description. Say what it does, what it returns, its input format and when to use it instead of a similar tool.
tool_choice
auto: Claude decides. any: some tool must be called. {"type": "tool", "name": …}: that tool must be called.
JSON schema
A tool's input schema guarantees valid, well-formed JSON. It does not guarantee the values are right.
Schema design
Make a field required only if every source has it. Otherwise make it nullable, or Claude will invent a value. Add "other" or "unclear" to enums.
Semantic errors
Totals that don't add up, or values in the wrong field: catch them with validation, then retry with the specific error.

Agents and the Agent SDK

Agentic loop
Call Claude, run the tools it asks for, append the results, repeat while stop_reason is tool_use.
Hub and spoke
The coordinator splits the task, picks the subagents, passes context and collects results. Subagents never talk to each other.
Subagent context
A subagent starts empty. Everything it needs goes in its prompt.
Spawning
Subagents are started with the Agent tool (called Task in older versions). It must be in the coordinator's allowed tools. Several calls in one turn run in parallel.
Tool scope
Give each agent only the 4–5 tools its role needs.
Hooks
PreToolUse can block or redirect a call. PostToolUse can rewrite a result. Use them for rules that must always hold.
Sessions
--resume continues a named session, and forking branches one. After files change, tell Claude what changed, or start fresh with a summary.

MCP

Parts
Tools are actions, resources are data to read (schemas, catalogues, docs), and prompts are reusable templates.
Config
.mcp.json in the repo is shared with the team, with secrets as ${ENV_VAR}. ~/.claude.json is personal.
Errors
Return isError: true with a category, a message and whether a retry makes sense. "Operation failed" tells the agent nothing.
Build or reuse
Use existing servers for standard systems like GitHub or Jira. Build your own only for workflows unique to your team.

Claude Code

CLAUDE.md
~/.claude/CLAUDE.md is yours only. The project's CLAUDE.md or .claude/CLAUDE.md is shared through git. A CLAUDE.md in a subfolder applies to that folder.
Imports
@path/to/file.md pulls in another file. Relative paths resolve from the importing file.
Rules
.claude/rules/*.md with paths: globs load only for matching files, such as every test file across the repo.
Skills
.claude/skills/<name>/SKILL.md is shared, ~/.claude/skills/ is personal. context: fork runs one in a subagent, and allowed-tools limits its tools.
Plan mode
For large, unclear or multi-file changes. Make small, clear fixes directly.
CI
claude -p runs without prompts. Add --output-format json, --max-turns, --max-budget-usd and --allowedTools, and use --append-system-prompt rather than --system-prompt.

Prompting and pipelines

Few-shot
The fix when output is inconsistent or the inputs vary: 2–4 examples that show the format and the edge cases.
Criteria
"Flag only issues that can cause a bug" beats "be thorough". Vague instructions give vague results.
Chaining
Use fixed steps when the task is predictable, and let the coordinator decide when it isn't. Review big diffs per file, then once across the files.
Retries
Retry with the exact error and they fix format mistakes. They can't add information the source doesn't have.

Message Batches API

Trade-off
Half the price, but results can take up to 24 hours, with no latency guarantee.
Use it for
Overnight and bulk jobs. Anything a person or a deadline is waiting on goes to the regular API.
custom_id
Results come back in any order. Match them to requests with custom_id, and resubmit only the failures.
Before a big batch
Test the prompt on a small sample with the regular API first.

Escalation, errors and context

Escalate when
The customer asks for a human, policy doesn't cover the case, or the agent can't make progress.
Handoff
Pass a structured summary (customer, issue, what was tried, what is needed) so the human doesn't start over.
Subagent errors
Retry transient errors locally. Otherwise send the coordinator the error type, the partial results and whether to retry.
Gaps
If a topic has no sources, say so in the report instead of leaving it out.
Long sessions
Keep key facts (IDs, amounts, dates) in a block that is never summarised. Summaries blur numbers.

Anti-patterns

Most wrong options aren't random: they are real mistakes that sound reasonable. Learn to spot these and many questions become easy.

  1. Teaching tool order with examples

    TrapFew-shot examples or prompt rules to make sure verify_identity runs before process_refund.

    FixA hook or prerequisite check in code that blocks the second call until the first has succeeded.

  2. Trusting the model's own confidence

    TrapEscalating when Claude says it is unsure, or filtering findings by a confidence score it reports.

    FixObjective triggers: a missing field, an amount over a limit, a policy gap, an explicit request for a human.

  3. Escalating on sentiment

    TrapRouting to a human when the customer sounds angry.

    FixEscalate on what the case needs. An angry customer with a simple problem can still be helped by the agent.

  4. Reading the reply to decide when to stop

    TrapEnding the loop when the text says "done", or after a fixed number of turns.

    FixStop on stop_reason == "end_turn". A turn cap is only a safety net.

  5. Batching everything to save money

    TrapSending urgent or interactive work to the Batches API for the discount.

    FixBatch only what can wait up to a day. Send the rest to the regular API.

  6. A bigger context window for missed details

    TrapSwitching to a model with a larger window when details in a long document get missed.

    FixProcess the document in focused sections, then run one pass that combines the section results.

  7. Every tool for every agent

    TrapGiving all agents all tools "for flexibility", including full web search for the synthesis agent.

    FixGive each role its own few tools. For a rare need, add one narrow tool or route it back through the coordinator.

  8. Hiding failures

    TrapA failed subagent returns an empty result, so the coordinator can't tell "found nothing" from "couldn't look".

    FixReturn an error with its type, the partial results and whether a retry makes sense.

  9. One failure stops everything

    TrapA timeout in one subagent ends the whole workflow and throws away the finished work.

    FixRecover locally where possible. Otherwise report to the coordinator, which can retry, reroute or continue with a noted gap.

  10. Required fields to force complete output

    TrapMarking every schema field required so nothing comes back empty.

    FixMake fields nullable where the source may not have the data. An honest null beats an invented value.

  11. Prompt rules as security

    TrapA generic fetch_url tool plus "only fetch approved domains" in the prompt.

    FixA narrower tool that checks an allow-list itself, so the rule holds whatever the input says.

  12. Guessing between matching records

    TrapA lookup returns two customers and the agent picks the most recent one.

    FixAsk for another identifier, such as an email or order number, before acting.

  13. Trusting the overall accuracy number

    TrapCutting human review because accuracy is 97% overall.

    FixCheck accuracy per document type and field first. A small document type can fail badly inside a good average.

  14. Resuming on stale results

    TrapResuming a session after the code changed and expecting Claude to notice.

    FixTell it which files changed, or start a new session with a summary of what was found.

The rule behind them all: when something must always happen, enforce it in code (hooks, schemas, stop_reason, allow-lists, explicit triggers), not with a prompt, examples or the model's own judgment.

What helped me pass

  • Most questions describe a symptom and ask for the root cause. Ignore answers that add a layer to work around the problem.
  • If the model "doesn't know" a format or standard, the answer is usually few-shot examples. If the output must match a structure, it is tool use with a schema.
  • Subagents share nothing on their own. The coordinator passes everything, in the prompt.
  • Learn the Claude Code CLI flags: -p, --max-turns, --max-budget-usd, --system-prompt and --append-system-prompt, --allowedTools, --permission-mode.

Good luck with your exam.

Wanna thank me? 👇🏼

Buy Me A Coffee

back to all posts