CCA-A exam distractors are almost always anti-patterns dressed up to look correct. If you can spot the anti-pattern, you can eliminate wrong answers before reading them in detail. 3 are critical (drop you below the 720/1000 pass mark if missed), 12 are common, and 2 are edge cases.
Writing every prompt the same way regardless of whether the task is analytical, exploratory, or generative, then blaming Claude when the output doesn't fit the task.
Analysis, research, drafting, and brainstorming each call for a different prompt structure - match the approach to what the task actually needs.
Asking for an entire multi-step deliverable in a single prompt, then getting an output that's shallow on every step because none of them were isolated.
Break a complex ask into its component steps and prompt for them individually or sequentially, iterating on each.
Treating confident, well-written prose as evidence of accuracy, and shipping it without checking whether the facts actually hold up.
Fluency is not accuracy. Run an explicit accuracy-and-completeness check before anything Claude produces goes out the door.
Deep-dive: /concepts/evaluating-output-accuracy-completeness →
Mistaking a confident, well-structured answer for one that's been verified, and skipping the fact-checking step because the output 'sounds right.'
Tone is not a signal of correctness. Actively check for hallucinated facts, internal inconsistencies, and bias before trusting the output.
Deep-dive: /concepts/identifying-and-validating-ai-output-errors →
Forwarding Claude's first-pass output directly to a client or executive without adjusting register, structure, or level of detail for who's actually going to read it.
The first draft is written for you as the prompter. Adapt register and structure before it reaches its actual audience.
Leaving a deliverable as scrollback in a chat window when it needs to be a standalone document, spreadsheet, or structured artifact someone else can open and use.
Match the format to how the result will actually be used and shared, not to whatever the chat interface defaults to.
Deep-dive: /concepts/choosing-output-formats-artifacts-vs-inline →
Re-explaining the same background context in every new chat instead of setting up a Project that holds instructions and knowledge sources persistently.
Projects, research mode, chat, and artifacts each fit different task shapes - choose deliberately instead of always reaching for plain chat.
Always using whichever model tier you used last time, regardless of whether this task needs the extra quality or would be served just as well by a faster, cheaper tier.
Match model tier to the specific cost, speed, and quality trade-off the task in front of you actually requires.
Introducing Claude into a team process because it seems useful, without first analyzing what the workflow actually needs or where the gap is.
Start with requirements analysis and research and planning, then decide where Claude actually fits.
Deep-dive: /concepts/claude-for-research-planning-and-solution-design →
Replacing an entire established workflow with a Claude-first version overnight, before anyone has validated that the augmented version actually works better.
Fold Claude into the existing process as an augmentation before considering a full redesign.
Deep-dive: /concepts/integrating-claude-into-existing-workflows →
Presenting only the successful outputs to stakeholders, leaving them with an inflated sense of what Claude can reliably do and no calibration on where it fails.
Set expectations honestly - stakeholders who understand the limitations trust the wins more, not less.
Setting up a Project's knowledge base at launch and letting it go stale as the underlying information changes, so Claude keeps citing outdated material.
Treat Project configuration as a living asset that needs periodic review, not a one-time setup task.
Enabling every knowledge connector (Drive, Gmail, and more) 'just in case' rather than scoping access to what the Project actually requires.
Connect only the sources a given Project genuinely needs - broader access isn't free and isn't automatically better.
Sharing client data, health information, or other regulated content with Claude without first checking whether it's appropriate to do so.
Check data sensitivity and applicable regulation before anything goes into a prompt or Project - not after.
Assuming IT or compliance owns AI governance entirely, and using Claude without checking whether the organization's own policy actually permits this use case.
Governance policy applies to how you personally use Claude day to day, not only to the systems IT builds.
Concluding 'Claude just can't do this' after one weak output, instead of diagnosing what specifically went wrong with the prompt or task framing.
Treat a weak output as a diagnostic signal about the prompt, not a verdict on the tool. Adjust and retry.
Fixing one bad result by hand-editing it, without changing the prompt or process that will produce the same weak result again next time.
Fix the pattern that produced the weak output, not just the one instance in front of you.
Deep-dive: /concepts/optimizing-ai-workflows-for-efficiency →
Take the free CCA-A diagnostic. No signup, about 10 minutes. Most distractors are one of the 17 patterns above - see how many you can spot.