Claude Certified Associate - Foundations common mistakes
Claude Certified Associate - Foundations · Understand the traps and how to avoid them.
Selects the largest, most expensive model tier for every task, including simple extraction, classification, and routing questions.
Candidates equate "most capable" with "correct answer" and never build the habit of matching tier to latency, cost, and reasoning depth.
What to do instead
Memorize one decision rule per tier (small/fast for high-volume classification and extraction, mid-tier for general generation and tool use, top tier for multi-step reasoning and hard coding), then practice labelling sample tasks by tier before choosing an answer.
Answers API questions as if the model remembers earlier calls, e.g. claiming a follow-up request will "recall" a prior request without resending it.
Experience with the chat product, where history is managed for you, leaks into API reasoning; statelessness is easy to read once and easy to forget under time pressure.
What to do instead
State the rule explicitly while reasoning: each request carries its own system prompt, prior turns, and new message; multi-turn behaviour comes from the client resending (and possibly trimming or summarizing) history.
Writes persona, constraints, and formatting rules into the first user message while leaving the system prompt empty, or fills the system prompt with a persona that contradicts the user turn.
Chat habits carry over, and the system prompt feels optional when a single-turn test still produces plausible output.
What to do instead
Assign roles deliberately: stable identity, behavioural constraints, refusal rules, and the output contract go in the system prompt; volatile task data and the question go in the user turn; check that no instruction in one contradicts the other.
Specifies only prohibitions ("do not ramble", "don't be too salesy") with no target length, structure, or schema.
Negative phrasing mirrors how people naturally give feedback, and it feels sufficient because the desired behaviour seems obvious to the author.
What to do instead
Rewrite each prohibition as a positive, checkable requirement (word limit, required sections, JSON schema, tone sample) and include one short example of a compliant output.
Treats any response as complete without reading stop_reason, and assumes max_tokens limits input length rather than generated output.
Happy-path responses end with end_turn, so truncation rarely appears in casual testing, and max_tokens sounds like a general size cap.
What to do instead
Branch on stop_reason in every design answer (continue on max_tokens, raise the cap, or request shorter output), and remember input plus output must fit the context window while max_tokens caps generation only.
Designs integrations that treat rate-limit and overloaded responses as fatal, with no retry, backoff, or timeout policy.
Prototypes run against a quiet account where the first call almost always succeeds, so error paths are never exercised.
What to do instead
Describe exponential backoff with jitter, capped retries, idempotency keys for tool side effects, and a user-visible fallback; distinguish retryable conditions from malformed-request errors that should not be retried.
Pastes the whole document corpus and full conversation history into every call, then attributes the quality drop or failure to the model.
More context feels safer than selection, and token cost and window pressure are invisible until measured.
What to do instead
Budget tokens per component, retrieve or chunk only relevant passages, summarize or drop stale turns, and order stable prefixes first so prompt caching can be applied.
Describes safety as "the system prompt tells Claude to be careful", with no input validation, output filtering, or escalation path.
Prompt-level guardrails are quick to demo and look like policy enforcement, while layered controls force design decisions candidates would rather avoid.
What to do instead
Describe defense in depth: input screening, least-privilege tool permissions, output checks before sensitive actions, logging, and human review for high-impact decisions; also separate refusing genuinely harmful requests from answering legitimate sensitive topics.
Validates a prompt by trying two or three happy-path inputs and shipping once the outputs read well.
Manual spot checks feel like testing and give fast positive feedback, while building a labelled set takes time candidates do not budget.
What to do instead
Define a small graded eval set covering normal, edge, and adversarial cases with a written rubric and a stored baseline, then report pass rates against that baseline on every change.
Changes prompt, model tier, and temperature in a single iteration, or keeps prompt drafts in scratch notes, so nobody can attribute the improvement.
Iteration pressure pushes candidates to fix everything at once, and prompt text is rarely treated as versioned code.
What to do instead
Change one variable per run, keep prompts in version control with an ID and changelog, and re-run the full eval set before promoting any version.