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 enumerates them through the search service's data plane to complete the ingestion topology, so every index can be traced back to the source system feeding it.
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.
Mapping ingestion end to end
Discovered via the search enricher, mapping ingestion pipelines from source data to searchable indexes. 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 and stitches the chain: data source, the indexer reading it, the skillset in between, the index at the end. With that chain in inventory, a question like “which production database does this RAG index actually read” stops requiring archaeology.
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.