7 domains and 28 published objectives, each with its official weight, what the domain tests, the decision rules that settle most of its items, the traps the wrong options set, and every objective in plain words, with the official documentation page to read where there is one.
1
Prompting and Task Execution
14% of the exam · 4 published objectives
14%
Domain 1 carries 14 percent of the blueprint, roughly eight of the 60 items, and tests whether you can turn a business intention into an instruction Claude can act on. Its four objectives are building a prompt that states the goal, context, constraints and deliverable; splitting a large request into ordered steps; improving a prompt through deliberate revisions; and changing technique according to whether the job is analysis, research, drafting or idea generation.
You are rarely asked to write a prompt from nothing. A stem describes an associate, a task and a first attempt that produced something vague, bloated or off-target, then offers four revisions or four ways to structure the work. The weaker options add emphasis, repeat the request louder or ask for everything in one pass. The right option pins down who the output is for, what form it takes and how anyone will know it is finished, and puts a checkpoint wherever an early mistake would flow onward.
Decision rules
- Name the reader, the format, the length and the finish line before the task itself; an option that does this beats one that adds quality adjectives.
- Split a request where a mistake would carry forward or where a person has to sign off, not simply where the text gets long.
- Change one thing per revision and compare outputs against the stated success criterion, not a feeling that the second draft reads better.
- Match the technique to the job: give brainstorming room and quantity, analysis the criteria and evidence, drafting a sample of the target voice.
Traps
- The more-words option: a revision that lengthens the prompt with emphasis and courtesy but still leaves the deliverable undefined.
- The single-pass option: asking for research, analysis, recommendations and a formatted deck in one prompt when each depends on the last.
- The brainstorm run like an audit: constraining an ideation task so tightly that the option removes the variety the stem asked for.
Objectives
- Create effective prompts for business and technical tasks. Write a prompt that gives Claude the goal, the audience, the relevant context and the shape of the deliverable for a business or light technical job. Read: Be clear, direct, and detailed
- Apply task decomposition techniques to structure complex requests. Break a large or multi-stage request into ordered pieces so that each step has a clear input, a clear output and a place to check the work. Read: Chain complex prompts for stronger performance
- Iterate prompts to improve output quality. Revise a prompt in deliberate steps, judging each version against a stated standard rather than rewriting from scratch. Read: Use our prompt improver to optimize your prompts
- Adapt prompting strategies based on task type (e.g., analysis, research, drafting, brainstorming). Change how you prompt depending on whether the job is analysis, research, drafting or idea generation, since each rewards a different structure. Read: Let Claude think (chain of thought prompting)
2
Output Evaluation and Validation
21% of the exam · 6 published objectives
21%
At 21 percent, about 13 items, this is the heaviest domain and the one that decides most borderline results. Its six objectives cover judging an output for accuracy and completeness, spotting invented detail, contradiction and slanted framing, applying practical checks, knowing when a qualified person must review, reworking a draft for its readers, and choosing a format.
The official sample item is the template: a confident summary citing a specific subsection number, bound for a compliance team, and the question of what to do before it goes out. The credible option checks the citation against the regulation itself; the distractors send it because Claude sounded sure, ask Claude to rate its own confidence, or polish the wording. Expect that pattern across finance, HR, legal and customer-facing settings, plus comparison items where you pick the draft that fits the audience, and format items decided by what happens to the output next.
Decision rules
- A specific-looking detail such as a clause number, a statistic or a named study is what to check first, because specificity is what fabrication imitates.
- The model's own confidence rating is not evidence; only the controlling source or a qualified reviewer settles a factual claim.
- Scale the checking to the consequence: spot checks for a low-stakes internal draft, line-by-line verification and named sign-off for anything regulatory, legal, financial or public.
- Fix substance before style: an option that corrects a wrong figure beats one that improves tone, even when the stem complains about tone.
- Pick the format by what happens next: inline text for a reply, an artifact for a document or code that will be edited and reused, structured data when it feeds a system.
Traps
- Fluency as proof: the option that ships the output because it reads well and Claude expressed no doubt.
- Self-verification: asking Claude to double-check or rate itself and treating that as validation.
- Any human will do: routing a specialist question to a colleague with neither the authority nor the expertise to catch the error.
- Polish first: reformatting or rewording a summary when the stem's real problem is an unverified claim.
Objectives
- Evaluate Claude-generated outputs for accuracy and completeness. Check a Claude answer against the task it was given: are the facts right, is anything missing, and does it answer the whole question? Read: Define your success criteria
- Identify hallucinations, inconsistencies, and biases in responses. Recognise the signs of invented details, statements that contradict each other and slanted framing in a response. Read: Reduce hallucinations
- Apply fact-checking and validation techniques. Use practical checks such as tracing a claim to its source, recomputing a figure or cross-referencing independent references before relying on an output. Read: Create strong empirical evaluations
- Determine when human review or additional verification is required. Decide when the stakes, the uncertainty or the policy mean a qualified person must review or approve before anything is acted on.
- Edit, adapt, refine, and compare the output generated by Claude model(s) for the intended audience. Rework a draft for the people who will read it, including choosing between two Claude outputs and tightening the one that fits.
- Organize and curate information for optimal outputs and select appropriate output formats (artifacts for code/documents, inline for conversational responses, structured formats for data). Arrange the information Claude produces so it is usable, and choose inline text, an artifact or a structured format according to how it will be consumed. Read: What are Artifacts and how do I use them?
3
Product and Model Selection
12% of the exam · 4 published objectives
12%
Domain 3 is 12 percent, about seven items, and asks whether you choose the right surface and model for a task rather than the most impressive one. Its four objectives are choosing between chat, Projects, Research and artifacts; telling Haiku, Sonnet and Opus apart by what each trades; matching that choice to the cost, speed and quality the task demands; and managing context and memory limits, including when to summarise, restart or persist.
The official sample gives the pattern: a high volume of short customer-reply drafts where speed and cost outweigh deep reasoning, and the right answer is the faster, cheaper model suited to routine work. The distractors use the most capable model for everything, switch off features to save money or abandon the platform. Other stems describe a recurring task run in fresh chats each week, a question needing current external sources, or a long thread losing earlier instructions; in each the answer is the feature built for that situation.
Decision rules
- Choose the least capable configuration that clears the stated quality bar, and reserve the most capable model for reasoning that genuinely needs it.
- Recurring work with the same instructions and files belongs in a Project; a one-off question in a chat; a document the team keeps editing in an artifact.
- When the task needs current, external, multi-source evidence, the answer is Research or supplied sources, not a bigger model.
- When a long conversation starts drifting or forgetting, summarise what matters, start fresh, and move anything permanent into Project knowledge.
Traps
- Default to the biggest: picking the most capable model for routine, high-volume work on the grounds that quality never hurts.
- Feature blindness: solving a recurring, multi-file task in fresh chats when a Project with instructions and knowledge exists for exactly that.
- Fighting the context window: pasting ever more into one thread instead of summarising, restarting or persisting.
Objectives
- Select appropriate Claude product features (e.g., projects, research mode, chat, artifacts). Pick the right surface for the job, whether a chat, a Project, Research or an artifact, based on persistence, evidence needs and the kind of output. Read: What are Projects?
- Differentiate between Claude model types (e.g., Haiku, Sonnet, Opus). Tell the model families apart by what each trades: speed and price against depth of reasoning. Read: Models overview
- Align model selection with task requirements (e.g., cost, speed, quality). Match the model to the constraints the task actually has, whether that is cost per item, turnaround time or the quality of the reasoning. Read: Choosing the right model
- Understand, manage context limitations and memory considerations and when to restart, summarize, or persist. Recognise the limits of a conversation's context and memory, and know when to summarise, start over or move material into persistent knowledge. Read: How do usage and length limits work?
4
Workflow Integration and Solution Design
16% of the exam · 4 published objectives
16%
Domain 4 carries 16 percent, about ten items, and moves from the single task to the process around it. Its objectives cover using Claude to analyse what a process or stakeholder needs, using it for research, planning and finding waste, fitting it into an existing workflow by augmenting or redesigning it, and explaining its value and limits to the people who decide. The guide also expects support for solution design and iteration, folded into the same scenarios.
A typical stem describes a team that wants Claude in a process: intake triage, report drafting, meeting follow-up, vendor research. The options differ on where Claude goes, what stays with people and what leadership is promised. The defensible option names the requirement first, places Claude on the structured, checkable part, keeps a person on any decision carrying rights, money or legal weight, and pilots against a baseline. The distractors automate end to end, bolt a chat box onto an unchanged process, or promise accuracy no model can guarantee.
Decision rules
- Start from the requirement and the cost of failure, not the feature: the right option says what the process must achieve before it says where Claude goes.
- Put Claude where the work is structured, repetitive and checkable, and keep people where the decision carries rights, money, safety or law.
- Pilot with a baseline and a metric before rolling out; an option that measures beats one that assumes.
- When a stakeholder asks what Claude will do, name both the gain and the limit, and never promise an accuracy the model cannot guarantee.
Traps
- Automate everything: the option that removes the human review step from a process whose errors stay hidden until they cause harm.
- The overpromise: telling leadership the assistant will be accurate or replace a role, when the defensible claim is a measured time saving with review kept.
- Bolt-on thinking: adding a chat box to an unchanged process and calling it integration.
Objectives
- Apply Claude to analyze requirements and use cases. Use Claude to pull apart what a process or a stakeholder actually needs and to sort candidate use cases by value and risk.
- Leverage Claude for research, planning, and process optimization. Apply Claude to gather background, build plans and find waste in a process, with sources and assumptions kept visible. Read: Use Research on Claude
- Integrate Claude into existing workflows to augment or redesign workflows. Fit Claude into a workflow that already exists, either speeding up sound steps or reshaping the flow where the tool changes what is possible.
- Communicate Claude’s value and limitations to stakeholders. Explain to decision-makers what Claude will and will not deliver for them, in terms of measured gains, remaining risks and the review that stays.
5
Configuration and Knowledge Management
12% of the exam · 3 published objectives
12%
Domain 5 is 12 percent, about seven items, and tests the durable set-up rather than the single prompt: building a Project with standing instructions and knowledge files, managing uploaded documents and connected sources such as Google Drive and Gmail, writing instructions that hold at the system level across every chat, and keeping all of it current as policies and products change.
The stems describe a Project giving inconsistent answers, a knowledge base holding three versions of the same policy, standing instructions that contradict what a user types, or a connector that reaches a mailbox the task has no business reading. The strong option curates: it removes the superseded documents, names the authoritative one, moves the rules that apply everywhere into the Project instructions and leaves task-specific detail in the prompt. It treats connector access as reach, not permission, and reviews the configuration when the underlying policy changes.
Decision rules
- One authoritative version per topic in Project knowledge; when two files disagree, the fix is curation, not a longer prompt.
- Standing Project instructions hold the rules for every chat, such as role, audience, house style and what to do when unsure; the prompt holds what applies to this task only.
- A connector grants reach, not permission; what may be read or acted on is set by policy and by the sensitivity of the data.
- Review instructions and knowledge whenever the underlying policy, product or team changes; a Project goes stale quietly.
Traps
- Everything in: uploading every document you have and expecting retrieval to work out which one is current.
- Instruction pile-up: fixing a Project by adding another rule that contradicts the last instead of removing the conflict.
- Connector as consent: assuming that because Drive or Gmail is connected, every file or message in it is fair game for any task.
Objectives
6
Governance, Risk, and Responsible Use
15% of the exam · 4 published objectives
15%
Domain 6 carries 15 percent, about nine items, and overlays every other domain: a useful result never excuses a policy breach. Its four objectives cover judging which jobs suit Claude, handling sensitive, regulated and personal data by the rules that apply, working within the organisation's AI policy and governance standards, and weighing the ethical consequences of a use, including bias, transparency and who bears the harm.
The official sample sets the tone: a spreadsheet of customer names and account numbers, a policy restricting regulated personal data, and a manager who wants trend analysis. The right move strips or anonymises the identifiers and proceeds; the distractors upload it because the analysis is internal, tell Claude not to retain it, or drop the task. That last distractor matters: the exam rewards the option that finds the compliant route, not the one that refuses. Other stems test unclear policy (ask, do not proceed), AI-drafted decisions about people (a named human owner, disclosure where required) and use cases unsuitable outright.
Decision rules
- If policy or law forbids it, no productivity gain rescues the option; but the best answer usually finds the compliant route rather than abandoning the task.
- Minimise before you upload: strip or pseudonymise regulated identifiers and share only the fields the analysis needs.
- An instruction to the model is not a control; policy is met by what you share and withhold, not by telling Claude to forget.
- Ask who is accountable: a decision touching a person's rights, employment, credit or health needs a named human owner and disclosure where policy requires it.
- Unclear policy means ask, not proceed; the approval path is part of the right answer.
Traps
- Internal so fine: sharing regulated data because the audience is inside the company.
- The magic instruction: telling Claude not to store, remember or use data as if that discharged a privacy obligation.
- The abstainer: refusing a legitimate task outright when anonymisation, minimisation or approval would have made it proper.
- Ethics as etiquette: treating bias, disclosure and accountability as tone problems rather than as reasons to change the design or stop.
Objectives
- Identify appropriate and inappropriate use cases. Judge which jobs are suitable for Claude and which are not, given the consequences of error, the data involved and who is accountable.
- Apply data, privacy sensitivity, regulatory policies, and privacy considerations. Handle sensitive, regulated and personal information according to the rules that apply to it, minimising what is shared and how.
- Follow organizational AI policies and governance standards. Work within your organisation's AI policies and governance standards, and take the approval route when the rules are unclear.
- Understand ethical implications of AI usage. Weigh the ethical consequences of a use of AI, including bias, transparency and who bears the harm when it goes wrong.
7
Troubleshooting and Optimization
10% of the exam · 3 published objectives
10%
Domain 7 is the smallest at 10 percent, about six items, but they are among the most discriminating because they punish the reflex to rewrite the prompt. Its three objectives are diagnosing why a prompt underdelivers or an output is poor and fixing the actual cause, adjusting your approach on results and feedback, and making a workflow faster and cheaper without making it less correct or controlled.
A stem gives you a symptom: a wrong figure in a monthly report, a summary that changes tone between runs, a Project answering from last year's policy, a review queue that takes too long. The tempting option rewords or reaches for a bigger model. The right option first classifies the failure and follows it to its source: a missing or outdated document, an overloaded thread, an ambiguous instruction, an underpowered model, or a duplicated process step. Optimisation items add one constraint: the speed-up may not delete a control policy requires.
Decision rules
- Classify the failure before touching anything: wrong fact, wrong conclusion from right facts, wrong form, inconsistent across cases, or too slow and costly; each points to a different cause.
- A missing or wrong fact is a source, retrieval or context problem before it is a wording problem.
- Change one variable, re-run on the same cases and keep the record; a fix you cannot reproduce is not a fix.
- Optimise the workflow, not the single call: remove duplicated context and route simple cases to the light model, but never buy speed by dropping a required review.
Traps
- Prompt-first reflex: rewording the prompt when the knowledge base holds the outdated policy that caused the error.
- Escalate the model: reaching for the most capable model to fix a problem that a missing source or an ambiguous instruction caused.
- Efficiency by amputation: speeding up a workflow by removing the verification step that made it safe.
Objectives
- Identify, diagnose, and resolve issues with underperforming prompts and/or poor outputs. Find out why a prompt is underdelivering or an output is poor, trace it to its actual cause and apply the fix that addresses that cause. Read: Increase output consistency
- Adjust approach based on feedback and results. Change your approach in response to what the results and the reviewers tell you, and keep what demonstrably worked. Read: Prompt engineering overview
- Optimize workflows for efficiency and effectiveness. Make a Claude-assisted workflow faster and cheaper without making it less correct or less controlled. Read: Usage limit best practices
Weights are the official domain weightings from the exam guide. Objective titles are Anthropic's published wording; the sentence after each is ours.
