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

Configuration and knowledge management

Weight: 12 percent of the exam (roughly 7 of 60 questions). Tests whether you can put the right instruction at the right scope, curate a knowledge base people can trust, share it safely, and connect Claude to the systems where work already lives.

What the exam expects

Almost every question in this domain reduces to one of three judgments:

1. Scope. A requirement is described. Which configuration layer matches its reach exactly, no wider and no narrower?
2. Instructions or knowledge. Is this thing a directive about behaviour, or reference material to draw on?
3. Enforcement or guidance. Is the requirement a preference Claude should follow, or an access boundary that must be enforced by a control?

Getting the third one wrong is the most costly error, because a scenario will offer an instruction as the answer to a confidentiality problem and it will read as thoughtful design. Instructions guide behaviour. They are not permission boundaries.

The configuration layers and their scope

Two precedence facts are directly testable. Organization instructions take precedence over individual instructions where the two conflict, and individual instructions continue to apply to everything the organization instructions do not address. That is the opposite of the intuition most systems train, where the narrower setting wins, so it is a favourite exam hinge.

The scoping errors the exam looks for:

• Putting a context dependent preference into account wide instructions. If someone's standing instruction says "always be conversational" and they then enable an executive briefing skill, they have built their own conflict. Account wide instructions should hold only what is true in every context.
• Escalating a team or personal preference into organization instructions. Organization instructions bind everyone, so a research team's citation habit or a marketing team's tone does not belong there.
• Expecting project instructions to cascade outward. They apply inside that Project and nowhere else.
• Assuming a preference stated inside a conversation persists. It applies to that conversation only. Making it persistent means moving it to the right layer.

Projects: instructions versus knowledge

A Project has two distinct components and conflating them causes most of the quality problems in this domain.

Project knowledge is reference material: templates, datasheets, past examples, policy documents, standard answers. It answers "what does Claude know here."

Project instructions are behavioural directives: how to format, what to always flag, what to never do without approval. They answer "how should Claude behave here."

Practical consequences the exam tests:

• Long instructions perform worse. When instructions run to pages, important rules get lost among reference detail. The fix is to tighten instructions to the small number of rules that genuinely change the output and move terminology lists, examples, and standard text into project knowledge. Repeating a rule three times is folk practice, not a fix.
• Behavioural rules buried in a knowledge document are unreliable. Directives belong in the instructions field, not appended to documents.
• Documents in project knowledge are supplied once and reused. That is both the organizational benefit and a real efficiency gain against usage limits, compared with attaching the same file to a fresh conversation every day.
• Projects do not nest. There are no sub projects. Separate bodies of work mean separate Projects.
• Free accounts get five Projects. Paid plans lift that cap and expand effective project knowledge capacity through retrieval when a project grows large.

Why answers are noticeably better inside a well maintained Project than outside it is worth stating plainly, because it appears as a question: the Project supplies curated knowledge and standing instructions that an ordinary chat simply does not have. It is not a different model tier and it is not cached answers.

Curating a knowledge base people can trust

The single most common failure is a knowledge base that accumulates rather than gets curated. When it holds three drafts of the pricing sheet, this year's playbook and last year's, and the retired policy alongside its replacement, Claude has no reliable way to know which one an organization currently treats as binding. The symptom is confident citation of superseded facts.

The fixes, in the order the exam tends to reward them:

1. Curate down to current sources of truth. Remove superseded versions when a new one lands. Archiving belongs in a document management system, not in project knowledge.
2. Name an owner and a refresh cadence. Project knowledge is a copy, not a live mirror of the source system. If templates change monthly and nobody re synchronizes, the Project silently goes stale.
3. Scope each Project to a coherent body of work so its knowledge and instructions stay relevant to the questions asked in it.

Watch for the distractor that offers a project instruction such as "prefer newer documents" or "ignore anything before this year." It reads like sound instruction design, which is exactly why it is offered, but it depends on documents carrying reliable, comparable dates, and many do not. An instruction cannot reliably compensate for contradictory source material.

Sharing Projects safely

Sharing is available on Team and Enterprise, with two permission levels:

• Can view. Read and chat with the project, including its knowledge. It restricts editing, not viewing.
• Can edit. Full modification rights over knowledge, instructions, and membership.

Projects can be shared individually, in bulk, or organization wide, and recipients find them under a "Shared with me" tab.

Two rules follow directly and both appear as questions.

Consumers get view, maintainers get edit. If twelve colleagues all have edit access, some of them will delete documents they consider redundant and rewrite the instructions, which is precisely the drift a shared Project exists to prevent. Broad edit access sounds collaborative and is the trap.

Sharing scope is set per Project, so material with different audiences belongs in different Projects. If the employee handbook should go organization wide but the draft compensation bands should not, that is two Projects. View access does not hide documents from viewers, renaming files does not hide their contents, and a project instruction not to discuss a topic is guidance rather than an access control. Only separation actually restricts who can reach the material. The same logic applies to one Project per client: it keeps retrieval focused and, more importantly, maintains a hard confidentiality boundary that no instruction can substitute for.

Connectors

Connectors let Claude reach apps and services to retrieve data and take actions. The security model is the part the exam cares about.

• Connectors operate under the authenticating user's own permissions in the source system. If a person cannot open a file there, Claude cannot open it for them. Connectors never expand access. An option claiming that connectors bypass source permissions "to enable cross tool search" is describing a serious flaw as if it were a feature.
• On Team and Enterprise, enablement is two steps. An owner enables the connector for the organization, then each member authenticates individually. This is why one colleague can be using a connector while another cannot yet.
• Admin restrictions can only narrow, never widen. Admins can allow reading while blocking send actions on an email connector, or block file creation in a storage connector. This is an enforced control, unlike an instruction telling Claude not to send mail.
• On Enterprise, admins can additionally restrict verified domain connectors to enterprise accounts.
• Availability. Web connectors are available across plans including Free. Custom connectors are capped at one on Free and unrestricted on paid plans.

Where the connection originates decides what is reachable. A custom remote MCP connector is contacted from Anthropic's cloud, not from the user's device, so the server must be reachable over the public internet or the network must allowlist Anthropic's IP ranges. A tool that runs only on a laptop, or a service behind a corporate firewall with no public endpoint, cannot be reached that way. A locally running desktop extension is the path for those cases. Connectors also retrieve on demand; they do not bulk copy a connected system into project knowledge.

How to think through the question

1. Name the requirement's reach. Everywhere for this user, inside one Project, or across the whole organization? That single reading eliminates most options immediately.
2. Decide whether it is a directive or reference material. Directives go in instructions, material goes in knowledge.
3. Ask whether it needs to be enforced or merely followed. Confidentiality, permission, and "must not be able to" language means a control: separate Projects, view versus edit, an admin connector restriction. If an option answers that with an instruction, eliminate it.
4. Eliminate options that widen scope to solve a narrow problem. Organization instructions for one person's tone, organization wide sharing to solve an editing problem.
5. Eliminate configuration answers to content problems. A contradictory knowledge base is fixed by curation, not by a model tier or a clever instruction.

Worked example. "An HR director wants to share a Project containing the employee handbook company wide, but the same Project also holds draft compensation bands not yet approved for general viewing."

Step 1: two different audiences are named, so there are two different reaches in one container. Step 2: this is about material, not directives. Step 3: "not approved for general viewing" is enforcement language, so guidance will not do. That eliminates "share it and add an instruction not to discuss compensation." Step 4: view only access is tempting because it sounds restrictive, but view access grants read access to project knowledge and restricts editing instead, so it fails the requirement. Renaming files is obscurity, not access control. Step 5: the answer is to separate the material into two Projects and share each at its own scope. The general principle: sharing scope is a property of the Project, so different audiences require different Projects.

Exam traps

• Answering a confidentiality requirement with a project instruction. It reads as thoughtful and it is the most frequently offered wrong answer in this domain. Instructions guide, controls enforce.
• Assuming the narrower instruction wins. Organization instructions take precedence over individual instructions where they conflict. Most other systems work the other way, which is why this catches people.
• Believing "can view" hides the documents. View access includes reading project knowledge. It restricts editing.
• Granting broad edit access because collaboration sounds good. It produces exactly the uncontrolled drift that separate permission levels exist to prevent.
• Fixing a bloated instructions field by adding more to it. Repetition and emphasis do not help; moving reference material into knowledge does.
• Treating project knowledge as an archive. Keeping every historical revision so Claude "can compare and infer which is current" is the direct cause of superseded citations.
• Thinking a connector grants new access. It inherits the authenticating user's existing permissions and nothing more.
• Forgetting that organization enablement is only step one. Members still authenticate individually.
• Assuming a remote connector can reach a local or firewalled service. Remote means contacted from Anthropic's cloud. Local tools need a desktop extension.
• Using account wide instructions for something context dependent. It is the usual cause of a skill appearing not to work.

Quick reference

• Precedence: organization instructions beat individual instructions on conflict; individual instructions still cover everything else.
• Scope: account wide for always true preferences, project instructions for one Project, skills for reusable voice and format, organization instructions for company policy (3,000 character maximum, Team and Enterprise, admin and above).
• A preference stated inside a conversation applies to that conversation only.
• Knowledge answers "what does Claude know here." Instructions answer "how should Claude behave here." Keep instructions short and behavioural.
• Curate: one authoritative version per fact, a named owner, a refresh cadence, and a coherent scope per Project.
• Sharing: view for consumers, edit for maintainers. Sharing scope is per Project, so different audiences mean different Projects.
• Free plan: 5 Projects, 1 custom connector. Projects do not nest.
• Connectors inherit the user's source system permissions. Admin restrictions only narrow. Org owner enables, then each member authenticates.
• Remote custom connectors are reached from Anthropic's cloud and need a publicly reachable endpoint or an IP allowlist. Local tools need a desktop extension.