Configuration and Knowledge Management
12% of the Claude Certified Associate – Foundations blueprint — roughly 7 of the 60 questions on a real sitting.
Configuration and Knowledge Management is 12% of the CCAO-F blueprint, roughly 7 of the 60 questions. It is the domain most directly about the product's structure, and the one where a small number of precise boundaries earn you most of the marks. Nothing here is technical — there are no settings files and no configuration syntax. The whole domain reduces to knowing where a given piece of context should live and who else will be affected by putting it there.
Three containers matter. A Project's instructions carry what is constant across all the work in that Project: the house voice, the banned superlatives, the rule about answering only from the attached policies. Its knowledge carries the documents that work draws on: the policy PDFs, the last four board packs, the terminology list. The individual request carries what changes every time: this week's product, this month's figures, today's question. Almost every question in this domain is a scenario where something has been put in the wrong container, or where someone has assumed a container reaches further than it does. Add connectors — which bring in material from systems your organisation already uses — and the shared-Project permissions that determine who can change any of it, and you have the full scope.
What the exam actually tests
- —Sorting context into Project instructions, Project knowledge, or the individual request
- —How account-level instructions and a Project's instructions coexist rather than one replacing the other
- —The reach of a Project's knowledge: chats started inside it, and nowhere else
- —Keeping knowledge current — why a superseded document left in place is worse than no document
- —What a connector does, whose permissions it uses, and what it is and is not allowed to do
- —What sharing a Project actually shares, and what stays private to each member
Instructions, knowledge, and the request
The sorting rule is duration. If something is true for every piece of work in the Project, it belongs in the instructions. If it is reference material the work is drawn from, it belongs in the knowledge. If it changes with each task, it belongs in the request. A brand tone guide and a list of banned superlatives go in the instructions; this week's product details do not, because putting them there means editing the Project every week. A forty-page style guide goes in knowledge — instructions are directions, not a library, and a document stuffed into them becomes long and weakly followed.
Instructions worth following are specific
"Be helpful and professional and write well" configures nothing. It names qualities no one would argue with and gives no way to tell a compliant answer from a non-compliant one. Useful instructions are testable: answer only from the attached policies and say so plainly when a question is not covered; use British spelling; never use the internal acronym in customer-facing text; keep replies under 200 words unless asked otherwise. The exam presents vague drafts and asks what a reviewer should say, and the answer is always to convert aspiration into a checkable constraint — the same discipline as good prompting, applied where it persists across every chat in the Project.
Two layers of instruction, both in force
Account-level instructions apply across your conversations; a Project's instructions apply to chats started inside that Project. Candidates often assume these compete and that one must win outright. In practice they coexist: a personal default — say, a direct and unhedged style — can hold generally while a particular Project's requirements shape the work done there. Where they genuinely conflict, state the narrower requirement explicitly rather than leaving it to be inferred. Keep account-level instructions to genuine personal defaults and put anything work-specific into the Project it belongs to.
Knowledge decays, and stale knowledge is confident
Six months after a shared Project is set up, answers begin citing a supplier list replaced in the spring. Nothing is broken; the old list is still in the knowledge, so it is still a legitimate source. This is the most common configuration failure in real use, and the most dangerous, because the wrong answers are traceable, consistent and delivered with the same assurance as the right ones. The fix is to remove the superseded document, not merely add the replacement alongside it — with two versions present, the answer depends on which is drawn upon. Someone must own currency.
Connectors and inherited permissions
A connector lets Claude reach a system your organisation already uses, so material that changes frequently can be read where it lives rather than uploaded as a copy that immediately starts going stale. Two properties matter for the exam. First, setting one up is an authorisation you perform, granting access under your own account. Second, a connector inherits your permissions in that system: if you cannot open a folder there, Claude cannot reach it through the connector either. So when a colleague reports Claude cannot find a folder she can see, the question is what her access actually is, not whether the connector is faulty. On Team and Enterprise plans, administrators control which connectors are available and may allow reading without allowing actions.
Where candidates go wrong
Trap 1 — 'The Project's knowledge is available in all my chats'
This is the single most consequential misconception in the domain. Uploading the expenses policy to a Project does not put it into every conversation you have; it is available to chats started inside that Project, and a chat begun outside it has no access to it. The failure is silent and therefore convincing — the outside chat answers the expenses question anyway, from general knowledge, in the same confident register, with none of the policy's specifics and no warning that it was not consulted. If grounding in a document matters, the work must happen inside the Project holding it.
Trap 2 — 'A colleague established that in the shared Project, so Claude knows it'
Two people work in the same shared Project. One establishes in her chat that the pilot has been extended to March. The next day her colleague asks a related question in his own chat and gets an answer based on the original end date. Nothing has gone wrong. Sharing a Project shares its knowledge and instructions; individual chats stay private unless deliberately shared. Facts the team needs in common must be written into the knowledge or instructions, where they persist for everyone. A conversation is not a team record, and treating it as one is how shared Projects quietly diverge.
Trap 3 — 'Upload the new version and the Project is up to date'
Adding is intuitive; removing feels destructive, particularly in a Project several colleagues rely on. But knowledge is not a chronology, and there is nothing that marks the newer supplier list as superseding the older one. With both present, either can inform an answer, and the answers drawn from the old one look exactly like the answers drawn from the new one. The related error is uploading a copy of a document that lives in a connected system and is edited regularly — the copy is correct on the day it is uploaded and wrong thereafter. If material changes often and is already reachable, read it where it lives.
Trap 4 — 'Give everyone edit access so the Project stays current'
It sounds collaborative and it is how shared knowledge becomes unmaintainable. When eight people can rewrite the instructions and replace documents, the constraints that made output consistent drift, and no one can say when or why. Shared Projects distinguish viewing from editing precisely so this is a decision rather than an accident: the two colleagues who own the reference documents and rewrite the instructions get edit access; the other six work in the Project and do not. The exam rewards matching permission to responsibility, and treats broad edit access as the answer that dissolves the standard the Project existed to enforce.
How to study this domain
Learn the three containers as a single question you can ask in seconds: does this stay the same for every task here (instructions), is this the material the work draws on (knowledge), or does this change today (the request)? Then learn the reach of each container, because that is where the marks are. Project knowledge reaches chats inside the Project. Account-level instructions reach your conversations. A shared Project shares knowledge and instructions, not chats.
The best preparation is to build one Project properly for something you do repeatedly. Write instructions specific enough that you could tell whether an answer complied with them. Upload the reference documents. Then deliberately test the boundaries: ask the same question in a chat outside the Project and see how differently it answers, and notice that nothing warns you. That single experiment fixes the domain's biggest misconception better than any amount of reading. Finally, get in the habit of asking who owns currency — a Project with no one responsible for removing superseded documents will be confidently wrong within a couple of quarters.
Common questions
Does a Project's knowledge apply to all my conversations?
No. It is available to chats started inside that Project. A conversation begun outside it cannot draw on that material and will answer from general knowledge instead, with no warning that your documents were not consulted. This is the most commonly examined misconception in the domain.
What belongs in Project instructions rather than Project knowledge?
Instructions carry standing directions: the tone to use, words to avoid, the rule to answer only from attached material. Knowledge carries the documents the work draws on. A long style guide is knowledge, not instructions — instructions are directions, and a document pasted into them makes them long and less reliably followed.
If I share a Project, can colleagues see my chats in it?
No. Sharing a Project shares its knowledge and instructions and gives access to the Project itself; individual chats stay private unless you share them deliberately. Anything the team needs to hold in common must be written into the knowledge or the instructions.
Should I upload a document or connect the system that holds it?
Upload material that is stable. Connect systems that hold material which changes often, so it is read where it lives rather than as a copy that starts going out of date the moment it is uploaded. Bear in mind a connector reaches only what your own account can already access in that system.
Do my account-level instructions stop working inside a Project?
They do not simply switch off. Account-level instructions are your personal defaults across conversations, and a Project's instructions shape the work done in it; the two coexist. Keep genuine personal preferences at the account level and put anything specific to a body of work into that Project's instructions.
Practise this domain
The CCAO-F bank is weighted to the blueprint above, so 12% of what you practise is this domain — and every option carries a written explanation, not just the correct one.
See CCAO-FOther CCAO-F domains
Not affiliated with or endorsed by Anthropic. Domain names and weightings are taken from the published exam guide; always check the official guide before booking.