Azure AI Search Data Source
Does ZopNight manage Azure AI Search Data Source?
Search data sources define the connections indexers read from: blob containers, SQL databases, Cosmos DB. The definitions themselves cost nothing. ZopNight lists each data source by name under its parent search service, read through the data plane with the admin key, so every definition is visible in inventory.
Rules that fire on Azure AI Search Data Source
No active rule family targets Azure AI Search Data Source today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
At a glance
| Field | Value |
|---|---|
| Scheduling notes | discovery only. |
Data sources define the connections indexers read from: blob containers, SQL databases, Cosmos DB. Free objects that complete the search ingestion topology.
A data source is a pointer, not a meter
Nothing bills on the data source object. Its significance is structural: it holds the connection an indexer uses to reach source data (a storage container, a SQL table, a Cosmos DB collection), typically with a stored connection string or managed-identity reference. Read operations an indexer performs against that source do land as transactions and egress on the source system’s own bill, which is the one indirect cost this object controls the path to.
Listing data sources by name
Discovered via the search enricher, which lists each data source by name under its parent search service. Like the other search children, data sources live on the service’s data plane and are invisible to Resource Graph, so ZopNight lists them with the admin key. That key requires Microsoft.Search/searchServices/listAdminKeys/action (Search Service Contributor or a custom role); without it the service is discovered but its data sources are not. ZopNight does not record each data source’s type or target, and it does not stitch the chain from data source to indexer, skillset and index. Trace that chain in the portal when a question like “which production database does this RAG index actually read” comes up.
Stale connections indexers still trust
Data-source problems are hygiene problems. Definitions pointing at deleted containers or renamed databases, discovered only when the indexer’s next run fails. Connection strings that embed credentials rotated long ago, or worse, ones that still work and nobody remembers authorizing. And orphaned data sources left behind after their indexer was deleted, keeping a live credential to a production system inside a search service that no longer uses it. Each is invisible until enumerated.
Data source definitions in the portal
Azure portal → AI Search → select the service → Search management → Data sources lists every definition with its type and target. Pairing that list against the Indexers view shows immediately which definitions are load-bearing and which are dead weight holding credentials for no reason.