CCAO-F · module 5 of 7 · 12% of the exam

Product and model selection

Weight: 12 percent of the exam (roughly 7 of 60 questions). Tests whether you can match a business need to the right Claude plan, the right model tier, the right Anthropic product, and whether you recognize the cases where Claude is not the right tool at all.

What the exam expects

This domain is about fit. You are given a workplace situation and asked to pick the smallest, cheapest, most appropriate thing that actually meets the stated requirement. Almost every question has an option that is technically capable but oversized, and an option that is cheap but fails a requirement stated explicitly in the scenario. Your job is to notice which requirement is load bearing.

Four separate selection decisions show up:

1. Which plan (Free, Pro, Max, Team, Enterprise) does this group need?
2. Which model tier (Haiku, Sonnet, Opus) fits this task?
3. Which product (Claude.ai, Claude Code, the API) fits this workflow?
4. Should Claude be used here at all?

You are not expected to recite pricing to the dollar. You are expected to know which capability lives at which tier, because that is what makes a requirement decisive.

Choosing a plan

Plans divide along two axes that the exam keeps separate: capacity (how much you can use Claude) and governance and collaboration (what an organization can control and share). Confusing these two is the most common wrong turn in this domain.

The decisive tests:

• Capacity problem for one person points to Pro or Max. It never points to Team, which is a collaboration plan whose standard seat allowance is only modestly above Pro.
• Sharing and central administration points to Team.
• SCIM, audit logs, retention configuration, or more than 150 seats points to Enterprise. Team offers single sign on and just in time provisioning, but not automated deprovisioning through SCIM, not audit log export, and not custom retention. If a scenario names any of those three, Team fails.

Within Team, seat types matter. Mixing a few premium seats for heavy users with standard seats for occasional users is the intended pattern, and "give everyone the premium seat so nobody is ever blocked" is a distractor that fails the cost test.

When someone hits a limit mid cycle, the supported moves are: upgrade the seat or plan, purchase usage credits, or shift routine work to a lighter tier while waiting for the reset. Team limits apply per member, so there is no shared organization pool an admin can enlarge.

Choosing a model tier

Three tiers, ordered by capability and by cost against your allowance.

Read the scenario for the signals that move you off the default:

• Move down to Haiku when you see high volume, repetitive, consistently formatted, speed sensitive, or simple and well specified.
• Move up to Opus when you see complex, multi step, high stakes, long documents, conflicting sources, or an explicit statement that accuracy matters more than turnaround.
• Stay at Sonnet when the scenario gives no strong signal in either direction.

Two facts about tier selection that questions like to test. First, the model is a per conversation choice a user can change at any point, including partway through a conversation when the work gets harder; nothing is lost by switching. Second, an organization default set by an administrator is a starting point, not a lock. Users may still select a heavier tier for a task that needs it. The correct answer to "the default is too light for our hardest work" is almost never "raise the default for everyone" and almost never "remove the default entirely."

The habit the exam most wants you to resist is defaulting to the heaviest tier "to be safe." It is not safer. It draws down the session and weekly allowances faster, adds latency, and delivers no measurable gain on a five way classification or an email rewrite. The capacity you burn on trivial work is capacity unavailable for the analysis that genuinely needed the depth.

Choosing a product

The dividing questions are: who is driving the interaction, does it need to run unattended, and does it need to touch a codebase or another system programmatically. A recurring weekly report that a person assembles is a Claude.ai Projects problem, not an API problem, and reaching for an integration there is premature engineering. An assistant embedded in a product used by customers who will never have Claude accounts is an API problem, and no amount of Project sharing substitutes for it.

Note that the API is not simply "cheaper Claude.ai." It is billed differently for a different purpose and carries real build and maintenance cost that a seat does not.

When Claude is the wrong tool

Two disqualifiers, and they are about the nature of the task rather than about configuration. No plan upgrade or tier change removes either one.

Determinism already available elsewhere. If the output must be exact and auditable, and a formula, query, or system of record already produces it, that existing mechanism is the right tool. Totalling 40,000 spreadsheet rows to the cent, or fetching today's closing share price, belongs to the spreadsheet and the market data system. Claude's value on those tasks is interpreting, explaining, and flagging anomalies in a number sourced elsewhere, not being the source.

Accountability that must rest with a person. If a decision carries legal, clinical, or employment consequence for an individual, an authorized human must make it. Telling a patient to stop a prescribed medication, or auto rejecting 200 job applicants with no human review, fails on accountability regardless of how good the output is. Watch for options offering a disclaimer, a documented prompt, or a compliance configuration as if any of those were a substitute for a human decision maker. They are records and mitigations, not accountability.

Note what does not disqualify: a human reviewing Claude's draft, Claude comparing proposals before a person decides, or Claude summarizing a long document. Those are all good fits. The line is drawn at Claude being the exact source of record, or Claude being the accountable decider.

How to think through the question

A repeatable procedure for this domain:

1. Find the binding constraint. Scan the scenario for the concrete requirement: a seat count, a named security control, a volume figure, a speed requirement, a statement that accuracy outweighs turnaround, a mention of customers without accounts. There is usually exactly one, and it decides the question.
2. Identify which of the four selections is being asked. Plan, tier, product, or suitability. Options often mix categories deliberately, offering a plan upgrade as the answer to a tier question or a tier upgrade as the answer to a governance question.
3. Eliminate options that ignore the binding constraint. If security named SCIM, every option that stops at Team is out no matter how well it reads.
4. Eliminate the over engineered option. Multi agent frameworks, custom API builds, and second organizations are almost never right in an associate level scenario when a Project or a seat type would do.
5. Eliminate the "buy your way out" option when the scenario shows untried free improvements.
6. Pick the smallest thing that satisfies the constraint.

Worked example. "A 12 person consultancy on individual Pro subscriptions wants one invoice, shared client briefs everyone works from, and control over who can change those briefs. Two partners work with Claude all day; the rest use it a few times a week."

Step 1, the binding constraints: one invoice, shared knowledge, permission control, and uneven usage. Step 2, this is a plan question with a seat allocation component. Step 3, individual Pro plans cannot deliver centralized billing or shared Projects, so any option keeping them is out. Nothing here names SCIM, audit logs, or retention, and 12 is well under 150, so Enterprise is not required. Step 4, eliminate proposals to build anything custom. Step 5, eliminate "give all 12 premium seats," which overspends on ten people who do not need it. Step 6, the answer is Team, with premium seats for the two heavy partners and standard seats for the other ten. Notice that the uneven usage detail was not decoration; it existed to test whether you know seat types can be mixed.

Exam traps

• Treating the most capable tier as the safe default. It is tempting because "more capable" sounds like risk reduction. It is actually a cost and capacity decision, and burning the allowance on routine work starves the hard work later.
• Answering a governance question with a capacity plan. Max is the highest individual tier, so it feels like the strongest option. It has no admin controls, no shared Projects, and no organization membership at all.
• Reaching for Enterprise whenever a scenario sounds corporate. Collaboration, sharing, single sign on, and central billing all stop at Team. Only identity lifecycle automation, audit evidence, retention configuration, and scale past 150 seats cross the line.
• Reading an organization default model as a restriction. It sounds like policy, so overriding it sounds like a violation. It is a starting point users can change per conversation.
• Recommending an API build for a manual recurring task. Automation language in the scenario pulls you toward engineering, but a weekly human driven report is a Projects problem.
• Treating a disclaimer, a logged prompt, or a plan upgrade as a fix for an accountability problem. Each sounds responsible. None of them changes who is answerable for the decision.
• Assuming a heavier model tier fixes recency or exactness. Tier affects reasoning depth. It does not make training data current and does not turn a probabilistic system into an auditable calculator.
• Forgetting that Team has a floor and a ceiling. Minimum 2 members, maximum 150 seats. Both bounds have appeared as the hinge of a question.

Quick reference

• Capacity for one person: Pro, then Max (5x, 20x).
• Collaboration and central admin: Team. Minimum 2 members, maximum 150 seats. Standard and premium seat types can be mixed.
• SCIM, audit logs, Compliance API, custom retention, more than 150 seats: Enterprise.
• Free: 5 Projects, 1 custom connector, limited usage. Paid plans lift both and expand project knowledge capacity through retrieval.
• Out of capacity mid cycle: upgrade the seat or plan, buy usage credits, or shift routine work to a lighter tier. Team limits are per member.
• Haiku for high volume and simple. Sonnet by default. Opus for complex, high stakes, long document reasoning.
• Model choice is per conversation and changeable mid conversation. Org defaults are a starting point, not a lock.
• Claude.ai for people doing knowledge work. Claude Code for codebases. API for software and unattended workflows.
• Claude is the wrong tool when an exact answer already comes from a deterministic system, or when the decision itself must belong to an authorized human.