CCA Associate: The 6 Exam Scenarios

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.