Dominant Signal
The one characteristic of a task that picks its product feature: recurring shared context, multi-source cited synthesis, an iterative shareable deliverable, or a simple one-off. Real work mixes features; exam questions carry one signal each.
Exam context: Find the signal before reading the options. The wrong options are always real features applied to the wrong kind of task. So the mistake the question tests is choosing by feature prestige instead of by signal.
See also: 3.1 Selecting the Right Claude Product Feature
Ordinary Chat
The default way to work with Claude: a single conversation with material attached in the moment. It handles one-off questions, single drafts and self-contained analyses immediately, with no setup.
Exam context: A legitimate right answer, not a second-best option. When the question's dominant signal is a simple one-off, the plainest choice wins over every more capable feature.
See also: 3.1 Selecting the Right Claude Product Feature
Project (claude.ai)
A self-contained workspace with its own chat history and knowledge base. A Project has two parts that stay the same across chats: instructions that shape every chat inside the workspace, and uploaded knowledge Claude uses as background for those chats.
Exam context: The sign is recurrence: the same documents and preferences needed across many conversations. Re-pasting that context chat after chat is the manual workaround a Project exists to end. Configuring instructions and knowledge well belongs to Domain 5.
See also: 3.1 Selecting the Right Claude Product Feature
Research Mode
The feature for questions whose answer must be assembled from several outside sources. Claude searches agentically, with each search building on the last, and returns a synthesised report with citations the audience can check. Research is available only on paid Claude plans: Pro, Max, Ultra, Team and Enterprise.
Exam context: Not a quality upgrade for ordinary questions. A task answerable from material the user already holds gains nothing from it; that wrong option uses the wrong tool, and checking the citations belongs to Domain 2. One current fact from outside needs only web search in an ordinary chat.
See also: 3.1 Selecting the Right Claude Product Feature
Web Search
Claude finds current information on the web inside an ordinary chat and answers with the sources it found. It suits queries that one or two lookups can answer.
Exam context: Web search is the tool for one current fact from outside, such as the status of a published notice. Research is more than a single fact needs.
See also: 3.1 Selecting the Right Claude Product Feature
Extended Thinking
A setting that makes Claude work through a problem at more length before it answers. It does not search. On the newest models (checked 13 November 2026), thinking is always on in Claude, and the effort setting controls how much Claude thinks.
Exam context: Extended thinking is the tool for careful reasoning about material the business already has, such as its own booking or sales records. It brings in no outside facts.
See also: 3.1 Selecting the Right Claude Product Feature
Artifact
Standalone content displayed in its own window, created when an output is significant, self-contained and likely to be edited, iterated on or reused. You iterate it in one of two ways: you ask Claude to change it, or you edit an earlier message. Editing an earlier message creates a branch of the chat with artifacts of its own. A finished artifact can be shared.
Exam context: The dominant signal is a life beyond the chat, that is, continued use after the chat ends: a sheet revised every quarter, a plan shared and updated. An answer used once has no use beyond the chat, and making it an artifact is more than it needs.
See also: 3.1 Selecting the Right Claude Product Feature
Manual Workaround
The bad practice of doing a feature's job by hand: re-pasting the same standing context into every chat, or keeping a document that is revised over time as plain text that you search for in an old conversation.
Exam context: Wrong options often present it as careful work. The right answer moves recurring context into a Project and an evolving document into an artifact, doing the setup work once instead of every time.
See also: 3.1 Selecting the Right Claude Product Feature
Model Family
One of the three tiers the exam guide names: Haiku, Sonnet and Opus. The Haiku class is the fastest, lowest-cost tier; the Sonnet class is the balanced middle, the best combination of speed and intelligence; the Opus class is the most capable reasoning tier. Specific model names change over time and are on the quick reference.
Exam context: No tier is "the good one". The right answer is the tier whose strengths match the task in front of you. In the guide's own sample question, the right answer for high-volume routine drafting is the faster, lower-cost model.
See also: 3.2 Differentiating Between Claude Model Types
Capability
Depth on demanding work: resolving ambiguity and contradiction, multi-step reasoning, synthesis across partly disagreeing sources, and drafting where a subtle error has consequences. Not "better at everything".
Exam context: The documentation never claims a lighter tier matches a heavier one on demanding work, and no right answer relies on that equivalence. What justifies the lighter tier is fitness for the task plus review.
See also: 3.2 Differentiating Between Claude Model Types
Model Picker
The control in the chat interface for choosing which model responds: click the model name and pick another available model. The change applies from Claude's next response, and the picker shows what the account has access to, which varies by plan and organisation settings.
Exam context: Mid-conversation switching means the tier decision is never a one-off commitment; routine preparation and the hard synthesis step can run on different tiers inside one piece of work. A never-opened picker is a habit, not a decision.
See also: 3.2 Differentiating Between Claude Model Types
Prestige Selection
Assigning the most capable model by the project's importance rather than the task's demands. Importance belongs to projects; demands belong to tasks, and a routine reformat inside a very important project is still a routine reformat.
Exam context: The guide's sample rationale calls always-using-the-top-model a waste of the cost and latency budget. Watch for a wrong option that argues "because this work matters".
See also: 3.2 Differentiating Between Claude Model Types
Usage Allowance
What "cost" means in this certification: the plan's finite usage budget, not a per-use invoice. Model choice, effort level, current conversation length and file attachment size are among the factors that determine how quickly it is consumed.
Exam context: Treating the allowance as a budget makes cost a real currency: every task overpaid for takes allowance from the tasks still to come. Wrong options invent factors such as time of day; among the factors actually named are the model, the conversation's length and the attachments.
See also: 3.3 Aligning Model Choice with Cost, Speed and Quality
Effort
A setting in the model menu that controls how much thinking Claude applies to a response. Higher effort gives more thorough responses, but they take longer and use more of the usage allowance. Low and Medium effort work well for routine tasks.
Exam context: Current guidance (checked 29 October 2026) is to try a lower effort level before you move to an older or smaller model only to stay inside your limits. When a question asks which tier to use, answer with the tier that the task needs, not with an effort setting. For high-volume routine work, that is the faster, lower-cost tier. The exam guide's sample question does this.
See also: 3.3 Aligning Model Choice with Cost, Speed and Quality
Volume and Stakes
The two factors that decide what a task needs. Volume multiplies cost and speed: across hundreds of runs, tier differences decide whether the job finishes and the allowance lasts. Stakes multiply quality: one output that informs a consequential decision needs depth, however short it is.
Exam context: The trap in these questions uses arguments about volume in decisions about stakes: "it is only one letter" is true and irrelevant, because one letter with consequences needs more than five hundred without.
See also: 3.3 Aligning Model Choice with Cost, Speed and Quality
Split Workload
The working pattern for mixed work: routine bulk on the fast tier with a sampled spot-check, the consequential core on the capable tier with qualified human review. The picker makes the split easy mid-conversation.
Exam context: When a question mixes both kinds of work, the right answer almost always splits. The two uniform settings, maximum quality everywhere and minimum cost everywhere, are the recurring wrong options on either side of it.
See also: 3.3 Aligning Model Choice with Cost, Speed and Quality
Escalation Loop
Re-running a disappointing output on ever-heavier models without changing the prompt. A vague brief fails at every tier, so the loop spends time and usage relearning that.
Exam context: When the question shows a prompt missing audience, constraints or source material, the right answer is to fix the brief, which belongs to Domain 1; no tier upgrade substitutes for it.
See also: 3.3 Aligning Model Choice with Cost, Speed and Quality
Spot-Check
The sampled review that makes lighter-tier volume work professional rather than merely cheap: fix a sample size before looking at any output, then check the sample against the quality standard.
Exam context: Domain 2's verification duty never stops, and it is sized to the job. A right answer that sends bulk work to the fast tier almost always pairs it with a sampled check, and a failed sample means the task was less routine than its label claimed.
See also: 3.3 Aligning Model Choice with Cost, Speed and Quality
Restart
Deliberately opening a fresh conversation: when a piece of work is done, when the chat has accumulated abandoned approaches and superseded drafts, or when a long conversation approaches the platform's length and usage limits.
Exam context: The official options at the limit are practical: start a new conversation, or use a Project for larger amounts of information. Anthropic's Academy adds that the quality of Claude's answers can get worse in a very long conversation.
See also: 3.4 Managing Context Limits and Memory
Verified Summary
The handover document a long conversation produces before a restart: decisions made, current state and open questions, checked against source records before it is trusted. The verified version opens the fresh conversation.
Exam context: The summary contains every uncorrected error in the chat it summarises, so the unverified version pasted straight into a new chat is the wrong option that looks almost right. Verification is the step the right answer always includes.
See also: 3.4 Managing Context Limits and Memory
Explicit Persistence
The dependable way to give a new conversation a specific working output: paste it in, re-attach the file, or store it in Project knowledge. A standing document that keeps being revised and shared belongs in an artifact instead.
Exam context: Where an output goes depends on how long it is used: used once means paste it into the next chat, revised and shared means artifact, needed by every future chat means Project knowledge. Neither memory nor chat search substitutes for it.
See also: 3.4 Managing Context Limits and Memory
Memory Boundary
The line between what claude.ai's memory carries and what it does not. Memory holds a set of individual topics covering your role, projects, preferences and ongoing work context: context about you, not transcripts, drafts or attached documents. Each Project has its own memory. It is used alongside your memory from chats outside Projects, but never with another Project's memory. Chat search is prompted retrieval on paid plans. Rollout dates are on this domain's quick reference.
Exam context: Two stale claims fail in opposite directions: that Claude cannot remember anything across chats, and that memory can be trusted to carry a working document. The right answer depends on the boundary, never on either stale claim.
See also: 3.4 Managing Context Limits and Memory
Continuity Illusion
The marathon chat's best argument: "a new conversation would lose all our context". False, because the context worth keeping is exactly what a verified summary and persisted documents move to the new conversation, at a fraction of the length and the usage.
Exam context: The option to keep everything in one chat is the usual wrong option in 3.4 questions. A related case belongs to a different domain: diagnosing a chat already producing poor output is Domain 7, not a selection decision.
See also: 3.4 Managing Context Limits and Memory