What you will be able to do
- Use READ METADATA and BROWSE to inspect grants, row filters and policies without reading the data
- Fix a retriever that can't reach its index by granting the full set of privileges it needs
- Choose ABAC row filter or column mask policies when a retriever surfaces data it should not
- Recognise the failure modes that no Unity Catalog action resolves
1.Using UC metadata to confirm a governance cause
Evaluation logs tell you that context is missing or that the wrong context came back. Unity Catalog metadata tells you whether governance caused it. You don't need data access to check. READ METADATA lets you view an object's permissions, row filters, column masks and ABAC policies without the ability to change the object or read its data. It is a child of the composite MANAGE privilege. BROWSE goes less deep: it "allows users to discover objects and view their metadata without granting access to the underlying data". It is granted at the catalog level.
With metadata visible, you can check the identity the retriever runs as. Does it hold the privileges needed to query the index? Does a row filter or policy apply to the source? Every Unity Catalog object is a securable with its own privileges, and "A user or group must be explicitly granted a privilege to perform an action." Unity Catalog never assumes access the identity wasn't given. Missing access shows up as missing results.
The evaluation scores alone can't separate the causes. The RetrievalSufficiency judge asks whether the retrieved context provides all the necessary information, so a missing-access gap and a weak index both lower it. The score is only a symptom. To tell them apart, check the retriever identity's grants and any row filters or policies with READ METADATA. Then rerun the same evaluation queries and see whether the scores change once access is corrected.
Checkpoint 1 of 6· Check yourself
A data engineer has been granted BROWSE on a catalog. What can they do with a table in that catalog?
BROWSE is for discovery. It shows metadata and lets users request access, without USE CATALOG or USE SCHEMA, but it gives no data access.
“BROWSE allows users to discover objects and view their metadata without granting access to the underlying data.”Source: docs.databricks.com
2.Retriever can't reach the index: grant the full privilege chain
The most direct governance fix applies when the retriever's identity can't query the index at all, or can only reach part of what it should. The Databricks Apps docs give the requirement for an app's service principal: USE CATALOG on the parent catalog, plus "the USE SCHEMA privilege on the parent schema, and the SELECT privilege on the index". This follows the general Unity Catalog rule for reading an object. Usage privileges on both parent containers are prerequisites, and "Having only the SELECT privilege on a table is not sufficient to read it" if either one is missing.
Two details decide which grant is the right answer. First, inheritance: "When you grant a privilege on a container object, that privilege automatically applies to all current and future child objects." A grant at schema level therefore covers indexes created later. Second, MANAGE isn't a data-access shortcut. It lowers usage-privilege requirements only for metadata capabilities: "Data-access privileges such as SELECT and MODIFY still require USE CATALOG and USE SCHEMA, even for users with MANAGE." The same rules apply to evaluation. The AI Search evaluation job "inherit[s] Unity Catalog permissions from the AI Search index", so anyone with query access can start a run and view the results dashboard.
| Privilege | What it allows | Role in retrieval failures |
|---|---|---|
| USE CATALOG | Required to interact with any object inside a catalog. Does not itself grant access to data. | Must be present on the index's parent catalog |
| USE SCHEMA | Required to interact with any object inside a schema. Does not itself grant access to data. | Must be present on the index's parent schema |
| SELECT | Query data from a table, view, materialized view, or OpenSharing share. | The data-access grant the retriever needs |
| READ METADATA | View owner-visible metadata, including permissions, row filters, column masks, and ABAC policies | Diagnose without reading data |
| MANAGE | Manage privileges, transfer ownership, rename, and drop an object. | Lets you fix grants, but does not by itself let you read data |
Checkpoint 2 of 6· Check yourself
An agent's service principal holds SELECT on an AI Search index, but its queries still fail with access errors. READ METADATA shows no USE CATALOG or USE SCHEMA grant on the index's parents. Which grant most directly resolves the failure?
Accessing the index takes all three privileges: USE CATALOG, USE SCHEMA and SELECT. The missing pieces are the two usage privileges. MANAGE and READ METADATA don't grant data access, and SELECT on the source table doesn't replace them.
“the USE SCHEMA privilege on the parent schema, and the SELECT privilege on the index”Source: docs.databricks.com
3.Retriever surfaces what it shouldn't: ABAC row filters and column masks
The opposite governance failure is over-exposure. Retrieval succeeds, but the context contains rows or columns this user shouldn't see. Removing the whole grant would break retrieval for everyone. The fix is to narrow what each identity can see inside the object. In Unity Catalog, "ABAC supports row and column-level security through row filter policies and column mask policies on tables."
ABAC policies are driven by governed tags, and they are attached at a level of the hierarchy: metastore (Beta), catalog, schema or table. "When a securable object has the attributes targeted by a policy, that policy takes effect automatically". One policy can therefore protect every tagged table in a schema, including tables added after the policy was written. These policies are defined on tables, so don't assume the effect without checking it. After you apply a policy, use READ METADATA to confirm the filter or mask is attached, then rerun your evaluation and confirm the leaked context no longer appears. Keep in mind that a row filter also lowers recall for the users it restricts. A drop in sufficiency for those users after the change is expected behaviour, not a new failure.
Checkpoint 3 of 6· Check yourself
A support chatbot's retrieval logs show answers built from other regions' customer records. Which Unity Catalog action most directly resolves this while keeping retrieval working for authorised users?
Row filter policies limit which rows each identity can read, so authorised retrieval keeps working while the leak stops. Revoking SELECT breaks retrieval for everyone.
“ABAC supports row and column-level security through row filter policies and column mask policies on tables.”Source: docs.databricks.com
Sources6
4.Failures that no grant will fix
Part of choosing the right governance action is knowing when there isn't one. Unity Catalog decides who can see what. It doesn't change how relevant or how fresh the results are. A stale index needs a sync, through Triggered Sync or by switching to Continuous Sync. Poor ranking shows up as relevant documents sitting low in the results, and the AI Search evaluation tests this by running every strategy "with and without the reranker". Queries that miss exact terms such as product codes are what hybrid search is for, because it combines keyword and semantic matching. Irrelevant chunks from the wrong product or version are a job for metadata filtering, which the retrieval quality guide calls "your biggest lever for retrieval quality". A query can filter only on columns that are in the index: "A query can define filters based on any indexed column in the Delta table." So a filter column such as department must be synced into the index first. Adding it is an index schema change, and a schema change means rebuilding the index.
The embedding model is another retrieval-quality factor outside Unity Catalog. The RAG quality overview lists it with the other data pipeline choices: "Retrieval quality can be influenced by both the data pipeline (for example, parsing/chunking strategy, metadata strategy, embedding model)". Changing it is a pipeline decision, not a grant or a policy.
So the decision has two steps. Confirm from eval logs that retrieval, not generation, is failing. Then use UC metadata to check whether governance explains it. If access is missing, grant the full privilege chain. If data is over-exposed, apply a row filter or column mask policy. If grants and policies look right, the fix lies in the retrieval configuration, not in Unity Catalog.
Checkpoint 4 of 6· Match them up
Match each diagnosed failure to the action that most directly resolves it
Tap a term, then the definition that fits it.
Only access gaps and over-exposure are governance problems. Ranking and freshness are fixed in the AI Search configuration.
“Each strategy is also evaluated with and without the reranker.”Source: docs.databricks.com
Checkpoint 5 of 6· Exam question
An internal-policy chatbot uses AI Search over a single index containing HR, Finance, and Legal documents with no metadata columns. MLflow eval logs show low precision scores: for narrow questions like "What is the parental leave policy?" the top-k results mix in unrelated Finance and Legal chunks alongside the correct HR chunk, pushing relevant content lower in the ranking. UC metadata shows the source Delta table does have `department` populated for every row. Which action most directly resolves this failure mode?
Correct answer: E — Add a metadata filter on the `department` column so queries can be scoped to the relevant document set before ranking.
Checkpoint 6 of 6· Exam question
A newly launched AI Search agent over engineering runbooks shows poor relevance scores in MLflow eval. Debugging the raw retrieval traces reveals that the top-ranked chunks for a query like "restart the ingestion service" include chunks about unrelated topics that happen to share generic words like "service" and "restart," while a side-by-side test with a stronger third-party embedding model on the same chunks returns noticeably more relevant top-k results for the same queries. UC lineage confirms chunking, ingestion, and metadata are all otherwise correctly configured. Which failure mode and Unity Catalog-governed remediation path best fits this evidence?
Correct answer: D — Embedding model mismatch; register a fine-tuned or better-suited embedding model in Unity Catalog and rebuild the index using it.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Granting SELECT on the index is enough for a retriever to query it.Why is that wrong?
Reading an object also requires USE CATALOG and USE SCHEMA on its parent containers. Without them, SELECT does nothing.
Covered in Retriever can't reach the index: grant the full privilege chain
2.Granting MANAGE on the index will let the retriever read its data.Why is that wrong?
MANAGE lowers usage-privilege requirements only for metadata capabilities. Reading data still needs SELECT together with USE CATALOG and USE SCHEMA.
Covered in Retriever can't reach the index: grant the full privilege chain
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.https://docs.databricks.com/aws/en/data-governance/unity-catalog/access-control/privileges-referenceOfficial docs
“View all owner-visible metadata for an object, including permissions, row filters, column masks, and ABAC policies”
↩︎ Using UC metadata to confirm a governance cause - 2.https://docs.databricks.com/aws/en/data-governance/unity-catalog/access-control/permissions-conceptsOfficial docs
“A user or group must be explicitly granted a privilege to perform an action.”
↩︎ Using UC metadata to confirm a governance cause“When you grant a privilege on a container object, that privilege automatically applies to all current and future child objects.”
↩︎ Retriever can't reach the index: grant the full privilege chain“Having only the SELECT privilege on a table is not sufficient to read it”
↩︎ Exam trap 1“Data-access privileges such as SELECT and MODIFY still require USE CATALOG and USE SCHEMA, even for users with MANAGE.”
↩︎ Exam trap 2“BROWSE allows users to discover objects and view their metadata without granting access to the underlying data.”
↩︎ Checkpoint - 3.
“Does the context provide all necessary information to generate a response that includes the ground truth facts?”
↩︎ Using UC metadata to confirm a governance cause - 4.
“the USE SCHEMA privilege on the parent schema, and the SELECT privilege on the index”
↩︎ Retriever can't reach the index: grant the full privilege chain - 5.
“The evaluation job and results dashboard inherit Unity Catalog permissions from the AI Search index.”
↩︎ Retriever can't reach the index: grant the full privilege chain“Each strategy is also evaluated with and without the reranker.”
↩︎ Checkpoint - 6.
“When a securable object has the attributes targeted by a policy, that policy takes effect automatically”
↩︎ Retriever surfaces what it shouldn't: ABAC row filters and column masks“ABAC supports row and column-level security through row filter policies and column mask policies on tables.”
↩︎ Checkpoint - 7.
“This is your biggest lever for retrieval quality.”
↩︎ Failures that no grant will fix“Want fallback when semantic search misses obvious keyword matches.”
↩︎ Failures that no grant will fix - 8.
“A query can define filters based on any indexed column in the Delta table.”
↩︎ Failures that no grant will fix - 9.
“Retrieval quality can be influenced by both the data pipeline (for example, parsing/chunking strategy, metadata strategy, embedding model)”
↩︎ Failures that no grant will fix - 10.
“Schema changes to the source table are not supported unless you rebuild the index.”
↩︎ Failures that no grant will fix