Jonathon's AI Wiki

CCA-F Practice Exam (60 Questions)

9 min read

Source: raw/guide_en.MD

A comprehensive 60-question practice test from a community study guide that matches the format and difficulty of the real CCA-F exam. The test uses 4 of the 6 possible exam scenarios: Multi-Agent Research System (15 questions), Claude Code for CI/CD (15 questions), Code Generation with Claude Code (15 questions), and Customer Support Agent (15 questions). This supplements the community GitHub repo (15 questions) and the Official Exam Guide sample questions (9 questions) for a total of 84 practice questions across all sources.

How to Use This

  1. Take the test cold first — do not read answers before attempting. Track your score by scenario
  2. Review wrong answers deeply — the explanations are the most valuable part
  3. Identify your weak scenarios — focus study on the scenario(s) where you score lowest
  4. Map each question to a task statement in the Official Exam Guide to build exam-reading skills

Scenario Distribution

ScenarioQuestionsPrimary Domains Tested
Multi-Agent Research SystemQ1-Q15Agentic Architecture, Tool Design, Context & Reliability
Claude Code for CI/CDQ16-Q30Claude Code Config, Prompt Engineering, Context & Reliability
Code Generation with Claude CodeQ31-Q45Claude Code Config, Prompt Engineering, Agentic Architecture
Customer Support AgentQ46-Q60Agentic Architecture, Tool Design, Context & Reliability

Key Patterns by Scenario

Multi-Agent Research System (Q1-Q15)

This scenario tests coordinator-subagent architecture, error propagation, context management, and tool scoping. The 15 questions cover these recurring patterns:

  • Conflicting data handling (Q1) — the analysis agent should complete its work with both values annotated, then let the coordinator reconcile. Never silently pick one value or stop work to escalate
  • Coordinator as central hub (Q2, Q8) — all communication routes through the coordinator for observability, uniform error handling, and controlled information flow
  • Local error recovery (Q3, Q6) — subagents should handle transient failures locally and only escalate unrecoverable errors with context and partial results
  • Narrow decomposition as root cause (Q4) — when results are incomplete but subagents executed correctly, the coordinator’s task decomposition is too narrow
  • Coverage annotations (Q5) — when synthesizing from mixed-quality inputs, annotate which sections have full vs partial vs missing coverage
  • Tool naming to fix misrouting (Q7) — rename overlapping tools to eliminate semantic overlap (e.g., analyze_content → extract_web_results)
  • Structured error context (Q9) — return failure type, attempted query, partial results, and alternatives to enable coordinator recovery
  • Scoped tools to prevent misuse (Q10) — replace general-purpose tools with constrained alternatives (e.g., fetch_url → load_document with URL validation)
  • Research space partitioning (Q11) — the coordinator explicitly partitions topics before delegating, not after, to prevent duplicate work
  • Distinguishing access failures from empty results (Q12) — timeout (retry decision) vs “0 results” (valid finding) require different responses
  • Lost-in-the-middle mitigation (Q13) — place key-findings summary at the start, organize details with section headings
  • Upstream structured data (Q14) — modify upstream agents to return structured data (key facts, relevance scores) instead of verbose content
  • Scoped verify_fact tool (Q15) — give synthesis agents a limited verification tool for simple checks (85% case), route complex ones through coordinator

Claude Code for CI/CD (Q16-Q30)

This scenario tests CLI integration, batch processing decisions, review architecture, and developer trust. Key patterns:

  • --output-format json + --json-schema (Q16) — the correct way to get structured CI output for posting inline PR comments
  • Independent review instance (Q17) — a second Claude instance without generation context catches issues the generator rationalized
  • Batch API limitation: no multi-turn tool calling (Q18) — batch is fire-and-forget; cannot intercept mid-request tool calls
  • Batch vs synchronous matching (Q19, Q21, Q30) — blocking pre-merge = synchronous; overnight/weekly = batch. This pattern is tested three times
  • Few-shot examples for consistent format (Q20) — when prose instructions produce variable output, 3-4 examples showing exact format are most reliable
  • Explicit criteria over vague instructions (Q22) — “flag only when claimed behavior contradicts code behavior” beats “check comments are accurate”
  • Disable high-false-positive categories (Q23, Q29) — temporarily remove noisy categories to restore developer trust; improve prompts before re-enabling
  • Include existing tests in context (Q24) — Claude can only avoid duplicating tests if it knows what tests already exist
  • Prior review findings for dedup (Q25) — include previous findings in context; instruct to report only new/unresolved issues
  • -p flag for non-interactive CI (Q26) — the documented way to prevent CI hangs
  • Multi-pass review (Q27) — per-file local analysis + cross-file integration pass to fix attention dilution
  • Rationale and confidence in findings (Q28) — include reasoning in each finding to reduce developer investigation time

Code Generation with Claude Code (Q31-Q45)

This scenario tests CLAUDE.md configuration, skills, rules, planning mode, and team workflow. Key patterns:

  • Concrete I/O examples (Q31) — when prose requirements cause misinterpretation, 2-3 concrete examples remove ambiguity
  • Planning mode for ambiguous tasks (Q32, Q34) — multiple valid approaches or architectural decisions require investigation before implementation
  • Skills for on-demand workflows (Q33) — keep universal standards in CLAUDE.md; create skills for workflow-specific guidance (PR review, deploy, migrations)
  • context: fork for isolation (Q35, Q43) — prevents verbose output or exploration context from polluting the main session
  • Personal skill override (Q36) — personal skills at ~/.claude/skills/ with same name take precedence over project skills
  • User-level vs project-level diagnosis (Q37) — when a new team member misses guidance, check if instructions are in user-level config instead of project-level
  • Skills vs path rules vs CLAUDE.md (Q38) — skills for on-demand context (endpoint examples), path rules for file-type conventions, CLAUDE.md for universal standards
  • Skill frontmatter trio (Q39) — argument-hint (prompts for params), context: fork (isolation), allowed-tools (security)
  • .claude/rules/ with glob patterns (Q40, Q42) — for cross-cutting conventions by file type regardless of directory location
  • .claude/commands/ for project-scoped commands (Q41) — version-controlled, available to all who clone the repo
  • .mcp.json with env var substitution (Q44) — project-level MCP config with ${GITHUB_TOKEN} for secrets
  • Explore subagent for verbose discovery (Q45) — isolates Phase 1 output to preserve context for Phases 2-3

Customer Support Agent (Q46-Q60)

This scenario tests tool selection, escalation, context management, and multi-issue handling. Key patterns:

  • Tool descriptions as first diagnostic (Q46, Q57) — when the agent picks the wrong tool, check descriptions first
  • Few-shot for multi-issue decomposition (Q47) — agent handles single issues well; needs examples for multi-issue reasoning and parameter separation
  • Parallel investigation with shared context (Q48) — decompose complex requests into separate issues, investigate in parallel with shared customer data
  • Explicit escalation criteria with few-shot (Q49) — unclear decision boundaries cause both over-escalation (simple cases) and under-escalation (policy exceptions)
  • Policy gap = escalation trigger (Q50) — when policy is silent on a request (competitor price matching), escalate; do not invent policy
  • Programmatic prerequisites (Q51) — block lookup_order and process_refund until get_customer returns verified ID. Deterministic, not probabilistic
  • Self-critique stage (Q52) — the evaluator-optimizer pattern catches inconsistent explanation completeness
  • Prompt to bundle tool requests (Q53) — instruct Claude to combine related tool calls in one turn to reduce API loops
  • Case facts block (Q54) — extract transactional facts (amounts, dates, IDs) into a persistent block outside summarized history
  • Ask for additional identifiers (Q55) — when get_customer returns multiple matches, request email/phone/order number; never guess
  • System prompt keyword steering (Q56) — systematic keyword-driven tool selection patterns indicate prompt-level instructions creating unintended associations
  • stop_reason as loop control (Q58) — "tool_use" = continue, "end_turn" = stop. The only reliable signals
  • PostToolUse hooks for normalization (Q59) — centralized, deterministic normalization of heterogeneous tool outputs
  • Targeted few-shot for ambiguous scenarios (Q60) — 4-6 examples targeting ambiguous cases with rationale for tool choice

Cross-Scenario Principle Frequency

These principles appear across multiple scenarios, indicating high exam likelihood:

PrincipleScenariosQuestion count
Deterministic over probabilisticAll 48+
Tool descriptions fix misroutingResearch, Support5
Batch API for non-blocking onlyCI/CD, Research5
Few-shot for consistent outputCI/CD, Support, Code Gen5
context: fork for isolationCode Gen3
Explicit criteria over vague instructionsCI/CD3
Coverage annotations / graceful degradationResearch3
.claude/rules/ with glob patternsCode Gen3
Coordinator decomposition as root causeResearch2
Planning mode for complex/ambiguous tasksCode Gen2
Independent review instanceCI/CD2

Scoring Guide

For self-assessment, use these thresholds:

ScoreReadiness
50+/60 (83%+)Strong — likely ready to pass
40-49/60 (67-82%)Moderate — review weak scenarios
30-39/60 (50-66%)Needs work — study all domains systematically
Below 30/60Start with Study Guide before retesting

Remember the actual exam passing score is 720/1000 (roughly 72%), so consistently scoring above 75% on practice questions is a reasonable readiness indicator.

Key Takeaways

  • The 60-question test covers 4 of the 6 possible exam scenarios, matching the real exam format of 15 questions per scenario
  • Batch API timing decisions (synchronous vs batch) are tested repeatedly across scenarios — this is a high-frequency exam topic
  • Tool description quality and context: fork are the most frequently tested Claude Code configuration patterns
  • The Research scenario heavily tests error propagation and coordinator decomposition — two patterns that are tested nowhere else with this depth
  • The CI/CD scenario uniquely tests the developer trust angle (false positive rates, investigation time, category disabling)
  • Cross-scenario principles (deterministic > probabilistic, explicit criteria, few-shot examples) account for the majority of questions
  • The Customer Support scenario is the best scenario for studying escalation patterns and context management together

Try It

  1. Print the full 60-question test from the source guide and take it timed — allow 90 minutes (same pace as the real exam)
  2. Score by scenario to identify your weakest area, then study that domain’s technical content in CCA-F Technical Reference
  3. For each wrong answer, identify which cross-scenario principle you missed and find 2-3 other questions testing the same principle
  4. Combine with the community questions from CCA-F Practice Questions for a total of 84 practice questions
  5. Retake after one week of study and compare scores to measure improvement

Graph View

Backlinks