CCA Guide

English

简体中文

English

简体中文

Appearance

Examples of Exam Questions with Explanations ​

Question 1 (Scenario: Customer Support Agent) ​

Situation: Data shows that in 12% of cases the agent skips get_customer and calls lookup_order using only the customer’s name, which leads to incorrect refunds.

Which change is most effective?

  • A) Add a programmatic precondition that blocks lookup_order and process_refund until an ID is obtained from get_customer [CORRECT]
  • B) Improve the system prompt
  • C) Add few-shot examples
  • D) Implement a routing classifier

Why A: When critical business logic requires a specific tool sequence, software provides deterministic guarantees that prompt-based approaches (B, C) cannot. D addresses availability, not tool ordering.

Question 2 (Scenario: Customer Support Agent) ​

Situation: The agent often calls get_customer instead of lookup_order for order-related questions. Tool descriptions are minimal and similar.

What is the first step?

  • A) Few-shot examples
  • B) Expand each tool’s description with input formats, examples, and boundaries [CORRECT]
  • C) Add a routing layer
  • D) Merge the tools

Why B: Tool descriptions are the model’s primary selection mechanism. This is the lowest-effort, highest-impact fix. A adds tokens without addressing the root cause. C is overengineering. D requires more effort than justified.

Question 3 (Scenario: Customer Support Agent) ​

Situation: The agent resolves only 55% of issues with a target of 80%. It escalates simple cases and tries to handle complex policy exceptions autonomously.

How do you improve calibration?

  • A) Add explicit escalation criteria with few-shot examples [CORRECT]
  • B) Self-rated confidence (1–10) with automatic escalation
  • C) A separate classifier trained on historical data
  • D) Sentiment analysis

Why A: It directly addresses the root cause—unclear decision boundaries. B is unreliable (the model can be confidently wrong). C is overengineering. D solves a different problem (mood != complexity).

Question 4 (Scenario: Code Generation with Claude Code) ​

Situation: You need a custom /review command for standard code review that is available to the whole team when they clone the repository.

Where should you create the command file?

  • A) .claude/commands/ in the project repository [CORRECT]
  • B) ~/.claude/commands/
  • C) Root CLAUDE.md
  • D) .claude/config.json

Why A: Project commands stored in .claude/commands/ are version-controlled and automatically available to everyone. B is for personal commands. C is for instructions, not command definitions. D does not exist.

Question 5 (Scenario: Code Generation with Claude Code) ​

Situation: You need to restructure a monolith into microservices (dozens of files, service-boundary decisions).

What approach should you use?

  • A) Planning mode: explore the codebase, understand dependencies, design an approach [CORRECT]
  • B) Direct execution incrementally
  • C) Direct execution with detailed up-front instructions
  • D) Direct execution and switch to planning when it gets hard

Why A: Planning mode is designed for large changes, multiple possible approaches, and architectural decisions. B risks expensive rework. C assumes you already know the structure. D is reactive.

Question 6 (Scenario: Code Generation with Claude Code) ​

Situation: A codebase has different conventions across areas (React, API, database). Tests are co-located with code. You want conventions to be applied automatically.

What approach should you use?

  • A) .claude/rules/ files with YAML frontmatter and glob patterns [CORRECT]
  • B) Put everything in the root CLAUDE.md
  • C) Skills in .claude/skills/
  • D) CLAUDE.md in every directory

Why A: .claude/rules/ with glob patterns (e.g., **/*.test.tsx) enables automatic convention application based on file paths—ideal for tests spread across the codebase. B relies on model inference. C is manual/on-demand. D does not work well when relevant files are in many directories.

Question 7 (Scenario: Multi-agent Research System) ​

Situation: The system researches “AI impact on creative industries,” but reports cover only visual art. The coordinator decomposed the topic into: “AI in digital art,” “AI in graphic design,” “AI in photography.”

What’s the cause?

  • A) The synthesis agent does not detect gaps
  • B) The coordinator decomposed the task too narrowly [CORRECT]
  • C) The web search agent does not search thoroughly enough
  • D) The document analysis agent filters out non-visual sources

Why B: The logs show the coordinator decomposed “creative industries” only into visual subtopics, completely missing music, literature, and film. Subagents executed correctly—the issue is what they were assigned.

Question 8 (Scenario: Multi-agent Research System) ​

Situation: A web-search subagent times out while researching a complex topic. You need to design how error information is passed back to the coordinator.

Which error propagation approach best enables intelligent recovery?

  • A) Return structured error context to the coordinator: failure type, query, partial results, and alternatives [CORRECT]
  • B) Implement automatic retries with exponential backoff inside the subagent, then return a generic “search unavailable” status
  • C) Catch the timeout inside the subagent and return an empty result set marked as success
  • D) Propagate the timeout exception to a top-level handler that terminates the whole workflow

Why A: Structured error context gives the coordinator what it needs to decide whether to retry with a modified query, try an alternative approach, or continue with partial results. B hides context behind a generic status. C masks failure as success. D aborts the entire workflow unnecessarily.

Question 9 (Scenario: Multi-agent Research System) ​

Situation: The synthesis agent often needs to verify specific claims while merging results. Currently, when verification is needed, the synthesis agent hands control back to the coordinator, which calls the web-search agent and then re-runs synthesis with the new results. This adds 2–3 extra round trips per task and increases latency by 40%. Your assessment shows that 85% of these checks are simple fact checks (dates, names, statistics), while 15% require deeper investigation.

How do you reduce overhead while maintaining reliability?

  • A) Give the synthesis agent a limited verify_fact tool for simple checks, and continue routing complex verification through the coordinator [CORRECT]
  • B) Accumulate all verification needs into a batch and return them to the coordinator at the end
  • C) Give the synthesis agent full access to all web-search tools
  • D) Proactively cache additional context around each source

Why A: This applies the principle of least privilege: the synthesis agent gets exactly what it needs for the 85% common case (simple fact checks) while preserving the coordinator-mediated path for complex investigations. B introduces blocking dependencies (later synthesis steps may depend on earlier verified facts). C breaks separation of responsibilities. D relies on speculative caching that cannot reliably predict needs.

Question 10 (Scenario: Claude Code for CI) ​

Situation: A pipeline runs claude "Analyze this pull request for security issues", but hangs waiting for interactive input.

What is the correct approach?

  • A) Use the -p flag: claude -p "Analyze this pull request for security issues" [CORRECT]
  • B) Set CLAUDE_HEADLESS=true
  • C) Redirect stdin from /dev/null
  • D) Use --batch

Why A: -p (or --print) is the documented way to run Claude Code in non-interactive mode. It processes the prompt, prints to stdout, and exits. The other options are either non-existent features or Unix workarounds.

Question 11 (Scenario: Claude Code for CI) ​

Situation: The team wants to reduce API cost for automated analysis. Claude currently serves two workflows in real time: (1) a blocking pre-merge check that must complete before developers can merge a PR, and (2) a tech-debt report generated overnight for morning review. A manager proposes moving both to the Message Batches API to save 50%.

How should you evaluate this proposal?

  • A) Use batch processing only for tech-debt reports; keep real-time calls for pre-merge checks [CORRECT]
  • B) Move both workflows to batch processing and poll for completion
  • C) Keep real-time calls for both to avoid ordering issues in batch results
  • D) Move both to batch processing with a fallback to real time if a batch takes too long

Why A: The Message Batches API saves 50%, but processing time can be up to 24 hours with no guaranteed latency SLA. That makes it unsuitable for blocking pre-merge checks where developers are waiting, but ideal for overnight batch workloads like tech-debt reports.

Question 12 (Scenario: Multi-file Code Review) ​

Situation: A pull request changes 14 files in an inventory tracking module. A single-pass review of all files produces inconsistent results: detailed comments for some files but superficial ones for others, missed obvious bugs, and contradictory feedback (a pattern is flagged as problematic in one file but approved in identical code in another file).

How should you restructure the review?

  • A) Split into focused passes: analyze each file individually for local issues, then run a separate integration pass for cross-file data flows [CORRECT]
  • B) Require developers to split large PRs into submissions of 3–4 files
  • C) Switch to a higher-tier model with a larger context window to review all 14 files in one pass
  • D) Run three independent full-PR review passes and report only issues found in at least two runs

Why A: Focused passes directly address the root cause—attention dilution when processing many files at once. Per-file analysis ensures consistent depth, and a separate integration pass catches cross-file issues. B shifts burden to developers without improving the system. C is a misconception: larger context does not fix attention quality. D suppresses real bugs by requiring consensus across inconsistent detections.