What this is about#
Domain 7 of the Claude Certified Associate – Foundations exam is Troubleshooting and Optimization. It’s worth 10% — the lightest domain on the exam. But it’s the one that closes the loop on the other six: everything from prompting to configuration to model selection eventually produces an output that underperforms, and this domain is the discipline of tracing that failure to its root cause, fixing it, and making sure the fix persists instead of getting re-discovered next week.
Key point 1: four failure patterns, four different fixes#
Underperformance almost always traces to one of four patterns, and each leaves a distinct symptom signature. Under-specification — the prompt leaves too much to inference — shows up as inconsistent output shape across otherwise similar runs. Context overload — too much competing information crowding out early instructions — shows up as quality that was fine, then quietly drifted as the session grew. Wrong feature or model — the task needs a different tool entirely — shows up as a prompt that’s fine but capped by the setup underneath it. Stale configuration — instructions, knowledge, or a Skill reflecting an old process — shows up as output that was correct for months and then wrong for no prompt-side reason at all. Naming the pattern before reaching for a fix is most of the diagnosis.
Key point 2: fix cheapest first#
The diagnostic sequence runs from lowest cost to highest: check the prompt and instructions before switching models, check configuration before rebuilding the workflow. Reaching for a bigger model or a full workflow redesign before ruling out a vague instruction or a stale piece of configuration burns time and often doesn’t even fix the problem, because the root cause was never model capability in the first place.
flowchart TD
A[Output underperforming] --> B{Is the prompt or
instruction specific enough?}
B -->|No| C[Fix the prompt/instructions
cheapest, try first]
B -->|Yes| D{Is configuration
stale or missing?}
D -->|Yes| E[Update instructions,
knowledge, or Skill]
D -->|No| F{Is this the right
feature or model tier?}
F -->|No| G[Switch entry point
or model tier]
F -->|Yes| H[Redesign the workflow
last resort, highest cost]
style C fill:#86b6ef,stroke:#5598e7,color:#0b0b0b
style E fill:#2a78d6,stroke:#1c5cab,color:#fff
style G fill:#104281,stroke:#0d366b,color:#fff
style H fill:#d03b3b,stroke:#a32e2e,color:#fff
Key point 3: turn vague critique into a specific adjustment#
“Make it better” isn’t actionable — it gives Claude nothing new to act on, so the next attempt drifts the same way the first one did. Naming the exact dimension that failed is what actually changes the output: not “the tone is off” but “drop the exclamation points and cut every sentence that restates the previous one.” The difference between a captured fix and a lost one is whether that specific adjustment gets written into a standing instruction, or just applied once in the moment and forgotten by the next session.
Key point 4: find friction with three signals, then promote the fix#
Three signals point at a fix worth making permanent: repetition (you’re typing the same correction across sessions), correction (you’re editing the same kind of mistake out of the output every time), and variance (the same request produces meaningfully different quality depending on who asks or when). Once a signal shows up, the fix needs a home — and the test for which one is simple: a rule about behavior goes in standing instructions, a reference fact goes in the knowledge base, a procedure with multiple steps becomes a Skill. Promoting the fix to the right slot is what stops the correction from recurring.
Key point 5: measure improvement against the metric that matters#
A workflow audit that goes from 45 minutes to 25 minutes only counts if the 45 minutes was the actual bottleneck and 25 minutes is measured the same way — same task, same reviewer standard, not a looser one. The temptation is to optimize whatever is easiest to measure; the discipline is optimizing the metric that was actually the complaint in the first place, whether that’s time, revision count, or how often a human has to step in.
Conclusion#
Domain 7 in one pass: name the failure pattern before reaching for a fix — under-specification, context overload, wrong feature or model, stale configuration each leave a different symptom. Fix cheapest first: prompt and instructions before model switches, configuration before workflow redesigns. Turn vague critique into a specific, capturable adjustment instead of a one-off fix. Watch for repetition, correction, and variance, then promote the fix into the right home — rule, reference, or procedure. And measure improvement against the metric that was the actual complaint, not whatever’s easiest to track.
Sources#
- Troubleshooting & Optimization — Anthropic Partner Academy
- Claude Certified Associate – Foundations Exam Guide — official PDF
Where this fits#
Part 9 of Getting Claude Certified. Part 1 covered the 4D Framework, Part 2 covered Chat, Projects, Artifacts, and Research, Part 3 covered Domain 1 — Output Evaluation and Validation, Part 4 covered Domain 2 — Workflow Integration and Solution Design, Part 5 covered Domain 3 — Governance, Risk, and Responsible Use, Part 6 covered Domain 4 — Prompting and Task Execution, Part 7 covered Domain 5 — Product and Model Selection, Part 8 covered Domain 6 — Configuration and Knowledge Management. That’s all 7 exam domains — the series closes here.
