CCA-F Certification Prep · lesson 8 of 10

CCA-F Scenarios — Playbooks

Six scenario types in the exam pool. Each exam attempt samples four. Every scenario has a "canonical" architecture; the exam tests whether you can spot it and the trade-offs around it.

Scenario 1 — Customer Support Resolution Agent

Tag: #scenario/support

What it tests

A production support agent that handles returns, billing, account issues. Goal: high first-contact resolution, accurate escalation, compliance.

Canonical architecture

flowchart LR
    U([User msg]) --> CL[Intent classifier<br/>Haiku + few-shot]
    CL -- billing --> B[Billing handler]
    CL -- support --> S[Support handler]
    CL -- refund --> R[Refund handler<br/>+ confirm gate]
    CL -- unclear / low-confidence --> H[Escalate to human]
    B --> O([Response w/ provenance])
    S --> O
    R --> O

Tools used per handler:

lookup_customer, lookup_order (read-only)
process_refund (destructive — requires confirm: true arg)
escalate_to_human (always available)

Key decisions

Routing first. Single mega-prompt loses to a router + specialists.
Tools with confirmation. Refunds, cancellations, address changes — confirm: true arg + host confirmation flow.
Stale data hazards. Customer balance, order status — always read fresh, don't trust 20-turn-old data.
Escalation criteria as principles, not endless conditionals.
Provenance. Cite which policy / order ID drove the decision.

Common pitfalls (= exam wrong answers)

"Handle everything in one prompt with 30 conditional rules" → dilution.
"Cache the customer's order list at session start" → goes stale within minutes.
"Auto-issue refunds under $50" without confirm + audit log → compliance risk.

Domain map

Primary: cca-domain-1-agents, cca-domain-2-tools-mcp, cca-domain-5-context-reliability.

Scenario 2 — Code Generation with Claude Code

Tag: #scenario/code-gen

What it tests

A team using Claude Code for day-to-day engineering. Multi-developer workflows, shared conventions, safe defaults.

Canonical architecture

Developer
  → claude (CLI / IDE)
    • CLAUDE.md (shared + local)
    • .claude/settings.json (shared) + .local.json (per-user)
    • .claude/commands/* slash commands
    • .claude/skills/* reusable skills
    • .claude/agents/* subagents (Explore, Verify, ...)
  → Hooks: PostToolUse lint, Stop test
  → Plan mode for ambiguous tasks

Key decisions

Where does a convention live? Shared vs personal vs subdir scope.
Plan mode when scope is ambiguous; direct execute when narrow.
Slash commands vs skills vs subagents — match by who invokes and what's loaded.
Permissions: deny destructive, allow common safe tools, prompt the rest.

Common pitfalls

Putting team conventions in ~/.claude/CLAUDE.md → only on one machine.
Skipping plan mode for a multi-file refactor → off-the-rails result.
Permissive allow ["*"] in shared settings → safety footgun for the team.

Domain map

Primary: cca-domain-3-claude-code, cca-domain-1-agents.

Scenario 3 — Multi-Agent Research System

Tag: #scenario/research

What it tests

A research agent that synthesizes a report from many sources. Coordinator + specialized workers.

Canonical architecture

flowchart TB
    User([Research question]) --> O[Orchestrator<br/>Opus + plan mode]
    O -- "search 10 topics in parallel" --> S1[search_subagent x N<br/>Haiku]
    S1 -- "ranked citations" --> O
    O -- "deep-read top sources" --> A[analyze_subagent<br/>Sonnet]
    A -- "themed findings" --> O
    O -- "synthesize themes" --> Sy[synth_subagent<br/>Sonnet]
    Sy --> O
    O -- "draft" --> W[write_subagent<br/>Sonnet]
    W -- "draft + citations" --> E[evaluator<br/>Sonnet]
    E -- "feedback" --> W
    E -- "approved" --> Out([Final report])

Key decisions

Orchestrator-workers is the canonical pattern.
Context isolation — each subagent gets its own context, only summaries return.
Provenance threading — workers tag findings with source IDs; orchestrator preserves them.
Parallelism where independent (search 10 topics simultaneously).
Evaluator-optimizer for final polish: an editor agent reviews draft, generator revises.

Common pitfalls

Single mega-context with all sources → context explosion + "lost in middle".
Subagents sharing mutable state → races, contradictions.
Forgetting provenance — final report can't cite sources.

Domain map

Primary: cca-domain-1-agents, cca-domain-5-context-reliability, cca-domain-4-prompting.

Scenario 4 — Developer Productivity Tools

Tag: #scenario/dev-tools

What it tests

An IDE-integrated assistant: code navigation, refactor suggestions, doc lookup. Heavy MCP usage.

Canonical architecture

IDE host (Claude Code / VS Code)
  ├── MCP: filesystem (read project)
  ├── MCP: git (history, blame)
  ├── MCP: linear (tickets)
  ├── MCP: docs (internal wiki, RAG)
  └── built-in Read/Grep/Glob/Bash

Key decisions

MCP primitives: filesystem read = resources; "create ticket" = tool; "summarize this issue" = prompt (slash command).
Trust scopes — read-only credentials for first installations.
Caching internal docs in system prompt content blocks for grounded Q&A.
Resource URIs for large blobs (full file content, image attachments).

Common pitfalls

Exposing filesystem MCP with no path allowlist → traversal.
Returning entire repo trees inline → context blowup.
Tool descriptions don't disambiguate (search vs search_code vs search_tickets).

Domain map

Primary: cca-domain-2-tools-mcp, cca-domain-3-claude-code.

Scenario 5 — Claude Code in CI/CD

Tag: #scenario/cicd

What it tests

Running Claude Code unattended in CI: automated reviews, test generation, PR feedback.

Canonical architecture

flowchart LR
    PR([PR opened]) --> CI[CI workflow]
    CI --> CC[claude --print 'review diff'<br/>--output-format json]
    CC -.-> AC[Allowed: Read, Grep, Glob, Bash gh:*]
    CC -.-> DN[Denied: Edit, Write, Bash rm:*, Bash git push:*]
    CC -.-> HK[Hooks: SessionStart fetch metadata,<br/>Stop post review]
    CC --> J([JSON envelope])
    J --> P[Parse + post as PR comment]

Key decisions

--print + narrow permissions for non-interactive safety.
--output-format json for parseable output.
Hooks to wire to GitHub APIs and run tests.
Session isolation (worktree subagent or fresh checkout) for write-side ops.
Deny destructive explicitly — never trust * allow in shared CI config.

Common pitfalls

Interactive prompts hanging the build because confirmation wasn't pre-allowed.
git push --force allowed → bad day.
No iteration cap → CI bill spikes.
Reading more than the PR diff → wasted tokens.

Domain map

Primary: cca-domain-3-claude-code, cca-domain-5-context-reliability.

Scenario 6 — Structured Data Extraction

Tag: #scenario/extraction

What it tests

Bulk extracting structured fields from unstructured documents (invoices, contracts, forms).

Canonical architecture

flowchart LR
    Docs([PDFs / images / text]) --> B[Message Batches API<br/>Haiku or Sonnet<br/>cached system prompt]
    B --> F[Forced tool use<br/>tool_choice = extract_X]
    F --> V{Validate<br/>jsonschema}
    V -- pass --> DB[(Structured store<br/>w/ provenance)]
    V -- fail --> RT{Retry < 3?}
    RT -- yes --> B
    RT -- no --> HQ[Human review queue]

Key decisions

Forced tool use for the extraction schema. Most reliable structured output.
Batch API for offline volume → 50% discount.
Validation + retry loop with error feedback included.
Provenance fields in schema for audit (field_value + field_source).
Confidence + human review for low-confidence extractions.
Caching the system prompt (schema description, examples, policy) for huge cost savings.

Common pitfalls

Asking for JSON in prose only → unreliable.
No validation loop → silently corrupt data downstream.
Putting volatile timestamps in cached system prompt → cache misses.
One huge schema → flatten or split.

Domain map

Primary: cca-domain-4-prompting, cca-domain-2-tools-mcp, cca-domain-5-context-reliability.

Cross-cutting heuristics

Smallest pattern that works.
Specialize the workers, generalize the orchestrator.
Make destructive ops require confirmation.
Provenance threads through everything.
Cache stable; refresh volatile.

CCA-F Scenarios — Playbooks

Scenario 1 — Customer Support Resolution Agent

What it tests

Canonical architecture

Key decisions

Common pitfalls (= exam wrong answers)

Domain map

Scenario 2 — Code Generation with Claude Code

What it tests

Canonical architecture

Key decisions

Common pitfalls

Domain map

Scenario 3 — Multi-Agent Research System

What it tests

Canonical architecture

Key decisions

Common pitfalls

Domain map

Scenario 4 — Developer Productivity Tools

What it tests

Canonical architecture

Key decisions

Common pitfalls

Domain map

Scenario 5 — Claude Code in CI/CD

What it tests

Canonical architecture

Key decisions

Common pitfalls

Domain map

Scenario 6 — Structured Data Extraction

What it tests

Canonical architecture

Key decisions

Common pitfalls

Domain map

Cross-cutting heuristics

See also