Databricks-GenAI-Assoc Governance Practice Question
A platform team is serving a retrieval-augmented generation application. The vector index is built from a Delta table in Unity Catalog, and the team wants every similarity search executed by an end user to be automatically restricted to documents that user is allowed to see, without maintaining a separate index per department. Which approach best enforces this at query time?
⚠ Common exam trap
The trap here is assuming vector search bypasses Unity Catalog authorization, when reads through governed tables still honor row filters.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Create a row filter function on the source Delta table that filters rows by the invoking user's group membership
Row filters evaluate the invoking user's identity as part of the query, so placing the filter on the source Delta table means every read, including retrieval reads that feed similarity search, is automatically scoped to allowed rows. This keeps a single governed index and avoids per-department duplication while still enforcing per-user document visibility at query time.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Apply a column mask to the embedding column so unauthorized users receive null vectors
Why it's wrong here
Masking the embedding column would corrupt similarity computation rather than restrict which documents are candidates. Unauthorized users would still see the row exists and would get null or placeholder vectors, producing meaningless results; masking is value-level redaction, not row-level authorization, so it cannot enforce document visibility here.
- ✗
Build one vector index per department and route queries based on the caller's group
Why it's wrong here
Separate indexes per department can technically work, but the scenario explicitly rejects maintaining a separate index per department. This approach multiplies storage and refresh cost, and routing logic becomes a new place for authorization bugs, so it does not satisfy the stated constraint of a single governed index.
- ✗
Grant SELECT only to a service principal and have the application connect as that principal for all users
Why it's wrong here
Using a single service principal collapses every end user into one identity, so Unity Catalog cannot distinguish departments and the filter would return the union of everything the principal can see. This defeats the goal of per-user restriction and would over-expose documents, even though the service principal pattern is common for backend workloads.
- ✓
Create a row filter function on the source Delta table that filters rows by the invoking user's group membership
Why this is correct
Row filters on the underlying Delta table are evaluated against the invoking principal, so a retrieval query that reads through the table returns only rows that caller may see. Because the vector index is refreshed from that table, embedding the filter there enforces per-user visibility automatically without duplicating indexes per department, which matches the requirement precisely.
About these practice questions
Courseiva writes every Databricks-GenAI-Assoc question from scratch — 330 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Databricks exam blueprint
This Databricks-GenAI-Assoc practice question is part of Courseiva's free Databricks certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the Databricks-GenAI-Assoc exam.