What this domain tests
12% of the CCAO-F — roughly 7 of 60 scored items. The question underneath every item: can you set Claude up so that good output is the default, not a per-chat achievement? That means configuring Projects, sorting content between instructions and knowledge files, choosing between uploads and connectors, and — the part teams skip — keeping all of it current.
First-hand reports describe the Associate exam as non-technical and judgment-heavy, with "less clear-cut answers than the technical exams." For this domain that translates to placement questions: several plausible homes for a piece of information, one best one. You won't be asked to recite a menu path. You'll be asked where a team-wide citation rule should live, or why a Project started quoting April's numbers in July. Learn the layers and the hygiene discipline and these are fast points.
Theory outline
The Project: instructions + knowledge, and the sorting rule
A Claude Project is a persistent workspace that packages two things every chat inside it inherits:
- Custom instructions — behavioral guidance: who Claude is acting as, who the audience is, tone, output conventions, sourcing rules, what to do when a request is out of scope.
- Project knowledge — uploaded reference material: policies, price lists, product specs, style guides, past examples.
The exam's favorite move in this domain is making you sort content between the two. The rule:
Instructions shape behavior. Knowledge documents carry content.
A rate card belongs in a knowledge file, where it can be replaced independently when prices change. "Lead with the number, cite the source document by name, escalate anything off the rate card to the pricing desk" belongs in instructions. Mix them — paste the rate card into instructions, or bury behavioral rules inside a 30-page uploaded doc — and both become unmaintainable. Every price change now means rewriting instructions; every tone tweak means re-uploading a document.
One capacity fact worth knowing conceptually: project knowledge is not unlimited attention. Small knowledge bases fit in Claude's working context in full; on current paid plans, once knowledge grows past what fits, Claude retrieves relevant portions rather than reading everything. Either way, the practical consequence is identical — curation determines answer quality, because irrelevant and duplicate files either dilute attention or pollute retrieval.
The six configuration layers
Everything you can configure lives at one of six layers. Placement questions are the core of this domain, so learn the table cold:
| Layer | Scope | Best for | Never for |
|---|---|---|---|
| Org/workspace settings (admin) | Everyone in the organization | Who has access, which connectors are approved, data retention behavior | Task guidance or content |
| Project custom instructions | Every chat in one Project | Role, audience, tone, format conventions, sourcing rules, out-of-scope behavior | Reference content that changes on its own schedule |
| Project knowledge | Every chat in one Project | Reference documents: policies, specs, price lists, exemplar outputs | Behavioral rules; secrets/credentials |
| Styles | Your account, across chats | Delivery preferences: concise, formal, explanatory, custom voice | Facts, task context, team standards |
| Memory | Your account (where available; can be project-scoped) | Durable personal working preferences — your role, recurring formats | Secrets, one-off task details, anything the whole team must follow |
| Chat message | One conversation | The task at hand: today's brief, this document, this question | Anything you find yourself retyping weekly |
Two placement rules the exam rewards:
- Shared vs personal. A rule the whole team must follow ("always cite the source document by name") goes in Project instructions, because everyone working in the Project inherits it. Putting it in your personal style or memory configures only you — teammates' outputs stay inconsistent. The reverse error also appears: a personal preference ("I like tables first") does not belong in shared Project instructions, where it imposes one person's taste on the team.
- Stable vs per-task. If it applies to every conversation, push it up into configuration. If it applies once, keep it in the message. The symptom of getting this wrong is the "restate-it tax": re-explaining the same background every chat — the exam's cue that a Project (or memory) is missing.
Uploads vs connectors: static snapshot vs live source
Project knowledge can be populated two ways, and the difference is the single most-tested mechanism in this domain:
- Uploaded files are point-in-time copies. Upload a spreadsheet in April and Claude will faithfully cite April's numbers in July, no matter how many times the original changed in Google Drive. Claude has no way to know a snapshot is stale.
- Connectors reach the live source. Claude's connectors — Google Drive, Gmail, Google Calendar, and others from the connectors directory — let Claude search and read current content on demand, so answers track the source of truth. On Team/Enterprise plans, admins control which connectors are available to the organization.
Choosing between them:
| Situation | Right choice | Why |
|---|---|---|
| Stable reference (brand guide, signed contract, published policy) | Upload to project knowledge | Changes rarely; a snapshot is fine and always available |
| Living document (pipeline tracker, weekly metrics, roadmap) | Connector to the source (e.g., Google Drive) | Avoids the stale-copy failure; one source of truth |
| Email or calendar context | Gmail / Google Calendar connector | Content is inherently live and personal; search on demand |
| Sensitive or regulated data | Check org policy and connector approval FIRST | Connectors inherit your account's access; approval and data-handling rules are the gate |
Two subtleties worth a second read:
- Connectors respect existing permissions. Claude searching your Drive sees what your account can see — a connector is a window into your access, not an elevation of it. But that cuts both ways: broad personal access means broad exposure surface, which is why connector approval is an admin-level, governance-relevant decision.
- A connector doesn't replace curation. If your Drive contains six drafts of the proposal, a connector-backed search can surface the wrong one. Source hygiene — clear names, archived drafts, one canonical final — matters just as much for connected sources as for uploads.
Writing effective system-level instructions
The exam contrasts weak and strong instruction sets. Weak instructions state virtues; strong instructions make decisions for the model. Four components show up in every strong set:
- Role and audience — "You support the HR team answering employee policy questions. Audience: employees with no legal background."
- Format and length conventions — "Answer in 3 sentences or fewer; bold the policy name."
- Sourcing rule — "Cite the specific knowledge document by name. If the answer isn't in the uploaded policies, say so — do not answer from general knowledge."
- Out-of-scope behavior — "For legal interpretation, respond: 'escalate to Employee Relations.'"
"Be helpful, accurate, and professional" fails because it decides nothing — the model was already trying to be all three. The sourcing rule (#3) deserves special attention: instructing Claude to ground answers in project knowledge and say when the knowledge doesn't cover the question is the configuration-level defense against confident answers from general training knowledge, and it links this domain to Output Evaluation.
Maintenance: the update lifecycle
The blueprint's fourth objective — "inform, maintain, and update" — is where real deployments fail. The failure modes and their fixes:
| Symptom | Root cause | Fix |
|---|---|---|
| Answers got vaguer as files were added | Dilution — dozens of loosely relevant files competing for attention/retrieval | Prune to what the work needs; descriptive file names |
| Answers are inconsistent, sometimes citing old policy | Contradiction — multiple versions of the same document coexist | One canonical version; remove superseded files when uploading replacements |
| Claude quotes last quarter's numbers | Stale snapshot — uploaded copy never synced | Replace the file, or move that source to a connector |
| Policy changed but Project behavior didn't | The change was announced in a chat, not made in configuration | Chats don't update Projects; edit the knowledge/instructions themselves |
| Nobody knows if the knowledge base is current | No ownership | Named owner + review cadence (e.g., monthly), because Claude cannot flag its own staleness |
The correct update procedure is a two-step the exam likes: (1) replace — remove the superseded file and upload the current version (don't stack versions); (2) verify — run a test question whose answer changed and confirm the Project now answers per the new material. Configuration changes without verification is the maintenance equivalent of shipping code without running it.
A note on the "tell Claude in chat" trap: saying "by the way, the refund window is now 30 days" mid-conversation fixes that conversation only. Project configuration is the durable layer; the chat is ephemeral. Any option that patches a configuration problem inside a single chat is treating a persistent problem with a disposable fix.
Organization-level configuration
For admins, the levers that matter are the governance surface, not cosmetics:
- Access — who in the org can use Claude, managed via workspace membership (SSO/provisioning on Enterprise).
- Connectors and integrations — which are approved for the org; this is where data-exposure policy becomes enforceable.
- Data handling — retention behavior and how organizational data is used, per plan terms.
When an exam option list mixes "approved connectors and retention settings" with sidebar order and chat wallpaper, the governance-surface option wins. This is also the bridge to Domain 6: org configuration is where written policy becomes enforced policy.
Worked problems
Problem 1 — Sorting a new Project
A proposal team is setting up a Project. They have: (i) brand-voice rules ("confident, plain English, no jargon; every claim tied to a case study"), (ii) a 30-page services catalog updated quarterly, (iii) this week's client brief. Where does each belong?
A. All three in custom instructions, so nothing is ever missed B. (i) in custom instructions; (ii) in project knowledge; (iii) pasted into the chat for this week's work C. (i) in memory; (ii) in custom instructions; (iii) in project knowledge D. All three uploaded as knowledge documents
Approach: Run each item through the sorting rule. Brand-voice rules are behavioral guidance that applies to every chat — instructions. The catalog is reference content on its own update schedule — knowledge, replaceable each quarter without touching behavior. The client brief is per-task and this-week-only — it belongs in the message, not in durable configuration.
Why the others fail: A entombs a 30-page quarterly document inside instructions, forcing an instructions rewrite every quarter and bloating every chat. C puts team-wide voice rules in one person's memory (teammates never inherit them) and behavioral content in the wrong layers throughout. D uploads the voice rules as a document Claude may treat as reference rather than binding behavior, and freezes a weekly brief into durable knowledge where it will be stale in seven days.
Answer: B
Problem 2 — The daily-changing source
A sales ops lead wants Claude to answer questions from the pipeline tracker, a Google Sheet edited by reps every day. What is the best setup in claude.ai?
A. Upload the sheet to project knowledge and re-upload whenever someone remembers B. Paste the current pipeline into the Project's custom instructions C. Use the Google Drive connector so Claude reads the live sheet when asked D. Ask Claude to remember the pipeline via memory
Approach: Classify the source: living document, high change frequency, one source of truth already exists in Drive. That profile is exactly what connectors exist for — search/read the current version on demand, no stale copies, no re-upload chore that depends on human memory.
Why the others fail: A institutionalizes the stale-snapshot failure; "whenever someone remembers" is the rot mechanism, not a cadence. B is the worst of both worlds — content in the behavior layer, frozen at paste time, rewritten daily by hand. D misuses memory, which holds durable personal preferences, not a dataset that changes daily and belongs to the team.
Answer: C
Problem 3 — Which instruction rewrite?
An internal HR-policy Project produces answers that are sometimes legalistic, sometimes chatty, and occasionally speculate beyond the uploaded policies. Which custom-instructions rewrite best fixes all three symptoms?
A. "Be consistent, professional, and accurate. Do not make things up." B. "You answer employee policy questions for staff with no legal background. Max 4 sentences, plain English. Cite the policy document by name. If the uploaded policies don't cover the question, say so and direct the employee to HR — never answer from general knowledge." C. "You are the world's leading employment-law expert. Give thorough, authoritative answers." D. "Follow the uploaded documents."
Approach: Map symptoms to missing decisions. Inconsistent register → no audience/format decision. Speculation → no sourcing rule and no out-of-scope behavior. Option B supplies all four components of strong instructions: role+audience, format, sourcing rule, and an explicit escape hatch when knowledge doesn't cover the question.
Why the others fail: A restates virtues without deciding anything — "do not make things up" doesn't tell the model what to do when it doesn't know. C makes the speculation problem worse: an authoritative-expert role invites confident answers beyond the documents, and "thorough" fights the audience's needs. D gestures at grounding but decides nothing about audience, format, or what to do at the knowledge boundary — the exact edge where the failures occur.
Answer: B
Problem 4 — The 60-file Project
A two-year-old Project has 60 knowledge files, including three versions of the employee handbook (2024, 2025, 2026) with different remote-work rules. Claude's answers about remote work vary between chats. What is the highest-leverage fix?
A. Upload a note titled "IGNORE the 2024 and 2025 handbooks" B. Tell Claude at the start of each chat which handbook to use C. Prune the knowledge base: keep only the 2026 handbook and the files current work needs, with descriptive names D. Split into 60 separate Projects, one per file
Approach: Diagnose which rot this is. Not just dilution — contradiction: three authoritative-looking documents disagree, so which one informs any given answer is a coin flip. Contradiction is fixed at the source: one canonical version, superseded files removed. Pruning the rest of the 60 treats the accompanying dilution too.
Why the others fail: A adds a 61st file and hopes an instruction-shaped document out-shouts two full handbooks — meta-files about other files are a patch, not a fix, and future maintainers won't know why it's there. B is the disposable-fix trap: per-chat patching of a configuration-layer problem, and it depends on every user remembering. D destroys the point of a Project (shared standing context) and multiplies the maintenance surface by 60.
Answer: C
Exam traps
- Personal layer for team rules. Any option that puts a team-wide standard into one person's style or memory is wrong — the team never inherits it. Shared rule → shared layer (Project instructions).
- "Tell Claude in the chat" as a configuration fix. Chats are ephemeral; Projects are durable. Patching stale knowledge or missing rules inside one conversation fixes nothing for the next chat or the next person.
- Stacking versions instead of replacing. Uploading "handbook-v2" next to "handbook" feels safe but creates contradiction — the more dangerous rot. Remove superseded files.
- Expecting uploads to sync. Uploaded knowledge is a snapshot. "Claude should have noticed the Drive file changed" is never true for an uploaded copy — that's what connectors are for.
- Update without verify. Options that end at "upload the new file" lose to options that also confirm with a test question. Maintenance = change + verification.
- Content in the behavior layer. Price lists, catalogs, datasets pasted into custom instructions. Both halves become unmaintainable; the exam expects you to flag it.
- "Upload everything automatically." Accumulation is not knowledge management. Curation — fewer, current, well-named, owned — is.
- Trusting Claude to police freshness. Models cannot detect that their provided context is stale. Owner + review cadence is the only real answer to "how do we keep it current?"
- Cosmetic org settings. Wallpaper, sidebar order, shortcuts — governance distractors. Real org levers: access, approved connectors, data retention.