Claude Certification Guide CCAR-F

Quick reference

Every trap from all 27 lessons — 143 of them — grouped by domain. This is revision material, not a substitute for the lessons: the traps make sense once you've read the reasoning behind them. Print-friendly with Ctrl/Cmd + P.

Agentic Architecture & Orchestration

27% · 16 questions · 7 lessons
  • 1.1 Trusting the model to decide when it's done with no enforced fallback
  • 1.1 Treating "the text looks finished" as a termination signal
  • 1.1 Setting max_iterations low enough to silently truncate real work
  • 1.1 Building an open-ended agent for a task with a fixed, enumerable shape
  • 1.1 Logging a runaway loop instead of stopping it
  • 1.2 Reaching for multi-agent orchestration because it sounds more sophisticated
  • 1.2 Fanning out independent subtasks sequentially out of habit
  • 1.2 Chaining stages sequentially when the subtasks don't actually depend on each other
  • 1.2 Ignoring what happens when one branch of a parallel fan-out fails
  • 1.2 Adding a manager layer for two subagents that could just run directly
  • 1.3 Passing the full parent conversation to every subagent "just in case"
  • 1.3 Letting a subagent inherit system-prompt instructions meant for a different role
  • 1.3 Handing off a natural-language summary where a structured field would be reliable
  • 1.3 Assuming isolation is free when it actually requires deliberate design
  • 1.3 Sharing context because it's the default, not because the task needs it
  • 1.4 Assuming a handoff payload has the expected shape without checking
  • 1.4 Treating a missing optional field as automatically safe to ignore
  • 1.4 Advancing a workflow stage before its checkpoint condition is actually verified
  • 1.4 Building enforcement into a prompt instruction instead of a code-level check
  • 1.4 Having no defined behavior for what happens when a handoff fails validation
  • 1.5 Enforcing a safety rule only in the system prompt with no code-level backstop
  • 1.5 Confusing Claude Code's hooks configuration with Agent SDK lifecycle hooks in a custom application
  • 1.5 Logging tool calls after the fact instead of gating them before execution
  • 1.5 Putting guardrail logic in a place the model's own output can influence or bypass
  • 1.5 Using a hook for something a simple return-value check in the tool itself would handle
  • 1.6 Decomposing by how a human team would divide the work, not by agent reliability
  • 1.6 Splitting stable, low-risk steps as finely as volatile, error-prone ones
  • 1.6 Building one giant step that has to be entirely redone on any partial failure
  • 1.6 Fixing a task graph at design time when the right shape depends on the input
  • 1.6 Treating decomposition as a one-time decision instead of something to revisit under load
  • 1.7 Treating the conversation transcript as the system's durable state
  • 1.7 Resuming a session by replaying from the start instead of from a checkpoint
  • 1.7 Building a side-effecting step with no idempotency key
  • 1.7 Assuming a crash mid-step means the step definitely didn't complete
  • 1.7 Storing progress only in memory, with nothing surviving a process restart

Claude Code Configuration & Workflows

20% · 12 questions · 6 lessons
  • 3.1 Treating CLAUDE.md as a place for one-off, per-request instructions
  • 3.1 Duplicating the same convention across every subdirectory's CLAUDE.md
  • 3.1 Assuming a single monolithic CLAUDE.md scales to a large monorepo
  • 3.1 Putting secrets or environment-specific values in a file committed to git
  • 3.1 Believing CLAUDE.md changes take effect mid-session without a reload
  • 3.2 Creating a skill for a task that's only ever done once
  • 3.2 Writing a vague skill description that never triggers or triggers on everything
  • 3.2 Letting a skill's full working output land back in the main session
  • 3.2 Duplicating logic across two skills instead of one skill both paths can call
  • 3.2 Assuming a skill runs with the same permissions and context as the main session by default
  • 3.3 Assuming a session 'forgot' something when it was actually crowded out by repeated verbose output
  • 3.3 Forking every skill regardless of whether isolation is needed
  • 3.3 Believing a forked skill shares live state with the main session while it runs
  • 3.3 Designing a forked skill's summary as vaguely as its full output
  • 3.3 Treating context: fork as a performance optimization rather than a context-budget one
  • 3.4 Reaching for /compact as the fix for every long-session problem
  • 3.4 Assuming compaction preserves exact quotes and file:line references
  • 3.4 Compacting repeatedly instead of fixing a single noisy source of context bloat
  • 3.4 Not knowing what a session loses across a compaction boundary
  • 3.5 Writing 'never run rm -rf' as an instruction instead of a blocking hook
  • 3.5 Confusing Claude Code's settings.json hooks with a custom Agent SDK's lifecycle hooks
  • 3.5 Making a hook so aggressive it blocks legitimate, safe operations
  • 3.5 Forgetting that a hook is configuration, not something the model can talk itself out of
  • 3.6 Assuming user-level settings can override an enterprise-level restriction
  • 3.6 Setting permissions only at the project level and ignoring enterprise policy
  • 3.6 Writing an allow list so broad it approves risky operations by accident
  • 3.6 Not testing what a new team member's effective permissions actually are

Prompt Engineering & Structured Output

19% · 11 questions · 5 lessons
  • 4.1 Putting per-request or per-user data in the system prompt
  • 4.1 Letting the system prompt grow by one paragraph per new tool
  • 4.1 Duplicating a tool's description inside the system prompt
  • 4.1 Treating the system prompt as the place for one-off instructions
  • 4.1 Assuming a longer system prompt is a more thorough one
  • 4.1 Never revisiting the system prompt as the agent's capability set changes
  • 4.2 Prompting for JSON and hoping the model complies exactly
  • 4.2 Treating any schema violation as a reason to surface a raw error to the user
  • 4.2 Writing a schema so permissive the model has no real constraint to work against
  • 4.2 Not checking stop_reason before parsing output as complete
  • 4.2 Retrying a malformed response with the identical prompt
  • 4.2 Assuming tool-use output never needs validation because it's 'structured'
  • 4.3 Standardizing a technique that only worked because of one prompt's specific wording
  • 4.3 Choosing few-shot examples that all share an incidental pattern the model overfits to
  • 4.3 Requesting chain-of-thought reasoning purely as user-facing display copy
  • 4.3 Leaving the output contract implicit instead of stating it explicitly
  • 4.3 Believing more examples always helps
  • 4.3 Not versioning prompt technique changes the way code changes are versioned
  • 4.4 Assuming a constraint stated once at turn 1 stays in effect at turn 40
  • 4.4 Re-stating every constraint every turn, bloating cost for no reliability gain
  • 4.4 Not noticing when compaction or history pruning silently dropped an earlier constraint
  • 4.4 Treating a long session as just 'more of the same turn' rather than its own reliability regime
  • 4.4 Failing to distinguish stable identity constraints from constraints that change as the task shifts
  • 4.4 Only testing prompts against a short happy-path conversation before shipping
  • 4.5 Parsing output without checking stop_reason first
  • 4.5 Assuming a well-formatted response is also a correct one
  • 4.5 Passing unvalidated output directly into a downstream system with side effects
  • 4.5 Silently defaulting a missing field instead of flagging it
  • 4.5 Building validation that only checks syntax, not the business-logic constraints that matter
  • 4.5 Not logging validation failures, so drift goes unnoticed until it's a production incident

Tool Design & MCP Integration

18% · 11 questions · 5 lessons
  • 2.1 Naming a tool after its internal implementation instead of its effect
  • 2.1 Writing a description for a human maintainer instead of the calling model
  • 2.1 Leaving a parameter's format unconstrained when only a few values are valid
  • 2.1 Shipping two tools whose descriptions could both plausibly apply to the same request
  • 2.1 Assuming a working demo with one tool proves the schema at ten tools
  • 2.1 Making a required field optional to be 'flexible'
  • 2.2 Letting an unhandled exception propagate as the tool result
  • 2.2 Returning an empty or generic failure with no actionable detail
  • 2.2 Setting isError without including a message the model can act on
  • 2.2 Treating every failure as retryable, or every failure as terminal
  • 2.2 Logging the error server-side and returning nothing useful to the agent
  • 2.2 Exposing internal stack traces or secrets in an error message
  • 2.3 Treating stdio and HTTP as interchangeable with only a syntax difference
  • 2.3 Building a shared, multi-user tool on a stdio server meant for one local process
  • 2.3 Deferring transport choice until after the server's auth model is designed
  • 2.3 Assuming an HTTP MCP server needs no more security thought than a local one
  • 2.3 Choosing HTTP for a purely local dev tool out of habit
  • 2.4 Assuming tool names from different servers won't collide
  • 2.4 Letting one slow MCP server block the entire agent turn
  • 2.4 Connecting every agent instance directly to every server with no gateway
  • 2.4 Treating server unavailability as equivalent to a tool-level error
  • 2.4 Not revalidating tool discovery when a connected server's tools change
  • 2.5 Putting an API key in a prompt or tool parameter the model can see
  • 2.5 Using one long-lived, broadly-scoped credential for every external call
  • 2.5 Assuming a tool's auth is fine because it worked in testing with one user
  • 2.5 Letting a tool's error message leak part of a credential or token
  • 2.5 Skipping scope review because 'the tool only reads data'

Context Management & Reliability

16% · 10 questions · 4 lessons
  • 5.1 Sizing a system prompt and tool set against the full context window with no headroom
  • 5.1 Pruning only when a call already failed
  • 5.1 Treating all history as equally prunable
  • 5.1 Assuming a bigger context window removes the need for a budget
  • 5.1 Summarizing tool output only after it has already blown the budget once
  • 5.1 Forgetting that the response itself consumes budget the request has to leave room for
  • 5.2 Applying one caching decision uniformly across every agent in a system
  • 5.2 Defaulting to the longer TTL everywhere without checking the cost tradeoff
  • 5.2 Letting a pruning step rewrite content that sits before the cache checkpoint
  • 5.2 Assuming a shared prefix across agents will get cached without a shared checkpoint
  • 5.2 Treating cache verification as a one-time check instead of ongoing monitoring
  • 5.2 Optimizing cache hit rate for a low-traffic path while ignoring the high-traffic one
  • 5.3 Retrying a side-effecting tool call without an idempotency key
  • 5.3 Using one timeout value for both streaming and non-streaming calls
  • 5.3 Retrying immediately with no backoff, amplifying load during an outage
  • 5.3 Treating a timeout as proof of failure and retrying a call that actually succeeded
  • 5.3 Setting max retry attempts high enough to mask a systemic outage as a slow day
  • 5.3 Building retries at every layer independently, so one failure retries N times over
  • 5.4 Logging only final output and losing every intermediate decision the agent made
  • 5.4 Treating a spike in max_tokens stop_reason as normal instead of a signal
  • 5.4 Relying on manual spot-checks as the only quality gate before a release
  • 5.4 Building an eval set only from happy-path examples
  • 5.4 Not tracking loop iteration counts, so a runaway agent looks like normal load
  • 5.4 Evaluating a prompt change without a baseline to compare it against