The 6 CCA-F exam scenarios, deconstructed
Lesson 0 introduced the six business scenarios in one table. This is the deep dive: what each scenario really is, what it is really testing underneath the business framing, a realistic decision point you could be asked to judge, and what separates a strong architectural choice from a weak one.
Every scenario is a costume worn by one or two domains
The business framing changes — a support bot, a CI pipeline, a research system — but the underlying architectural concept being tested is always drawn from the same five domains you already studied. Learning to see through the scenario to the domain underneath is the single highest-leverage skill for exam day.
6.1 Customer Support Resolution Agent
The scenario: a company is building or deploying an agent that handles returns, billing disputes, and account issues end to end, with a stated business target of 80%+ first-contact resolution (FCR)— solving the customer's problem in a single conversation, without a human handoff.
What it's really testing
- Tool error handling and recovery (Domain 1). Order lookups time out, refund APIs return declines — the agent must reason over structured errors, not crash or hallucinate success.
- Escalation via deterministic triggers, not self-reported confidence (Domain 5). The scenario almost always plants an option where the agent "decides it can handle it" based on its own sense of the conversation. That is never the correct answer when a policy threshold exists.
- Session state preservation across a long conversation (Domain 1 / 5). Verified identity and case facts established early must survive to the end of the conversation, including across any compaction.
- The FCR-vs-escalation tension.The scenario's signature trap: a resolution-rate target sitting right next to a mandatory escalation rule. The target never wins.
Mini decision point
A customer's identity was verified in turn 2. By turn 20, they are requesting a refund that is 40% outside the policy window, and the team's FCR dashboard is sitting just under the 80% target for the month. The refund-eligibility tool returns false. Does the agent try to find a way to approve the exception to protect the metric, escalate immediately because the case trips a defined policy threshold, or attempt more troubleshooting first?
| Strong choice | Weak choice |
|---|---|
| Escalate the moment the deterministic threshold is tripped, and hand the human agent the already-verified identity and case facts so the customer never repeats themselves. | Let the agent weigh whether it "feels confident" approving the exception, because the team is under pressure to hit its FCR number this month. |
| Treat the FCR target as a lagging outcome metric the architecture influences indirectly (by resolving the cases it safely can) — never as a rule to satisfy by skipping a control. | Re-verify the customer's identity a second time "to be safe" instead of trusting state already established — this doesn't fix anything and erodes trust. |
6.2 Code Generation with Claude Code
The scenario:a company is rolling out Claude Code across a development team — not one developer's personal setup, but shared configuration that many engineers will use day to day.
What it's really testing
- CLAUDE.md hierarchy and shared config (Domain 3).What belongs at the repo level (everyone must see it) versus the user level (one developer's own preferences), and how the two layers combine.
- Slash command and skill design with proper tool scoping (Domain 3). A shared
/deploycommand or skill should carry exactly the tools it needs — no more. - Plan mode vs direct execution judgment (Domain 3). Knowing when a change is risky or ambiguous enough to warrant a reviewed plan first, versus safe enough to execute directly.
- Team-wide consistency vs individual flexibility. The scenario tests whether you know which layer of configuration a given rule belongs in.
Mini decision point
A 40-person engineering org wants: (1) nobody ever edits infra/prod/ directly, (2) a consistent commit-message format across the team, and (3) each developer keeping their own personal shortcuts and aliases. Three different rules, three different correct homes.
| Requirement | Strong choice | Weak choice |
|---|---|---|
| Never edit infra/prod/ | Repo-level PreToolUse hook or permission rule that blocks it outright | A line in the repo CLAUDE.md asking Claude not to |
| Consistent commit format | Repo-level CLAUDE.md convention or a shared slash command everyone runs | Leave it to each developer's memory |
| Personal aliases/shortcuts | Each developer's own user-level CLAUDE.md or personal settings | Bake everyone's personal preferences into the shared repo file |
6.3 Multi-Agent Research System
The scenario: a coordinator agent delegates a research task to specialised subagents — typically search, analysis, synthesis, and reporting — and assembles their work into a final answer.
What it's really testing
- Hub-and-spoke orchestration vs flat topology (Domain 1).The coordinator owns the plan and the definition of "done"; spokes never talk to each other.
- Context passing as structured summaries, not raw transcripts (Domain 1). The coordinator reasons over what each subagent concluded, not everything it read to get there.
- Graceful handling of a subagent that finds nothing or fails partway (Domain 1 / 5). A dead end is data too — it must surface, not vanish.
- Provenance and conflict handling when subagent reports disagree (Domain 5). Two subagents citing different numbers for the same fact is a reconciliation problem, not a coin flip.
Mini decision point
Four subagents run: search, analysis, synthesis, reporting. The search subagent returns zero results for one of its five sub-queries. Separately, the analysis subagent's summary states a market-size figure that disagrees with the number in the synthesis subagent's summary. The coordinator has to decide what goes into the final report.
| Strong choice | Weak choice |
|---|---|
| Note the zero-result sub-query as an explicit gap in the final report rather than silently dropping it; trace both figures back to their cited sources and reconcile or flag the discrepancy for the user. | Quietly omit the failed sub-query and pick whichever figure came from the subagent that happened to run last, on the assumption that later means more authoritative. |
| Keep the reconciliation work inside the coordinator, which is the only agent with visibility into every subagent's report. | Let the analysis and synthesis subagents exchange messages directly to "sort it out" between themselves. |
6.4 Developer Productivity Tools
The scenario: automating codebase navigation and engineering grunt work — finding usages, tracing dependencies, drafting a migration plan — often on a codebase Claude has never seen before, using the built-in tools (Read, Write, Bash, Grep, Glob) plus MCP servers for external systems like a ticketing tool.
What it's really testing
- MCP server integration and tool scoping (Domain 2). Which external systems get exposed as tools, and to which parts of the workflow.
- Tool description quality driving correct selection (Domain 2). When two tools sound similar, a vague description is what causes Claude to pick the wrong one.
- Subagents for exploratory, noisy work (Domain 1). Protecting the main session from hundreds of grep hits and dead-end file reads.
Mini decision point
A team wants Claude Code to find every call site of a deprecated internal API across a 4,000-file monorepo it has no prior familiarity with, cross-reference open tickets via an MCP ticketing server, and propose a migration plan — without derailing the main conversation the developer is actually working in.
| Strong choice | Weak choice |
|---|---|
Delegate the search to a subagent scoped to Read/Grep/Glob (read-only), return a structured summary of usages plus a proposed migration plan to the parent. | Run the entire multi-hundred-file exploration inline in the main session "so nothing gets lost." |
| Write precise, differentiated tool descriptions so a "list open tickets" MCP tool and a "list closed tickets" MCP tool cannot be confused for each other. | Give one agent every tool available (including Write and Bash) so it "never needs to ask" — unrestricted access for a read-only search task. |
6.5 Claude Code in CI/CD
The scenario: Claude Code runs inside a pipeline — reviewing pull requests, generating missing tests, or both — with no human at a terminal to interact with it.
What it's really testing
- Headless
-pmode and--output-format json(Domain 3). Pipeline steps need machine-parseable output, not a chat transcript. - Session isolation between separate CI runs (Domain 3).One PR's review must never inherit state from a different PR's run.
- Minimising false positives via a tightly scoped review prompt (Domain 3 / 4).A vague "review this code" prompt produces noisy, low-trust comments that teams learn to ignore.
Mini decision point
A pipeline needs to review every PR's diff and post inline comments through a bot, and separately generate missing unit tests for new functions. It must run unattended, produce output the bot can parse reliably, and never let one PR's review leak into the next.
# CI step - one isolated invocation per PR, machine-parseable output
claude -p "Review this diff for security and correctness issues only. \
Do not comment on style. Cite file:line for every finding." \
--output-format json < pr-diff.patch > review.json| Strong choice | Weak choice |
|---|---|
A fresh -p invocation per PR with --output-format json, and a review prompt scoped tightly to the categories the team actually acts on. | One long-lived interactive session reused across every PR of the day, with the terminal output scraped by regex. |
| Treat a broad "review everything" prompt as a false-positive generator to be narrowed, not a thoroughness feature. | Ask for a plain-English summary and have the bot keyword-match it, since "JSON felt like overkill." |
6.6 Structured Data Extraction
The scenario: converting unstructured documents — invoices, contracts, scanned forms, emails — into clean, validated, structured data a downstream system can consume.
What it's really testing
- JSON schema validation via
tool_use(Domain 4).Forcing the model's output into a schema you can validate mechanically. - Nullable field handling to prevent hallucinated values (Domain 4). A field that is genuinely absent from the source document must come back
null, never a plausible guess. - Validation-retry loops (Domain 4). When the schema check fails, the correct move is a bounded retry with the validation error fed back — not accepting bad data or failing the job.
- Message Batches API vs real-time API (Domain 4). Large, deadline-tolerant jobs belong in Batches; anything user-facing needs the real-time API.
Mini decision point
A team must extract 12 fields from 50,000 scanned vendor contracts overnight, with an 8-hour deadline and no user waiting on the result. Separately, a live chat widget needs 3 fields extracted from a customer's pasted email while the customer is on the page. Some contracts genuinely have no renewal clause at all.
| Strong choice | Weak choice |
|---|---|
| Message Batches API for the overnight 50,000-contract job (deadline-tolerant, cost-optimised, no one waiting); real-time API for the live chat extraction (user is actively waiting). | Real-time API for both "because it's simpler," ignoring that the bulk job is exactly the deadline-tolerant, high-volume case Batches exists for. |
Mark the renewal-clause field nullable so the model returns null when a contract genuinely has none, and run a bounded validation-retry loop on schema failures. | Require every field so the output is never "incomplete" — which forces the model to invent a value for contracts that never had a renewal clause to begin with. |
How to use this for exam day
Only 4 of these 6 scenariosappear in any single sitting, drawn at random — you will not know which four until you are in the exam. That means every scenario above earns its place in your prep; skipping one because it "seems less likely" is a bet with no upside and a real downside.
What you gain from studying all six is speed, not just coverage: the moment you recognise which scenario a question stem belongs to, you already know which domain's concepts and which anti-patterns are the likely trap — often before you have finished reading the four options.
Checkpoint quiz — Exam Scenarios
Exam-style: one scenario, one correct answer, three plausible mistakes. Click an option to lock in and see the explanation.
Turn 2 verified the customer's identity. The team's dashboard shows first-contact resolution at 76%, just under the 80% target. A refund request comes in that is 40% over the policy threshold — a case that trips a mandatory escalation trigger. What should happen?
A 40-person engineering org is rolling out Claude Code. One rule is mandatory for everyone ("never edit files under infra/prod/"); other preferences (preferred commit style, personal aliases) should vary developer to developer. Where should each live?
A coordinator delegates to search, analysis, synthesis, and reporting subagents. The search subagent finds nothing for one of its five sub-queries. Separately, the analysis and synthesis subagents' summaries disagree on a key figure. What should the coordinator do?
Onboarding automation must find every usage of a deprecated internal API across a 4,000-file monorepo it has never seen. It has Grep, Glob, and Read, plus an MCP server for the ticketing system, and must also propose a migration plan. How should the exploration be structured to keep the main session usable?
A pipeline runs Claude Code to review every pull request and generate missing tests. The PR-comment bot needs machine-parseable output, and one PR's run must never carry state into the next PR's run. Which setup satisfies both requirements?
A team needs 12 fields extracted overnight from 50,000 scanned vendor contracts, with an 8-hour deadline. Separately, a live chat widget needs 3 fields extracted from a customer's pasted email while they wait. Some contracts genuinely lack certain fields — for example, no renewal clause. What is the correct combination of API choice and schema design?
Quick glossary
Every term below appears somewhere in this course. If a question uses a word you're unsure of, check here before re-reading the whole lesson.
Agentic loop
The repeating cycle behind any Claude-powered agent: send a request, check what Claude wants to do next (stop_reason), run a tool if asked, send the result back, repeat until Claude is done.
stop_reason
A field on Claude's response telling your code why it stopped talking — e.g. it wants to call a tool (tool_use), it finished (end_turn), or it ran out of room (max_tokens).
tool_use / tool_result
tool_use is Claude asking your code to run something (a search, a database lookup...). tool_result is your code's answer, sent back so Claude can continue.
Subagent / Agent tool
A helper Claude spawns to do one focused piece of work in its own separate memory space, then reports back a summary — so the main conversation doesn't get cluttered with the helper's scratch work.
Hooks (PreToolUse / PostToolUse)
Small scripts that run automatically around a tool call — one right before it (can block it entirely) and one right after (can react to the result). Used for rules that must always hold, not just usually hold.
MCP (Model Context Protocol)
A standard way to connect Claude to external systems — databases, internal tools, company APIs — through a shared plug-in format instead of custom one-off code every time.
MCP Tools vs Resources vs Prompts
The three things an MCP connection can offer: Tools are actions Claude decides to call itself; Resources are data the surrounding app decides to hand Claude; Prompts are ready-made instructions a person picks, like a menu option.
.mcp.json
A config file listing which external MCP connections a project uses — shared with the whole team via version control, with any secret keys kept out of it and read from environment variables instead.
CLAUDE.md
A plain-text file Claude reads automatically at the start of every session in a project — the place for standing instructions like coding conventions or how the codebase is organized.
.claude/rules/
Instructions that only switch on for certain files (e.g. only when editing test files), instead of loading into every single session the way CLAUDE.md does.
Agent Skill
A packaged set of instructions Claude loads by itself when a task matches, without anyone typing a command — think of it as an instruction manual Claude picks up automatically off the shelf.
allowed-tools vs disallowed-tools
Two different settings that sound alike: allowed-tools just skips the usual 'are you sure?' prompt for tools you've pre-approved — it doesn't block anything else. disallowed-tools is what actually removes a tool from what's available.
Plan mode
A mode where Claude describes what it's about to do and waits for a yes before touching any files — used for bigger or riskier changes, skipped for small obvious ones.
Message Batches API
A cheaper way to send Claude a large pile of requests when nobody is waiting on the answer right away — costs about half as much, but can take up to a day to come back.
Prompt caching
A way to avoid Claude re-reading the same large, unchanging block of text (like a system prompt or a codebase) on every single request — it's remembered for a while, which is both cheaper and faster.
Context window
The total amount of conversation and text Claude can 'see' at once for a given request. When a conversation runs long, older parts may need to be summarized or dropped to make room.
Hub-and-spoke (multi-agent)
A setup where one coordinator agent hands out tasks to several helper agents and collects their answers — the helpers never talk directly to each other, only to the coordinator.
Anti-pattern
A design choice that looks reasonable but causes real problems in practice — this course names seven specific ones the exam likes to hide inside wrong answers.
Unofficial study resource — not affiliated with, endorsed by, or sponsored by Anthropic.