Connectors as Authorized External Reach (CCAO-F)

Reaching the data you already work in

The knowledge base holds documents you upload into a Project. But much of the information a team needs already lives somewhere else, in a Drive folder or an inbox that changes daily. Connectors are how Claude reaches into those systems, and the CCAO-F exam treats knowing what a connector is as a foundational, remember-level skill.

A connector extends Claude's reach into an external system you authorize. Rather than copying a document in, you let Claude search your Google Drive for the right file or find a relevant email in Gmail, working against the live source. That live quality is the defining property, and it is the line that separates a connector from uploaded knowledge.

The user controls the reach

A connector is authorized access, not open access. You decide which systems Claude may reach and what within them is accessible, and that control is part of the mechanism, not an add-on. Nothing is connected that you have not explicitly authorized.

Because you are in control, the connected set is a curation decision. The instinct to connect everything available is the wrong one: a deliberate, narrow set of connectors is easier to reason about and manage than a sprawling one. Connecting more sources is not automatically better, and treating "connect everything" as the default creates ungoverned reach you then have to police. Keep the set intentional.

Control also means connecting the right source in the first place. The obvious add-connector path can route to a public directory of look-alike connectors rather than the ones your organisation has vetted, so on Team or Enterprise it is worth confirming the correct path with your admin before you authorise anything. Wiring a workflow to an unapproved look-alike is an easy mistake that a moment of verification prevents.

Live reach versus a static copy

The cleanest way to hold connectors in mind is against uploaded knowledge, because the two are easy to blur and the exam leans on the contrast.

Uploaded knowledge is a static document: you add it to the Project, and it stays exactly as uploaded until you replace it. A connector is live reach: it queries the current state of the external system each time, so it reflects what is there now. If a Drive document changes, a connector sees the new version; an uploaded copy would still show the old one until re-uploaded. That difference in freshness and mechanism is the whole distinction, and it drives the later decision about connector access versus manual upload.

What the CCAO-F exam trips candidates on

The exam sets two traps. The first is assuming connecting more sources is always better rather than keeping the connected set deliberate. A scenario rewards restraint: a narrow, intentional set of connectors over a connect-everything approach. Recognising that more reach is not automatically better reach is the point.

The second is confusing a connector, which is live access to an external system, with uploaded knowledge, which is a static document added to the Project. A question that hinges on whether Claude sees the current version of a frequently changing file turns on this distinction: a connector does, a static upload does not. Keeping the two mechanisms straight is what the exam is checking.

Common misreadings to avoid

How this shows up on the exam

Domain 5 questions on this point check that you know a connector is authorized, live reach and that you would keep the connected set curated. The reliable readings are: the user controls access, deliberate beats maximal, and a connector is live where an upload is static.

This foundation sets up connector capability boundaries, which describes what a given connector can and cannot do, and it feeds the decision framework in connector access versus manual upload. It also pairs with curating uploaded knowledge, the static counterpart that needs the same deliberate care.