Domains
D5 · Configuration and Knowledge Management
Configuring Projects and custom instructions, curating knowledge sources, managing connectors and their permissions, building Skills, and maintaining configurations across personal, team and org scopes over time.
This domain is roughly 7 of 60 items. It tests whether you can set Claude up to behave consistently and correctly for a recurring purpose: configuring Projects with the right instructions and knowledge, curating knowledge sources so they stay fresh and non-conflicting, managing connectors and their permission implications, packaging repeatable procedures as Skills, and keeping all of this maintained over time at the right scope (personal, team or org).
Learning objectives
By the end of this page you should be able to:
- Configure a Project: custom instructions, knowledge files and project memory.
- Write effective system-level instructions – role, tone, do/don’t, format defaults, escalation rules.
- Curate knowledge sources for freshness, size, conflicts and versioning.
- Manage connectors and understand their permission implications.
- Use Skills as reusable procedures.
- Maintain configurations over time – review cadence, change log, ownership.
- Choose the right scope: personal vs. team vs. org.
5.1 Configuring a Project
A Project turns ad-hoc chatting into a consistent, reusable workspace. Three parts do the work:
| Component | What it holds | Effect |
|---|---|---|
| Custom instructions | A persistent system-level brief (role, tone, rules, format defaults) | Applied to every chat in the Project automatically |
| Knowledge files | Reference documents (policies, product info, style guides) | Grounds answers in your material without re-pasting |
| Project memory | Accumulated context across the Project’s chats | Continuity without restating everything |
The goal is that anyone starting a chat in the Project gets consistent, grounded, correctly-toned output without re-typing the setup.
Exam signal
“Every chat needs the same rules/tone/reference docs” → configure a Project. If the need is a repeatable multi-step procedure rather than shared context, that is a Skill (5.5).
5.2 Writing effective system-level instructions
Custom instructions are a mini system prompt. Good ones are specific, ordered and testable.
| Element | Purpose | Example |
|---|---|---|
| Role | Frame the expertise | “You are our internal HR policy assistant.” |
| Tone | Set the register | “Warm, plain language; no legalese.” |
| Do | Positive rules | “Always cite the policy section you used.” |
| Don’t | Guardrails | “Never give individual legal advice.” |
| Format defaults | Output shape | “Default to short bullet answers unless asked otherwise.” |
| Escalation rules | When to hand off | “For termination or disability questions, tell the user to contact HR Business Partner.” |
Role: You are the ACME internal HR policy assistant.Tone: Warm, plain English, no jargon. Be concise.Do: Answer only from the attached HR handbook; cite the section.Don't: Do not give individual legal advice or interpret contracts.Format: Short bullets; end with 'Source: <section>'.Escalate: For termination, disability, or pay-equity questions, direct the user to their HR Business Partner instead of answering.Instructions are not enforcement
Custom instructions guide behaviour; they do not hard-guarantee it. For business rules that must never be broken (e.g., “never disclose salary data”), rely on access control and connector scoping, not just a written instruction. This mirrors the Architect exam’s rule that prompt text is not a substitute for programmatic enforcement.
5.3 Curating knowledge sources
Knowledge files are only as good as their curation. Four properties matter.
| Property | Risk if ignored | Practice |
|---|---|---|
| Freshness | Stale policy answered as current | Date documents; remove superseded versions |
| Size / relevance | Bloated, noisy knowledge dilutes answers | Include only what is needed; trim boilerplate |
| Conflicts | Two docs disagree; answers become unreliable | Resolve conflicts; keep a single source of truth |
| Versioning | No one knows which version answered | Label versions; keep a change record |
The single most common curation failure the exam targets: leaving an old and a new version of the same policy both in the knowledge base, so Claude may cite either. The fix is to remove the superseded version and keep one authoritative source.
Exam signal
Stems mentioning “the policy changed”, “two documents disagree”, or “answers cite outdated figures” point to a knowledge-curation problem (freshness/conflict/versioning), not a prompting or model problem.
5.4 Connectors and their permission implications
Connectors (Google Drive, Gmail, Calendar, Slack, GitHub, and others) extend Claude’s reach into your tools. That reach is exactly the risk.
| Principle | Meaning |
|---|---|
| Least privilege | Connect only what the purpose requires; prefer specific folders/channels over whole accounts |
| Access inheritance | A connector exposes whatever the connected account can see |
| Scope discipline | Personal connectors ≠ team/org connectors; know whose data is reachable |
| Sensitivity awareness | Connecting Gmail/CRM/Slack can bring PII and confidential data into scope (D6) |
| Review over time | Revisit connections; revoke what is no longer needed |
Bad: Connect the entire company Google Drive so Claude 'has everything'.Good: Connect the single 'Product Docs' shared folder the task needs, review quarterly, and revoke when the project ends.Connectors inherit permissions
If you connect an account that can see confidential files, Claude can now reach those files in that context. Scope the connector to the minimum, and remember that data classification and policy (D6) apply to whatever becomes reachable.
5.5 Skills as reusable procedures
A Skill packages a repeatable procedure – the steps, format and rules for a recurring task – so Claude can perform it consistently on demand.
| Projects hold… | Skills hold… |
|---|---|
| Shared context (instructions, knowledge, memory) | A reusable procedure (how to do a specific task) |
| Applied to every chat in the Project | Invoked when the relevant task comes up |
Use a Skill when the same multi-step task recurs and you want the steps captured once and reused – e.g., “produce our standard weekly status report” with fixed sections and formatting. Use a Project when it is shared background context that many different chats need.
Exam signal
“Repeatable procedure / standard process run many times” → Skill. “Shared background/reference/tone for many chats” → Project. Both promote consistency and reduce re-typing; the exam wants you to pick by procedure vs. context.
5.6 Maintaining configurations over time
A configuration is a living asset, not a one-time setup.
-
Assign ownership – name a person/team responsible for each Project, Skill and connector.
-
Set a review cadence – e.g., quarterly review of instructions, knowledge freshness and connector scope.
-
Keep a change log – record what changed, when and why, so answers can be traced to a configuration version.
-
Retire stale content – remove outdated knowledge files and unused connectors.
-
Test after changes – run a few known questions to confirm the configuration still behaves correctly.
Without ownership and cadence, configurations rot: knowledge goes stale, connectors over-accumulate, and answers drift from policy.
5.7 Scope: personal vs. team vs. org
| Scope | Use for | Governance |
|---|---|---|
| Personal | Individual preferences, private drafts | Owned by the individual |
| Team | Shared team context, tone, knowledge | Team-owned; consistent across members |
| Org / Enterprise | Company-wide policy, standard Skills, controlled connectors | Central admin, audit, retention (D6) |
Choose the narrowest scope that meets the need. A personal preference does not belong at org scope; a company policy that everyone must follow does not belong hidden in one person’s personal Project.
Scope and governance move together
Org-scope configurations attract org-scope governance – admin ownership, audit logs, retention and access control. Team and org configurations must be maintained deliberately because many people depend on them.
5.8 A configuration decision tree
When someone brings a recurring need, route it to the right mechanism instead of defaulting to “a longer prompt”.
What kind of recurring need is it?│├─ Shared background / tone / reference docs for many chats│ └─► PROJECT (custom instructions + knowledge files)│├─ A repeatable multi-step PROCEDURE run the same way each time│ └─► SKILL (captures the steps, format and rules)│├─ Personal preferences to recall across my own sessions│ └─► MEMORY (personal scope)│└─ Access to data living in another tool (Drive, Gmail, Slack…) └─► CONNECTOR (scoped to least privilege; review over time)
Must it be identical for EVERYONE in the org? └─► ORG/ENTERPRISE scope + central ownership, audit, retention| Symptom in the stem | Mechanism | Common wrong pick |
|---|---|---|
| “Every chat needs the same rules/docs” | Project | Pasting each time; Memory |
| “Run our standard procedure repeatedly” | Skill | A Project |
| “Answers cite an outdated/old version” | Curate knowledge (remove superseded) | Bigger model; a prompt |
| “Must never expose data X” | Access control / connector scoping | Instruction text alone |
| “Everyone must behave identically” | Org scope | One person’s personal Project |
Exam signal
“Configuration” stems reward the narrowest mechanism that meets the need and treat instruction text as guidance, not enforcement. Watch for “add a rule to the instructions” as a distractor when the real fix is curation or access control.
5.9 Data-classification policy in configuration
Configuration is where governance (D6) becomes concrete: what you put in knowledge files and what you connect determines what data is reachable. A simple policy table keeps setup decisions consistent.
| Data class | In a Project’s knowledge? | Via a connector? | Note |
|---|---|---|---|
| Public | Yes | Yes | No special handling |
| Internal | Yes, on approved tooling | Yes, scoped | Per policy |
| Confidential | Only if approved; minimise | Only scoped, approved | Central ownership; audit |
| Restricted (PII/PHI/PCI) | Usually no – check policy first | Only under strict controls | Escalate if unclear (D6) |
Before/after – a knowledge base that leaked stale figures:
Before: A Project's knowledge held the 2025 and 2026 pricing sheets plus three overlapping FAQ drafts "for completeness". Answers cited whichever it retrieved — sometimes last year's prices.Fix: Remove the superseded 2025 sheet and the duplicate FAQ drafts; keep one dated, authoritative source per topic; add an owner and a quarterly review.After: Answers consistently cite the current pricing, with a change log recording when it was updated and by whom.Reachable = usable
If sensitive data is reachable through a knowledge file or a connector, an instruction saying “don’t use it” does not reliably prevent exposure. The dependable control is to not make restricted data reachable in the first place (curation + connector scoping), matching the Architect principle that prompt text is not enforcement.
5.10 Common misconceptions
| Misconception | Reality | Why it matters on the exam |
|---|---|---|
| “A written instruction guarantees a hard rule.” | Instructions guide; access control/scoping enforces. | Prompt-as-enforcement distractor. |
| “More knowledge files always help.” | Bloated, conflicting knowledge dilutes and confuses. | Over-stuffing distractor. |
| “A Project and a Skill are interchangeable.” | Project = shared context; Skill = repeatable procedure. | Feature-choice item. |
| “Connect the whole account so nothing is missing.” | Least privilege; connectors inherit the account’s access. | Over-privilege distractor. |
| “Set it up once and it stays correct.” | Configs rot; need ownership, cadence, change log. | Maintenance item. |
| “Memory stores our team’s procedure.” | Memory is personal recall, not a shared procedure. | Scope/feature confusion. |
| “Org policy can live in one person’s Project.” | Company-wide needs org scope + central governance. | Scope-mismatch item. |
| “Keeping the old and new policy is safer.” | Conflicting versions make answers unreliable; keep one. | Curation/conflict item. |
5.11 Scenario walkthrough – standing up a compliant HR assistant
Scenario. Dana is asked to configure an HR policy assistant for the whole company. She has the 2026 handbook, last year’s 2025 handbook, a pay-band spreadsheet with individual salaries, and read access to the whole HR Google Drive. A colleague suggests: “Put everything in the knowledge files so it knows everything, add an instruction ‘never reveal salaries’, connect the whole HR Drive, and set it up in your own Project so we can launch today.”
Expert reasoning trace.
- Scope first. A company-wide assistant that must behave identically for all employees belongs at org/Enterprise scope with central ownership, audit and access control – not in Dana’s personal Project. Reject “set it up in your own Project”.
- Curate knowledge, do not dump. Include only the current, authoritative 2026 handbook; remove the 2025 version so answers cannot cite stale policy. Reject “put everything in”.
- Salaries are the crux – reachable equals usable. An instruction “never reveal salaries” is guidance, not enforcement. The dependable control is to not make the salary spreadsheet reachable at all – exclude it from knowledge and do not connect a source that exposes it. Reject reliance on the instruction.
- Connector least privilege. Do not connect the whole HR Drive; scope to the specific folder holding the handbook and public HR docs. Whole-Drive access inherits everything the account can see (including salary data), which reintroduces the exposure just avoided.
- Add escalation rules. For termination, disability, or pay-equity questions, the instructions should direct users to their HR Business Partner rather than answer.
- Maintain it. Name an owner, set a quarterly review of freshness and connector scope, and keep a change log.
Exam-correct decision: org-scope configuration, one authoritative current handbook, salary data made unreachable (excluded + connector scoped, not just an instruction), least-privilege connector, escalation rules, and named ownership with a review cadence. Not dump-everything, not instruction-only salary protection, not whole-Drive connection, not a personal Project.
Exam traps in this domain
| Trap | Why it is wrong |
|---|---|
| “Keep both old and new policy versions in the knowledge base” | Conflicting sources make answers unreliable; keep one authoritative version |
| “Connect the whole Drive/mailbox so Claude has everything” | Violates least privilege; exposes far more than the task needs |
| “A written instruction guarantees Claude never discloses X” | Instructions guide, not enforce; use access control/scoping for hard rules |
| “Set up the Project once and never revisit it” | Configurations rot without a review cadence and ownership |
| “Put a company-wide policy in one person’s personal Project” | Wrong scope; org policy belongs at org scope with governance |
| “Use a Project when the need is a repeatable procedure” | Repeatable procedures are Skills; Projects hold shared context |
| “Dump every document into knowledge for completeness” | Bloated, noisy knowledge dilutes answer quality; curate for relevance |
| “No one owns the configuration” | Without ownership, freshness/conflicts/connector scope go unmanaged |
| “An instruction ‘never reveal X’ guarantees X stays hidden” | Reachable data is usable; exclude it and scope connectors – enforcement, not guidance |
| “Store the team’s procedure in Memory” | Memory is personal recall; a repeatable procedure is a Skill |
| “Connect the whole Drive to a company-wide assistant” | Inherits all the account can see, including restricted data; scope to least privilege |
| “Launch today in a personal Project to move fast” | Company-wide, must-be-identical assistants need org scope and governance |
Practice questions
Each item states how many responses to select. Attempt before revealing.
Q1 · A team's HR assistant Project starts citing an outdated leave policy. Investigation shows both the 2025 and 2026 handbooks are in the knowledge files. What is the BEST fix? (Select one)
A. Switch to a more capable model. B. Remove the superseded 2025 handbook so a single authoritative version remains. C. Add a prompt saying ‘use the newest policy’. D. Start a new Project each month.
Answer: B. Conflicting versions are a knowledge-curation problem; the fix is to keep one authoritative, current source and retire the old one. A bigger model (A) cannot resolve which document is authoritative; a prompt (C) does not reliably override a stale source; new Projects (D) do not address the duplicated files.
Q2 · An Associate needs to guarantee the assistant NEVER exposes individual salary figures. Which approach is MOST reliable? (Select one)
A. Add ‘never reveal salaries’ to the custom instructions and rely on it. B. Ensure the salary data is not in any connected source or knowledge file the assistant can access, in addition to the instruction. C. Use the most expensive model. D. Ask users politely not to request salaries.
Answer: B. Hard guarantees come from not making the data reachable (access control/scoping), not from instruction text alone. An instruction (A) guides but does not enforce; model tier (C) is irrelevant; relying on user behaviour (D) is not a control.
Q3 · A recurring task is 'produce our standard weekly status report' with fixed sections, tone and formatting. What is the BEST way to make this consistent and reusable? (Select one)
A. A Skill capturing the procedure, sections and formatting. B. A longer prompt each week. C. A more expensive model. D. Memory.
Answer: A. A repeatable multi-step procedure with fixed structure is exactly what a Skill is for. A long prompt each week (B) is manual and inconsistent; model tier (C) is unrelated; Memory (D) stores context, not a defined procedure.
Q4 · Which TWO are principles of good connector management? (Select two)
A. Connect only the specific folder or channel the task needs. B. Review connections periodically and revoke what is unused. C. Connect entire accounts so nothing is ever missing. D. Assume connectors have no data-governance implications. E. Never document who owns a connector.
Answer: A and B. Least privilege and periodic review/revocation are core connector-management principles. Connecting whole accounts (C) over-exposes data; connectors clearly have governance implications (D); and ownership must be documented (E).
Q5 · A company-wide code-of-conduct assistant must behave identically for all employees. At which scope should it be configured? (Select one)
A. Each employee’s personal Project. B. Org/Enterprise scope with central ownership, audit and controlled access. C. One manager’s personal account. D. Whichever employee sets it up first.
Answer: B. A company-wide, must-be-consistent assistant belongs at org scope with central governance. Personal scopes (A, C, D) cannot guarantee consistency or apply org-level controls.
Q6 · What is the MOST likely consequence of dumping every company document into a Project's knowledge files 'for completeness'? (Select one)
A. Answers become sharper. B. Noisy, bloated knowledge dilutes relevance and can surface irrelevant or conflicting material. C. The model gets faster. D. Connectors become unnecessary.
Answer: B. Over-stuffed knowledge reduces answer quality and raises conflict risk; curate for relevance. It does not sharpen answers (A), affect speed (C), or replace connectors (D).
Q7 · An Associate writes custom instructions for a support-triage Project. Which element BEST handles cases the assistant should not answer? (Select one)
A. A longer role description. B. Explicit escalation rules, e.g., ‘for billing disputes over $500, direct the user to a human agent’. C. A higher length limit. D. A friendlier tone.
Answer: B. Escalation rules tell the assistant when to hand off rather than answer, which is the correct mechanism for out-of-scope cases. Role length (A), length limits (C) and tone (D) do not define hand-off behaviour.
Q8 · A Project was set up a year ago and never revisited. Which maintenance practices should be in place? (Select two)
A. Named ownership for the Project and its connectors. B. A regular review cadence with a change log. C. Never changing anything once it works. D. Removing all human oversight. E. Deleting the Project after each use.
Answer: A and B. Configurations are living assets needing ownership and a review cadence with a change log. ‘Never change it’ (C) lets it rot; removing oversight (D) and deleting after each use (E) are not maintenance practices.
Q9 · A user wants Claude to remember their personal writing preferences across their own chats. Which is the RIGHT scope and tool? (Select one)
A. Org-scope Enterprise policy. B. Personal scope, via Memory or a personal Project. C. A team-wide Project forced on everyone. D. A connector to the whole company Drive.
Answer: B. Personal preferences belong at personal scope, via Memory or a personal Project. Org policy (A) and a forced team Project (C) are the wrong scope; a company-wide connector (D) is unrelated and over-broad.
Q10 · Two knowledge documents give different figures for the same KPI, and answers now vary. What is the ROOT issue and fix? (Select one)
A. Model quality; upgrade the model. B. A knowledge conflict; resolve to a single authoritative source and version it. C. Prompt length; shorten prompts. D. Connector speed; reconnect.
Answer: B. Divergent answers from disagreeing sources is a knowledge-conflict problem; establish one authoritative, versioned source. Model (A), prompt length (C) and connector speed (D) do not resolve the underlying data disagreement.
Q11 · When adding a connector to a shared team Project, what should the Associate check FIRST? (Select one)
A. Which model is cheapest. B. What data the connected account can access and whether that scope is appropriate for the team’s purpose and policy. C. The font of the output. D. How long the chat can be.
Answer: B. Because connectors inherit the account’s access, the first check is the data scope and its appropriateness under policy. Model cost (A), formatting (C) and chat length (D) are not the governing concern.
Q12 · A team wants both consistent tone/reference docs for many chats AND a repeatable report procedure. Which combination is BEST? (Select one)
A. A Project for the shared context plus a Skill for the repeatable procedure. B. Only a longer prompt. C. Only Memory. D. A separate account per task.
Answer: A. Shared context is a Project’s job and a repeatable procedure is a Skill’s job; combining them fits both needs. A long prompt (B) and Memory (C) cover neither well; separate accounts (D) fragment the setup.
Q13 · After changing a Project's custom instructions, what is a good practice before relying on it? (Select one)
A. Assume it works and roll out immediately. B. Run a few known test questions to confirm the configuration still behaves correctly, and log the change. C. Delete the knowledge files. D. Upgrade the model.
Answer: B. Testing with known questions after a change and logging it prevents silent regressions. Assuming it works (A) risks drift; deleting knowledge (C) and upgrading the model (D) are unrelated to validating the change.
Q14 · Configuring a company-wide HR assistant, an associate has the current handbook, last year's handbook, and a spreadsheet of individual salaries. Which TWO setup choices are correct? (Select two)
A. Include only the current handbook; remove last year’s version. B. Exclude the salary spreadsheet from knowledge and connectors so it is not reachable, rather than relying on a ‘never reveal salaries’ instruction. C. Include both handbooks for completeness. D. Add the salary sheet but instruct Claude never to reveal it. E. Connect the entire HR Drive so nothing is missing.
Answer: A and B. Keep one authoritative current source, and make restricted data unreachable rather than trusting an instruction. Both handbooks (C) create conflicts; instruction-only salary protection (D) is not enforcement; whole-Drive connection (E) violates least privilege and re-exposes the salary data.
Q15 · A company-wide assistant must behave identically for every employee and be auditable. At which scope should it be configured? (Select one)
A. Whoever sets it up first, in their personal Project. B. Org/Enterprise scope with central ownership, audit and controlled access. C. Each team’s private Project, copied around. D. One executive’s personal account.
Answer: B. A must-be-identical, auditable, company-wide assistant belongs at org scope with central governance. Personal or copied-around setups (A, C, D) cannot guarantee consistency or apply org-level controls.
Q16 · A support-triage Project should answer FAQs but hand off billing disputes over $500 to a human. Which instruction element handles this? (Select one)
A. A longer role description. B. An explicit escalation rule naming the condition and the hand-off (‘for disputes over $500, direct the user to a human agent’). C. A higher length limit. D. A warmer tone.
Answer: B. Escalation rules define when to hand off instead of answering, which is the correct mechanism for out-of-scope cases. Role length (A), length limits (C) and tone (D) do not define hand-off behaviour.
Q17 · A team wants BOTH consistent tone/reference docs across many chats AND a repeatable month-end close procedure. Which is BEST? (Select one)
A. Put everything in one long prompt. B. A Project for the shared context plus a Skill for the repeatable procedure. C. Memory for both. D. A separate account per task.
Answer: B. Shared context is a Project’s job and a repeatable procedure is a Skill’s job; combining them fits both needs. A long prompt (A) and Memory (C) cover neither well; separate accounts (D) fragment the setup.
Q18 · Before connecting a Slack workspace to a team Project, what should the associate check FIRST? (Select one)
A. Which model is cheapest. B. What channels/data the connected account can access and whether that scope is appropriate under policy, scoping to only what is needed. C. The output font. D. The maximum chat length.
Answer: B. Connectors inherit the account’s access, so the first check is the data scope and its appropriateness, scoping to least privilege. Model cost (A), formatting (C) and chat length (D) are not the governing concern.
Q19 · An assistant's answers have quietly drifted from current policy over six months, with no record of what changed. Which TWO maintenance practices would have prevented this? (Select two)
A. A named owner responsible for the Project and its knowledge. B. A regular review cadence with a change log. C. Never editing the configuration once live. D. Deleting the Project after each use. E. Removing all oversight to save time.
Answer: A and B. Ownership and a review cadence with a change log keep knowledge fresh and traceable. Never editing (C) lets it rot; deleting after use (D) and removing oversight (E) are not maintenance.
Q20 · An associate proposes adding every departmental document to a Project 'so it knows everything'. What is the MOST likely outcome and the better approach? (Select one)
A. Sharper answers; add even more documents. B. Bloated, conflicting knowledge dilutes relevance; include only the authoritative documents each task needs and curate for conflicts. C. A faster model; no change needed. D. Connectors become unnecessary.
Answer: B. Over-stuffing knowledge lowers answer quality and raises conflict risk; curate for relevance and resolve conflicts. It does not sharpen answers (A), affect speed (C) or replace connectors (D).
Key takeaways
- A Project bundles custom instructions, knowledge files and memory so every chat is consistent and grounded without re-pasting.
- Write instructions with role, tone, do/don’t, format defaults and escalation rules; but instructions guide, they do not enforce hard rules.
- Curate knowledge for freshness, relevance, conflict-resolution and versioning; keep one authoritative source.
- Connectors inherit the account’s access – scope to least privilege and review over time.
- Skills capture repeatable procedures; Projects hold shared context – pick by procedure vs. context.
- Maintain configurations with named ownership, a review cadence and a change log; test after changes.
- Choose the narrowest scope that meets the need; org-scope configurations carry org-scope governance.
- Reachable data is usable data: enforce hard rules by making restricted data unreachable, not by an instruction.
- Match the data class to what you put in knowledge and connect; restricted data (PII/PHI/PCI) needs policy checks or exclusion.
- Route recurring needs through the configuration tree (Project / Skill / Memory / connector / org scope) rather than a longer prompt.
Last updated Sep 18, 2026