What this domain tests
12% of CCAO-F — roughly 7 of 60 scored items. The blueprint lists four task objectives:
- Select appropriate Claude product features (Projects, research mode, chat, artifacts)
- Differentiate between Claude model types (Haiku, Sonnet, Opus)
- Align model selection with task requirements (cost, speed, quality)
- Manage context limitations and memory (when to restart, summarize, or persist)
Character: this is a judgment domain, not a spec-sheet domain. First-hand reports describe the Associate exam as scenario-based with "less clear-cut answers" than the technical certs — you won't be asked to recite token counts or prices, you'll be handed a workplace scenario and asked which product, feature, or model tier shows the best judgment. The official sample question for this domain (high-volume short replies → "use a faster, lower-cost model") is the template: a task profile, four options, and one answer that matches capability to requirement. Learn the matching logic, not the numbers.
Theory outline
The Claude model family: Haiku, Sonnet, Opus
Every Claude generation ships the same three-tier shape, named by poem length — smallest to largest:
| Tier | Profile | Sweet spot |
|---|---|---|
| Haiku | Fastest responses, lowest cost | High-volume, well-defined, bounded tasks: classification, extraction, routing, templated generation |
| Sonnet | Balanced intelligence, speed, and cost | The everyday default: drafting, analysis, summarization, moderately complex recurring work |
| Opus | Deepest reasoning, highest cost, slowest | Complex, ambiguous, multi-step, high-stakes work: cross-document synthesis, subtle judgment, agentic tasks |
What actually differs across tiers is how much the model can figure out on its own. All three follow instructions; the gap shows on ambiguity, nuance, multi-step reasoning, and long-horizon coherence. On a bounded task with clear criteria, Haiku performs near the frontier at a fraction of the cost and latency — which is exactly why "just use the biggest model" is a distractor, not an answer.
Two stable facts the exam leans on:
- Model names and versions change over time; the tier logic doesn't. Questions test the logic.
- The tiers share the same interface and product surface — picking a tier is a per-task decision, not an account-level identity.
Aligning model to task: the three-question procedure
The blueprint names the three trade-off axes explicitly: cost, speed, quality. A prepared candidate runs the same procedure on every scenario:
- Is the task bounded or open-ended? Fixed categories, a template, a clear extraction schema → bounded → light model. Judgment calls, synthesis, ambiguity → open-ended → stronger model.
- What does an error cost? A mis-routed ticket gets caught downstream; a wrong recommendation to a board moves money. Stakes buy reasoning depth.
- What's the volume? At thousands of runs per day, per-task cost and latency dominate; at one deliverable per week, they're rounding errors.
Then pick the cheapest tier that clears the quality bar — never the most powerful available, never the cheapest regardless.
| Scenario profile | Right call | Why |
|---|---|---|
| Route 2,000 inbound emails/day to 5 departments | Haiku | Bounded classification at volume |
| Weekly competitive digest with analyst-quality commentary | Sonnet | Moderate complexity, recurring — Opus overkill, Haiku misses nuance |
| Merger-risk memo synthesizing 9 diligence documents | Opus | Cross-document reasoning, high stakes |
| Extract invoice fields; flag anything unusual for deeper review | Haiku first pass → escalate flags | Tiered routing (below) |
Two hybrid patterns recur in correct answers:
- Design-then-execute. Use a strong model to design and pressure-test the template or rubric; run the volume on a light model. The intelligence lives in the template, not in each execution.
- Triage-then-escalate. A light model handles the routine majority and flags the ambiguous minority to a stronger model (or a human). You pay frontier prices only for frontier problems.
Anti-patterns (each shows up as a distractor): "always use the most capable model" (burns cost and latency budget on mechanical work); "always use the cheapest" (starves complex work of reasoning); "switch models to fix bad output" when the prompt is underspecified (a prompt problem has a prompt solution); "run the cheap model three times and merge" (consistency isn't capability).
Product features: chat, Projects, Artifacts, research mode
The blueprint's first objective is picking the right feature for the job. Four surfaces, four profiles:
| Feature | What it is | Pick it when |
|---|---|---|
| Chat | The default conversational surface | One-off tasks, quick questions, exploratory iteration |
| Projects | A workspace holding standing knowledge files + custom instructions that every chat inside it starts with | Recurring work sharing the same background — a client, a product, a team function. One Project per confidential context |
| Artifacts | Substantial outputs (documents, pages, diagrams, mini-apps) rendered in a dedicated pane, versioned through iterations, shareable | The output is a standalone deliverable you'll iterate on or hand to someone — not just a long answer |
| Research mode | Agentic, multi-step web research: Claude searches, reads sources across the web (and connected work tools), and returns a comprehensive cited report | You need current, sourced depth — a landscape scan, a diligence brief — where checkable citations matter |
Boundary cases the exam probes:
- Research vs plain web search. A quick current fact ("what did the company announce yesterday?") needs one search inside a normal chat. Research mode is for breadth-and-depth questions worth minutes of agentic digging and a cited report. Choosing Research for a one-fact lookup is the "overkill" distractor; answering a fast-moving landscape question from training knowledge is the "stale" distractor.
- Artifact vs long chat reply. Length alone doesn't make something an Artifact. The trigger is deliverable-ness: will it be edited, versioned, or shared as a thing?
- Project vs re-pasting context. If you've pasted the same background twice, it belongs in Project knowledge or instructions. Chat history is not a storage layer.
Products and plans: apps, API, and organizational fit
claude.ai apps (web, desktop, mobile) are the ready-made surface for individuals and teams: chat, Projects, Artifacts, Research, connectors. The Claude API is how developers build Claude into their own software. Same model family, different consumption. The Associate-level skill is routing: "we want a custom Claude-powered widget on our website" is API territory — hand it to developers — while "our analysts need AI for document work" is an apps-and-plans conversation.
Plan ladder as docs describe it: Free → Pro → Max for individuals (ascending usage limits and feature access), Team for organizations wanting shared billing and collaboration, Enterprise adding admin and security controls (SSO, domain capture, audit-oriented controls, enterprise data terms). Choosing between them hinges on exactly two fits:
- Governance fit — admin controls, security posture, data-handling terms (retention, training use).
- Usage fit — what work, which features, what volume, how many people.
Competitor choices, executive preference, and cosmetic factors are permanent distractor material.
Context limitations and memory: restart, summarize, or persist
The context window is Claude's working memory: everything it can consider at once — instructions, uploaded documents, conversation history. It is not the knowledge cutoff (training recency); conflating the two is a classic distractor pair. Two practical failure modes:
- Long chats degrade. As a conversation grows, early details get crowded out; Claude "forgets" decisions made weeks ago in the same thread.
- Context stuffing dilutes. Forty loosely relevant documents compete for attention with the one that matters. "Upload everything" is not a strategy.
The blueprint names the three responses. Know when each applies:
| Move | When | How |
|---|---|---|
| Restart | Topic change; quality degraded; iteration has accumulated contradictory steering | Fresh chat. Nothing worth carrying? Just start clean |
| Summarize (then restart) | Continuity matters — decisions, constraints, open items must survive the reset | Ask Claude to distill key decisions and open threads; seed the fresh chat with that summary |
| Persist | The same context will be needed across many future chats | Standing knowledge and instructions → a Project. Durable personal preferences (role, format tastes) → memory, where available |
Memory hygiene: memory is for stable working preferences that improve every future session — not one-off task details (noise), and never secrets or credentials. Scoped, sensitive company context belongs in a Project, not global memory.
One more trap: a bigger model does not fix a context problem. If the conversation outgrew working memory, escalating from Sonnet to Opus changes nothing — the fix is summarize/restart/persist.
Worked problems
Problem 1 — Feature selection. A consultant must brief a client Monday on how data-privacy enforcement across three jurisdictions has shifted in the last six months. She needs a thorough, current overview her client can check source by source. Options: (A) ask in a regular chat, relying on Claude's training knowledge; (B) use research mode to produce a cited, multi-source report; (C) create a Project and upload last year's regulatory PDFs; (D) request the answer as an Artifact for polish.
Approach: Classify the need: current (six months — likely post-cutoff), comprehensive (three jurisdictions, a landscape not a fact), verifiable (client will scrutinize). That triple — current + deep + cited — is research mode's exact profile.
Why the others fail: (A) training knowledge is frozen at a cutoff; recent enforcement shifts may be missing entirely, and nothing is citable. (C) a Project persists context; last year's PDFs are precisely the stale material the question outgrew. (D) Artifacts control output presentation, not information freshness — polishing an unsourced answer doesn't source it.
Answer: B
Problem 2 — Model tier with volume and mixed complexity. An insurer processes 10,000 claims forms daily. Ninety-five percent are routine field extraction; a few percent show inconsistencies suggesting fraud and need careful reading. Options: (A) run Opus on everything for maximum accuracy; (B) run Haiku on everything to control cost; (C) run Haiku for extraction with a rule that flags inconsistent forms for escalation to a stronger model and human review; (D) hire more staff and skip AI.
Approach: Volume screams light model; the fraud tail screams reasoning depth. When a workload is bimodal, the answer is almost never one tier — it's triage-then-escalate: pay Haiku prices for the 95%, frontier prices (plus a human gate, since fraud decisions are high-stakes) only for the flagged tail.
Why the others fail: (A) pays Opus cost and latency on 9,500 mechanical extractions a day — the canonical over-provisioning distractor. (B) sends the fraud-suspect minority through a model chosen for speed, exactly where errors are silent and costly. (D) abandons the automatable 95% because of the hard 5%.
Answer: C
Problem 3 — Context management with continuity. A product manager has run one planning chat for five weeks. Claude now contradicts decisions made in week one, and responses feel less sharp. The launch is in three weeks and the accumulated decisions matter. Options: (A) keep going — restarting would lose everything; (B) start a blank new chat and rebuild from memory; (C) have Claude summarize decisions, constraints, and open items; start a fresh chat seeded with the summary; and move standing documents into a Project; (D) switch the chat to the most capable model so it can remember more.
Approach: Diagnose first: the chat outgrew working memory — early content is being crowded out. Continuity matters (three weeks to launch), so pure restart wastes state and pure persistence-in-place is impossible. The move is summarize-then-restart, plus persist the standing material to a Project so the next five weeks don't recreate the problem.
Why the others fail: (A) mistakes the chat for the memory — quality keeps degrading. (B) restart without summarize throws away five weeks of decisions when a two-minute distillation would have kept them. (D) is the trap the domain loves: model tier and context health are different axes; escalating the model doesn't restore crowded-out history.
Answer: C
Problem 4 — Product routing. A retail company wants a Claude-powered assistant embedded in its own customer-facing order-tracking page, matching its brand and connected to its order database. The ops lead asks which claude.ai plan to buy. Options: (A) Enterprise plan — it has the most features; (B) Max plan for the ops team; (C) this is an API build — route it to the engineering team to build with the Claude API; (D) a Team plan with a shared Project containing the order data.
Approach: First question: who is the user, and whose interface? Customers, on the company's own page, wired to internal systems. That's software the company ships, not a workspace employees log into — API territory, regardless of which plan the ops team also buys for internal use.
Why the others fail: (A) and (B) buy seats in Anthropic's interface; no claude.ai plan embeds a branded assistant in your own product. (D) additionally proposes putting a live order database into Project knowledge — wrong surface and a data-governance smell.
Answer: C
Exam traps
- Context window vs knowledge cutoff. Working memory vs training recency. Any option that fixes staleness with a bigger window — or fixes a crowded chat with a newer model — is wrong.
- "Most capable = best choice." The exam rewards the cheapest tier that clears the quality bar. Watch for "to maximize quality" attached to a mechanical high-volume task.
- "Cheapest = best choice," symmetrically. High-stakes synthesis on a speed-tier model is the mirror-image error.
- Model-switching as a prompt fix. If the scenario shows a vague prompt, the answer lives in the prompting domain — not in escalating tiers.
- Research mode as the answer to everything current. One fresh fact = web search in chat. Research earns its cost on cited, multi-source depth.
- Artifacts chosen because output is long. The trigger is standalone-deliverable, not word count.
- "Upload everything to the Project." More context is not better context; dilution is real.
- Restart vs summarize confusion. Restarting when continuity mattered (state lost) and grinding on when a restart was due (quality sinks) are both punished. Match the move to whether accumulated state is worth carrying.
- Plan selection by vibes. Only governance fit and usage fit are ever load-bearing; competitor choice and executive preference are decoration.