Quick Reference: Domain 5 — Configuration and Knowledge Management

A Project has two configurable halves doing different work. Custom instructions shape behaviour and apply to every chat in the Project. Project knowledge supplies material that Claude uses as context in every chat. When the knowledge approaches the context window limit, Claude switches to RAG mode and searches it for the parts each question needs. Instructions answer "how should this work be done"; knowledge answers "what should it be done from".

• The container test: for every piece of a setup, ask one question: is this a rule about behaviour, or material to consult? "Write for residents who are not housing professionals" is behaviour, so it goes in the instructions. The repairs policy is material, so it goes in the knowledge.
• Why the split matters: a knowledge file can be swapped in one step when the source document is revised; a policy pasted into the instructions has to be found and cut out by hand.
• The two wrong-container failures: reference material pasted into the instructions (the behavioural rules are hidden, and stale text stays where it cannot be cleanly replaced), and the standing rule uploaded as a knowledge document (Claude uses it as context, and nothing tells Claude to apply it to every reply. In a large Project, the search may not load it at all).
• Build from your manual habit: whatever you re-explain at the start of every conversation is the instruction set; whatever you re-attach is the knowledge base. Then run a real task with a short task-only prompt and see what you no longer had to say.

On the exam: the right answer puts behaviour in the instructions and material in the knowledge; wrong options put at least one piece in the other container, usually presented as thoroughness. The question begins after the Project decision, so "use a Project" is never the right answer here; that judgement is Domain 3's.

Material reaches a Project by two routes, and the clue in almost every question is how the material changes, never how important it is.

• Governance: on Team and Enterprise plans, an Owner or Primary Owner must enable connectors for the organisation before members can use them. The correct action is a request to the workspace administrator, not improvisation.
• Permissions match the source: the connector can access only what that user can already access in the connected service, so two colleagues who ask about the same folder in their own chats can get different answers. That comes from the permission system, not a fault in Claude. The Gmail connector can send, reply to and forward email from your own account. By default, Claude asks for your approval before each of these actions (checked 1 September 2026). On Team and Enterprise plans, owners decide whether members can let these actions run without asking each time (checked 29 October 2026).
• Owner limits on actions: on Team and Enterprise plans, an Owner can limit which actions a connector can take for the whole organisation, setting each permission to Always allow, Needs approval or Blocked (for example, search and summarise email but never send). Members cannot override it. Your approval decides one action. The Owner's setting decides which actions are possible at all (checked 29 October 2026).
• Retrieval, not reading every document in full: as a project approaches its context limits, a large knowledge base is searched. Only the most relevant content is loaded. Two documented ways to influence what is retrieved: clear, descriptive file names, and naming a specific document in your prompt.
• Choosing only the needed documents is better than adding every document: every never-needed document lowers the share of relevant documents in the search and is a chance to be quoted at the wrong moment. Choose the few documents the work needs, then route each by how it changes.

On the exam: the option that adds a whole drive of documents looks thorough and is always wrong. Whether a document is permitted in the Project at all, on privacy or policy grounds, is Domain 6's question, not this one.

System-level instructions in this certification are plain-English rules that stay in effect at three documented levels. There is no technical layer underneath.

• Precedence: where levels overlap, organisation instructions take priority; individual instructions still apply to anything the organisation rules do not address.
• The placement question: who or what does this rule apply to? You everywhere: account-wide. One body of work: that Project. Everyone in the organisation: a request to the workspace Owner. Only today's job: today's prompt, which is the boundary with Domain 1.
• Behaviour, not aspiration: "keep each client email under 150 words" can be followed and failed; "be engaging" cannot. The test for every line: could a new colleague follow this and be checked against it?
• A short, prioritised set of rules works better than a long, exhaustive one: when everything is a rule, Claude cannot follow every rule equally well. Cut the lines that are not true every time, then group and prioritise the rest. Appending a rule does not fix a long set, and nor does moving the set into a knowledge file, where the rules become context rather than directions for every chat.
• Skill: a set of instructions that tells Claude how to do one kind of task, such as its steps and format. Claude loads it in any chat when a request refers to the Skill's name or description. So the steps for one kind of task do not need to be in account-wide or Project instructions. Skills now do the job of the deprecated Styles menu. Lesson 7.3 covers when to use one.

On the exam: an aspiration written as an instruction is the typical wrong option, and an ordinary member setting an organisation-wide rule personally is the typical error about levels. The right answer passes both tests; each wrong option fails exactly one.

These are product details that change. They carry a date rather than being taught as durable rules.

• RAG (retrieval-augmented generation) plan availability was contradictory in the Help Center itself. On 14 August 2026 one article said retrieval-augmented generation "is available for all Claude plans" and another said it "is only available to users with paid Claude plans". Current state (checked 30 September 2026): both now say paid plans. Plan availability still changes, so do not answer an exam question from it.
• The Styles menu is deprecated (checked 29 October 2026). Skills now do its job; the personalisation article names Skills as the way to customise how Claude formats and delivers its responses.
• The Google Drive route works only in private Projects (checked 13 November 2026). It adds a Google Doc only to the Files of a private Project and is disabled for shared Projects. A shared Project takes a Google Doc that changes as a dated upload that one named person replaces. On Team and Enterprise plans, an organisation can turn off sharing of chats that use connectors or synced content.
• Organisation instructions are limited to 3,000 characters. The limit is a maximum, not a length to aim for. A set of instructions that long has usually stopped being a set of standing rules.
• Tier gating. Connectors need an Owner or Primary Owner to enable them on Team and Enterprise plans, and organisation instructions are set by Owners and Primary Owners (checked 1 September 2026). The escalation answers in this objective depend on both facts.

Every question in this objective is the same Project: set up well once, and quietly drifted since. There are three ways a setup decays, and all three are invisible in day-to-day use. Knowledge goes out of date, because an upload is a copy from one moment and nothing tells you that the source was superseded. Instructions stay in force after the situation they describe has changed. The scope grows until the instructions fit none of the work.

• Remove, do not accumulate: when a document is superseded, remove the old version. A working Project needs exactly one answer to "which version is current"; a note file saying which governs, or an instruction telling Claude to prefer the newer document, compensates for a problem the knowledge base should not have.
• Who can change the setup: in a shared Project, a member with Can view can see the instructions and knowledge and chat, but cannot change them. A member with Can edit can change the instructions and knowledge, manage member settings and, on Enterprise plans, add project tags (beta). Give Can edit to the person who maintains the setup.
• Sweep after every swap: read the instructions for rules written for the old wording; a standing rule quoting the old notice period stays after the file it came from is gone.
• Informing is a human step, always: the only documented notification is the email when a project is first shared, and no notification of any kind is documented for later edits to knowledge or instructions. Tell collaborators what changed and when; the date lets people recognise work in progress as pre-revision.
• The habit that survives a busy calendar: a named owner, a review point tied to a real recurring event, and removal treated as an active step of the review.

On the exam: the keep-both-versions option feels thorough and careful, which is exactly why it is wrong. A question that opens with a bad output and asks what went wrong belongs to Domain 7, and even a perfectly maintained Project produces first drafts whose facts get verified under Domain 2.