2.1. Connecting to Enterprise Knowledge Sources
💡 First Principle: Choosing a knowledge source is choosing where retrieval happens. Every option grounds the same generative answers machinery — what differs is which index does the searching, who maintains it, and whose permissions it honors. Match the source to where the truth already lives, and the rest is configuration.
Get this choice wrong and you feel it immediately: answers that miss obvious documents, citations users can't open, or a search index you now maintain for no reason. Exam scenarios in this section nearly always describe the data's current home and the retrieval requirement — your job is to map them to the right source with the least new infrastructure.
| Dimension | Copilot Connectors | Power Platform Connectors | Azure AI Search |
|---|---|---|---|
| Retrieval target | Microsoft 365 semantic index | Structured business systems (Dataverse, SQL, SaaS) | Your own Azure search index |
| Data shape | Unstructured external content (wikis, ticketing, file shares) | Tables, records, live business data | Anything you index (docs, exports, custom corpora) |
| Who maintains retrieval | Microsoft 365 (after you ingest) | The connector queries live | You (index, vectorization, ranking) |
| Control over ranking | Low — inherits M365 search | N/A — query-based | High — vector config, semantic ranker |
| Typical exam cue | "content outside M365 should be searchable like SharePoint" | "answers must reflect live records" | "we already have an index" / "full control over retrieval" |
⚠️ Common Misconception: Knowledge sources and tools are interchangeable ways to extend an agent. Knowledge grounds generative answers — read-only retrieval with citations. Tools perform actions with side effects. A requirement to change anything is never satisfied by a knowledge source.
