CCA-F Practice Questions: How to Practise Without Using Dumps

Your support agent’s loop stops when the reply text contains "resolved", or after 10 iterations. Some chats end before the refund is issued; others spin until the cap. What is the fix?

1. Add stop words such as "done" and "completed".
2. Branch on stop_reason: loop on tool_use after returning tool results, finish on end_turn, and handle max_tokens, pause_turn and refusal explicitly.
3. Raise the cap to 50 and keep the keyword check.
4. Have Claude append {"done": true} to every reply and parse it.

Answer: B. The API reports why a turn ended, and the docs say to check it in agent loops.

• A fails: Keyword matching on model text is an anti-pattern the exam guide names.
• C fails: An arbitrary cap is a safety net, not stopping logic.
• D fails: This still parses generated text for a signal the API already returns.

A coordinator launches search and document subagents, then a synthesis subagent whose prompt says only "Write the report on topic X". The report ignores most findings and cites nothing. What is the fix?

1. Raise the synthesis agent’s max_tokens, since subagents share the coordinator’s conversation.
2. Switch synthesis to a larger model.
3. Let the search subagent write to the synthesis agent’s memory.
4. Put the full findings in the synthesis prompt, with claims kept apart from source URL, document name and date.

Answer: D. The SDK docs say the only channel from parent to subagent is the Agent tool’s prompt string.

• A fails: A non-fork subagent starts without the parent’s history or tool results.
• B fails: A better model cannot use findings it never received.
• C fails: Subagents do not share memory; context is passed explicitly.

An agent mapped a legacy codebase in a named session. A weekend refactor rewrote most files it had read. Resumed on Monday, it cites old function names. What do you do?

1. Start a new session seeded with a structured summary of conclusions that still hold.
2. Resume as is; sessions refresh file contents.
3. Fork the session and continue in the fork.
4. Run /compact and continue.

Answer: A. Most tool results are stale, so a clean summary is more reliable. If only a few files changed, resuming and naming them would do.

• B fails: Sessions persist the conversation, not the filesystem, per the docs.
• C fails: A fork copies the history, stale results included.
• D fails: Compaction summarises what is there; it does not re-read files.

Your process_refund MCP tool returns "Operation failed" for a gateway timeout, a refund over the limit and a missing permission. The agent retries all three. Best change?

1. Tell the agent in the system prompt to retry at most three times.
2. Throw a JSON-RPC protocol error for all three.
3. Return isError: true with an error category, a retryable flag and a plain-language reason.
4. Return an empty successful result.

Answer: C. MCP reports tool failures, business-logic errors included, in the result with isError. Category and retryable fields are the exam guide’s convention.

• A fails: Retrying a policy refusal or permission failure wastes calls.
• B fails: The spec keeps protocol errors for cases like unknown tools.
• D fails: Reporting failure as success hides it.

Tools get_order ("Gets order") and search_orders ("Searches orders") overlap. Given an order number, the agent often picks search_orders. Best fix?

1. Force get_order with tool_choice on every request.
2. Rewrite both descriptions: purpose, inputs, returns, and when to use the other tool.
3. Keep short descriptions and add a keyword rule to the system prompt.
4. Add a tool for each phrasing customers use.

Answer: B. The tool-use docs call detailed descriptions by far the most important factor in tool performance.

• A fails: Forcing one tool breaks searches, and some models reject forced choice.
• C fails: The guide warns that keyword-sensitive prompts create unintended tool associations.
• D fails: More tools raise decision complexity and degrade selection.

Claude Code ignores the team’s testing conventions for a new hire but follows them for colleagues. The lead wrote them in ~/.claude/CLAUDE.md. Fix?

1. Ask each developer to copy the lead’s file.
2. Put them in CLAUDE.local.md.
3. Rely on auto memory.
4. Move them to the project CLAUDE.md and commit it.

Answer: D. The memory docs say the project file is shared through source control and the user file only with you. /memory shows what loads.

• A fails: Copies drift apart.
• B fails: CLAUDE.local.md is for private preferences, kept out of git.
• C fails: Auto memory is notes Claude writes itself, stored in your own ~/.claude folder.

In CI, the Claude Code session that wrote a fix also reviews it and nearly always finds nothing. Humans later find problems. Best design?

1. Add "review critically" to that session’s prompt.
2. Enable extended thinking for the review step.
3. Run a separate -p review with no access to the author’s reasoning, returning JSON findings.
4. Drop findings with confidence below 0.8.

Answer: C. The guide says an independent instance beats self-review. Headless docs cover -p, --output-format json and --json-schema.

• A fails: The session still holds its own reasoning.
• B fails: The guide ranks independent review above extended thinking here.
• D fails: The guide treats self-reported confidence as unreliable.

You ask Claude Code to "reformat dates nicely" in a migration script. Output varies between runs. What helps most?

1. A few concrete input and output examples, including a null date.
2. A longer prose description of the style.
3. Adding "be consistent".
4. Running it five times and keeping the most common output.

Answer: A. The prompting docs call examples one of the most reliable ways to steer format.

• B fails: Prose is what produced the varied readings.
• C fails: An instruction without a target adds nothing.
• D fails: Voting adds cost and leaves the spec vague.

A manifest extractor uses a strict JSON schema and every response parses. One in twenty has item weights that do not sum to the stated total. Best response?

1. Tighten the schema until mismatches cannot occur.
2. Extract stated and calculated totals, validate in code, retry with the document, the failed output and the error, and flag unresolved conflicts.
3. Add "double-check arithmetic" and drop validation.
4. Move the job to the Batch API for accuracy.

Answer: B. Schemas guarantee shape, not correct values. Retries with error feedback fix format errors; a flag covers self-contradicting sources.

• A fails: A schema cannot express this check, and structured outputs do not support some numeric constraints.
• C fails: Prompts are probabilistic; code validation is the guard.
• D fails: Batch halves price. It does not change accuracy.

A pull-request review prompt says "be conservative; only report high-confidence findings". Developers dismiss style nits and now ignore real bugs too. What changes?

1. Tell it to be more conservative.
2. Require a numeric confidence above 90%.
3. Cap comments per pull request.
4. Define what to report (bugs, security) and skip (minor style), add examples, and pause the noisiest category while tuning.

Answer: D. The guide says explicit categorical criteria beat general caution, and false positives erode trust in accurate categories.

• A fails: Vague caution is what failed.
• B fails: Self-reported confidence is a weak proxy.
• C fails: A cap drops real bugs as easily as nits.

After repeated summarising in long chats, the agent says "your recent purchase" instead of order 48213 and a refund of $84.50. Best fix?

1. Keep a persistent "case facts" block of amounts, dates, order numbers and statuses outside the summarised history, and trim tool output.
2. Summarise more aggressively.
3. Keep only the last five turns.
4. Move to a larger context window.

Answer: A. Exact values should not pass through lossy summaries.

• B fails: More compression loses more numbers.
• C fails: Early turns hold the facts you would drop.
• D fails: The context docs describe context rot: recall degrades as tokens grow.

Extraction accuracy is 97% on a validation set. Leadership wants to auto-approve high-confidence extractions and end human review. Recommendation?

1. Approve; 97% beats typical human accuracy.
2. Use the model’s self-reported confidence as is.
3. Measure by document type and field, stratify-sample high-confidence outputs, and calibrate thresholds on labelled data first.
4. Review a flat random 1%.

Answer: C. A strong average can hide a weak document type. The eval docs say to mirror the real task distribution and include edge cases.

• A fails: The human comparison is asserted, not measured per segment.
• B fails: Uncalibrated confidence can be high on the cases that fail.
• D fails: A flat sample rarely catches rare document types.