CCAO-F Glossary - Configuration and Knowledge Management

Quick-lookup definitions for every domain, with exam context and links back to the lesson that covers each term.

Claude Project: A persistent workspace, distinct from a single conversation, whose configuration — custom instructions and an uploaded knowledge base — carries forward automatically into every future conversation started inside it, for every teammate with access. This persistence is the point: a team's Project should behave the same way in its fortieth conversation as in its first, without anyone re-explaining conventions or re-uploading material.; Exam context: Expect scenarios that test whether you recognize a Project's configuration as automatically inherited by new conversations, versus a distractor suggesting content must be re-pasted or re-described each time.; See also: 5.1 Configuring Project Instructions and Knowledge
Project Knowledge Base: The Project-level area for uploading reference documents — templates, style guides, product specs, prior work — that Claude can search and draw on across every conversation in the Project. It accepts common document formats directly, including DOCX, PDF, and plain text, so teams can upload existing documents as-is without converting them first.; Exam context: A common distractor claims the knowledge base only accepts plain text and requires conversion first; the exam expects you to know DOCX and PDF are supported natively.; See also: 5.1 Configuring Project Instructions and Knowledge
Project-Level Instructions: The custom instructions field where a Project's standing behavior lives: role, tone, and house rules that should apply across essentially every conversation in the Project. Instructions describing document contents in prose are a poor substitute for the actual document being available in the knowledge base to search and quote from — the two levers do different jobs.; Exam context: Distinguish this from a one-off conversational system prompt: Project instructions must hold up across many future conversations and multiple teammates, not just the task at hand when they were written.; See also: 5.1 Configuring Project Instructions and Knowledge
Connector: A mechanism that gives Claude live access to an external data source (such as Drive or Gmail), so a conversation queries the current state of that source directly rather than working from a copy that can drift out of date. This contrasts with a knowledge base upload, which is a fixed snapshot as of upload time.; Exam context: The exam tests whether you can match material to the right lever: genuinely stable, once-reviewed content fits a knowledge base upload, while content that changes on its own schedule (an inbox, a live spreadsheet) fits a connector.; See also: 5.2 Connectors: Drive, Gmail, and Data Sources
Google Drive Connector: A connector that lets Claude search and read files in a connected Drive directly from a conversation, pulling in current content without anyone manually opening, copying, and pasting it. It also supports writing back: Claude can create folders and save Claude-generated files directly into Drive, not just read existing files.; Exam context: A frequent distractor assumes connectors are strictly read-only or that saving a generated file still requires a manual download-then-upload round trip, or that the destination folder must already exist — all three are wrong for the Drive connector.; See also: 5.2 Connectors: Drive, Gmail, and Data Sources
Gmail Connector: A connector that lets Claude search and read messages and threads in a connected inbox to ground a task in the actual current state of a conversation or a specific email, instead of a teammate summarizing the thread manually first. It works on the same live-access principle as the Drive connector.; Exam context: Watch for an option claiming the Gmail connector only works with content uploaded to the knowledge base ahead of time — that describes an upload, not a connector's defining live-access behavior.; See also: 5.2 Connectors: Drive, Gmail, and Data Sources
Narrow-Instructions Trap: The most common mistake in Project instructions: writing them around the first real task rather than the Project's general purpose, so they work perfectly for that one request and then break the moment a teammate opens the Project for a different one. The fix is separating what's genuinely durable (role, scope, style) from what's specific to one request, and leaving the task-specific part out of the standing instructions entirely.; Exam context: Expect a scenario with instructions naming a specific dataset, deadline, or one-time request; the correct fix is generalizing the instructions, not writing an even more detailed version of the same task-specific wording.; See also: 5.3 Writing Effective Project Instructions
Knowledge Source Prioritization: Guidance within Project instructions on which knowledge source is authoritative when a Project has more than one uploaded document or connector — for example, stating that an uploaded style guide takes priority over older guidance a teammate pastes into a message. Without this, Claude has no way to know which source to prioritize when they conflict.; Exam context: The exam frames this as one of the durable elements that belongs in standing Project instructions, alongside role, scope, and format defaults — an easy item to omit when instructions are written narrowly around one task.; See also: 5.3 Writing Effective Project Instructions
Configuration Staleness: The state in which a Project's uploaded knowledge base or written instructions no longer reflect reality because underlying documents or processes changed after setup, while Claude keeps answering just as confidently either way. Signs include a superseded document still sitting in the knowledge base, instructions referencing a since-changed process, or multiple versions of the same document accumulated with none removed.; Exam context: A common distractor treats a well-configured Project as a finished, permanent state, or tries to fix a stale answer by editing the prompt or a single conversation rather than the actual outdated file or instruction in the Project's configuration.; See also: 5.4 Maintaining Configurations Over Time
Configuration Ownership and Review Cadence: The practice of assigning someone accountable for periodically reviewing a shared Project's instructions and knowledge base, removing or replacing outdated files, and updating instructions as processes change. For a shared Project used by a whole team over months, nobody is naturally positioned to notice drift unless someone is explicitly responsible for it — a lightweight recurring review is enough to catch most drift before it causes a mistake.; Exam context: The exam's 'inform, maintain, and update' framing expects treating configuration as living infrastructure, not a one-time setup task; an owner need not be the person who originally created the Project.; See also: 5.4 Maintaining Configurations Over Time