Domain 5 — Configuration and Knowledge Management (12%)

12% of the exam, roughly 7 questions. Almost all of it is about Projects: what goes in them, what does not, and how they stay useful over time.

5.1 What a Project actually is

A Project is a workspace that carries three things across every conversation inside it:

• Instructions — standing guidance about role, tone, audience, house rules and what to avoid. Applied to every chat in the Project without you restating it.
• Knowledge — uploaded documents Claude can draw on: style guides, product specifications, past reports, policies, reference data.
• Its own chat history — separate from your other work, so the Project stays coherent.

Projects are available on every plan, with a limited number on Free. Paid plans expand how much project knowledge you can hold effectively. Sharing a Project with colleagues — with view or edit permissions — is a Team and Enterprise capability, which is the examinable difference between an individual setup and an organisational one.

5.2 Writing Project instructions

The same discipline as a good prompt, made permanent. A useful set of instructions states:

• The role and perspective — "You are supporting the internal communications team at a mid-sized hospital group."
• The audience for most outputs — "Readers are clinical staff, not administrators."
• House conventions — British spelling, the terms the organisation uses and the ones it avoids, required disclaimers.
• Standing constraints — "Never state a figure that is not in the attached data." "Always flag where a clinician needs to verify."
• Default output shape, where the Project produces one kind of thing repeatedly.

Keep them specific and short. Vague instructions ("be professional") do almost nothing; long ones compete with the actual task for attention.

5.3 Curating knowledge

Project knowledge is not an archive. Everything in it competes for attention, and stale material is worse than no material because Claude will use it confidently.

Superseded documents are the most examinable failure here. When a Project starts producing outdated claims, the answer is to remove the old document, not to add an instruction telling Claude to ignore it.

5.4 Connectors and knowledge sources

Connectors let Claude read from systems your organisation already uses, so material does not have to be uploaded by hand. Two things to know for the exam: what a connector can reach is bounded by the permissions it was granted, and whether connectors are available at all is typically an organisational decision made by an administrator, not an individual preference.

Choose an upload when the source is a fixed document. Choose a connector when the material lives in a system and changes.

5.5 Maintaining a configuration

Configurations rot quietly. A Project set up in January with the then-current pricing sheet keeps producing January's prices in June, confidently, and nobody notices until a customer does. Treat a shared Project as a maintained asset: a named owner, a review when the underlying material changes, and removal of documents that no longer apply.

The organisational version of the same point: when several people rely on one Project, changes to its instructions affect everyone's output. Shared configurations need change discipline in a way personal ones do not.

← Previous: Domain 4 — Workflow Integration and Solution Design  |  Next: Domain 6 — Governance, Risk and Responsible Use →