The Six Scenarios, Worked

The exam is scenario-based: it presents four of six production scenarios, and the questions reason about those systems. So the best final preparation isn’t re-reading the domains — it’s walking each scenario and asking “which decisions matter here, and which tempting answers are traps?” This capstone does that, pulling the whole series together the way the exam pulls it together. Each scenario names its primary domains; the design calls and traps are the payoff.

Scenario 1: Customer Support Resolution Agent

Agent SDK; MCP tools get_customer, lookup_order, process_refund, escalate_to_human; 80%+ first-contact resolution. Domains 1, 2, 5.

The design spine: an agentic loop that drives on stop_reason, MCP tools with structured errors, and escalation judgment. The decisions that matter:

• Escalation triggers are the heart of it. Escalate immediately on an explicit request for a human; escalate on a policy gap (competitor price match when policy only covers own-site); offer to resolve when a frustrated customer’s issue is in-policy. Traps: escalating on sentiment, or on the model’s self-reported confidence.
• Structured errors on process_refund: a refund outside the return window is a business error, isRetryable: false, with a customer-friendly message, not a generic failure the agent retries.
• Ambiguity: if get_customer returns multiple matches, ask for an identifier; don’t guess.
• Context: a case-facts block keeps the order number, amount, and the customer’s stated expectation precise across the conversation, and tool outputs get trimmed to relevant fields.

Scenario 2: Code Generation with Claude Code

Claude Code in a dev workflow: generation, refactoring, debugging, with slash commands, CLAUDE.md, and plan mode. Domains 3, 5.

Almost pure Claude Code configuration. The decisions:

• Plan mode vs. direct execution: plan a multi-file refactor or an architectural change; execute a single-file bug fix directly. Combine: plan the investigation, execute the approved plan.
• CLAUDE.md placement: team conventions in the project file, not user-level (the teammate-not-getting-instructions trap); path-specific rules for file-type conventions that span directories.
• Commands vs. skills: a /deploy you invoke is a command; a convention Claude should apply on its own is a skill, with context: fork for verbose ones.
• Refinement: concrete examples and failing tests over more adjectives; the Explore subagent to keep discovery from eating context.

Scenario 3: Multi-Agent Research System

A coordinator delegating to search, analyze, synthesize, and report subagents, producing cited reports. Domains 1, 2, 5.

The multi-agent showcase. The decisions:

• Decomposition must be complete and disjoint: partition the topic so coverage has no gaps and no duplication. Trap: decomposition so narrow it leaves gaps.
• Context isolation: subagents inherit no conversation history, so the coordinator passes each its scope explicitly.
• Error propagation — a failed search subagent returns structured error context (what it tried, partial results), and synthesis carries coverage annotations. Traps: suppressing the error as an empty result, or killing the whole workflow on one failure.
• Provenance — claim-source mappings survive synthesis; conflicting statistics are annotated with attribution, not arbitrarily resolved; dates prevent temporal differences from reading as contradictions.

Scenario 4: Developer Productivity with Claude

An agent exploring unfamiliar codebases with the built-in tools plus MCP servers. Domains 2, 3, 1.

The decisions center on tools and context:

• Built-in tool selection — Grep for content, Glob for file patterns, Read to follow imports; Read+Write when Edit’s unique-anchor requirement fails. Build understanding incrementally — Grep entry points, then Read to trace — rather than reading everything upfront.
• Context degradation — over a long exploration, scratchpad files persist findings, subagents isolate verbose discovery, and /compact reclaims context.
• MCP integration — project-scoped .mcp.json with env-var secrets; enhanced tool descriptions so the agent prefers a capable MCP tool over built-in Grep.

Scenario 5: Claude Code for CI/CD

Claude Code in a pipeline running automated reviews and test generation, minimizing false positives. Domains 3, 4.

The decisions:

• Non-interactive execution — -p to prevent hangs, --output-format json with --json-schema for parseable findings to post as PR comments.
• Precision — explicit categorical criteria (“flag a comment only when it contradicts the code”) over “be conservative”; disable a high-false-positive category to protect trust in the accurate ones; few-shot examples for consistent finding format.
• Independent review — the review runs in a fresh instance, not the session that generated the code, because a session invested in its own reasoning is the worst judge of it.
• No duplicate work — include prior findings on re-runs; provide existing tests so generation doesn’t duplicate coverage; CLAUDE.md carries the review criteria.

Scenario 6: Structured Data Extraction

Extracting from unstructured documents, validating against JSON schemas, handling edge cases. Domains 4, 5.

The structured-output scenario:

• Guaranteed shape — tool_use with a JSON schema, forced via tool_choice (or "any" when the document type is unknown). Trap: believing a strict schema validates correctness — it fixes syntax, not semantics.
• Schema design against fabrication — optional/nullable fields so the model returns null instead of inventing a required value; "unclear"/"other"+detail enums for edge cases.
• Validation loops — retry with specific error feedback; extract calculated_total alongside stated_total to catch discrepancies. Trap: retrying when the information is simply absent from the source — recognize it and stop.
• Scale and trust — the Batches API for overnight volume (never for a tool-using agent); calibrated confidence and stratified sampling to route human review, validated by document type and field — because an aggregate accuracy number hides per-segment failure.

The pattern behind the patterns

Reading the six together, the same handful of principles recur, and they’re the exam’s real content:

• Structure over heuristics. Loop on stop_reason, not on parsed text; escalate on policy coverage, not sentiment; enforce with hooks and gates, not prompts.
• Be honest about uncertainty. Annotate coverage gaps and source conflicts; return null over a fabricated value; surface ambiguity instead of guessing.
• Isolate to stay reliable. Independent reviewers, forked skill contexts, subagent-scoped exploration, case-facts kept outside the summary.
• Scope tightly. Few well-described tools, criteria over adjectives, decomposition that’s complete and disjoint.

If an exam item offers a structured answer against a heuristic one, an honest answer against a falsely-clean one, or a tightly-scoped answer against a catch-all, the first is almost always right. That instinct, more than any single fact, is what the CCA-Foundations exam is built to reward.

Final thoughts

The exam frames everything as a scenario, so prepare by inhabiting the scenarios: for each, know the domains it draws on, the two or three decisions that carry it, and the tempting wrong answers it will offer. Across all six, the winning instinct is the same — prefer structure to heuristics, honesty to false certainty, isolation to entanglement, and tight scope to catch-alls. Build the systems these scenarios describe with the Agent SDK and Claude Code, and the questions stop being trivia and start being obvious. That’s the whole aim of this series, and the whole point of the credential.

Back to the exam overview, or start building — the best preparation is a real agent you wrote yourself.