The 6 Exam Scenarios

CCA Associate Foundations course · Page 9 of 10 · ← Back to all courses · Scenario questions dominate this exam. For each one below, learn the key decisions and the anti-patterns — every wrong answer on the real exam is built from one of these.

1. Customer Support Escalation & Governance

Domains: D2, D4, D6 Key decisions: valid escalation triggers are an explicit human request or a genuine policy gap — never sentiment or the agent's own confidence score · a policy gap gets escalated, not silently denied or silently approved · a complete handoff includes customer ID, root cause, the specific amounts, and a recommended next action · irreversible actions (refunds, external emails) need human sign-off before they execute, not after. Anti-patterns (wrong answers): escalating because the customer sounds frustrated · trusting the agent's self-reported confidence · denying a request just because no policy explicitly covers it · a handoff document that's just a CRM link with no synthesis.

2. Knowledge Base / RAG Accuracy Review

Domains: D2, D7 Key decisions: if the correct documents were retrieved and the answer is still wrong, that's a hallucination/grounding failure, not retrieval — the fix is tighter grounding and citations, never a stronger instruction · accuracy must be measured against a labeled dataset, and checked per document type, not just in aggregate · two credible sources disagreeing get both values shown with attribution. Anti-patterns: blaming chunking or embeddings when retrieval already succeeded · accepting 96% aggregate accuracy as sufficient to remove human review · averaging or silently picking one of two conflicting numbers.

3. Model and Product Selection for a New Deployment

Domains: D3, D4 Key decisions: name the user first — a non-technical team with a repeated workflow gets Claude.ai Projects, not the API · default to Sonnet; move to Haiku only once evals show it holds accuracy, move to Opus only once evals show Sonnet actually falls short · a cost-constrained scenario with two passing options always favors the cheaper one · every model swap is evaluated like a release, with the acceptance threshold set before testing. Anti-patterns: recommending the API "because it's more powerful" for a non-technical audience · defaulting to Opus everywhere without a measured gap · reusing an Opus-tuned prompt unchanged on Sonnet and assuming equivalent quality.

4. Automating a Document Extraction Workflow

Domains: D2, D4, D7 Key decisions: discovery must capture what the system must NOT do before design starts, and the current-process baseline must be captured before deployment — there's no retroactive fix for a missing baseline · low-confidence or contradictory-source extractions route to human review, calibrated against a labeled set, with ongoing stratified sampling of the auto-accepted items · a cost model built from average request size can understate real cost 2–3× when a long tail of large documents dominates spend. Anti-patterns: starting to build before all five discovery outputs exist · auto-accepting a high-confidence extraction from a self-contradictory source document · sizing a token budget from the average input alone.

5. Rolling Out Claude to a Team

Domains: D5, D6 Key decisions: team-wide conventions belong in project-level .claude/CLAUDE.md, committed to the repo — never in a personal ~/.claude/ file · MCP server config is committed, but the API key is referenced as an environment variable, never hardcoded · a champion-then-batch rollout (one champion per department proves the workflow, then trains peers) prevents one person from becoming the sole point of contact for the whole company · spend controls (model defaults, allowlists, per-user caps) are set deliberately, not left to default. Anti-patterns: writing team standards into personal user-level config · committing a raw API key "since only the team can see the repo" · launching to everyone simultaneously with no local champions · granting broad or admin-level CI permissions "to avoid failures."

6. Diagnosing a Production Quality Problem

Domains: D1, D2, D7 Key decisions: classify the failure before picking a fix — uniform failure across every input = prompt failure (rewrite criteria); fails only on complex tasks = model mismatch (test a higher tier); correct docs, wrong answer = hallucination (ground it); wrong docs = retrieval failure (fix chunking/embeddings) · change one variable at a time and predefine the metric before testing · an eval suite that predates a recent change can pass while testing behavior that no longer exists — that's worse than no eval suite, because it looks like coverage. Anti-patterns: rewriting the prompt when the real cause is a hallucination · changing the prompt and the model version in the same test · treating "the tests still pass" as proof nothing broke after a change.

Next: the exam cheatsheet for the rapid-recall version of every rule above.