Courseiva
Application Development →mediumMultiple Choice

Databricks-GenAI-Assoc Application Development Practice Question

A GenAI engineer has a RAG application whose retrieval step uses Databricks Vector Search. Users report that answers are sometimes irrelevant because the retriever pulls chunks from documents the user is not authorized to see. The engineer must enforce per-user document ACLs at query time without re-indexing the corpus. Which approach should the engineer take?

⚠ Common exam trap

The trap here is assuming that Unity Catalog or Delta Sharing ACLs automatically propagate to a Vector Search index's query results, when in fact the index must be filtered explicitly via metadata.

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

✓

Add a metadata column that stores the document's ACL principals, then pass a filter string with the caller's identity to the Vector Search query.

Vector Search indexes can carry metadata columns that are queryable through the filters parameter, letting the application pass the caller's identity so only permitted chunks are returned. This satisfies per-user ACL enforcement at query time without rebuilding the index when permissions change, and it avoids leaking unauthorized content into the application tier. The other approaches either do not affect index results or are operationally impractical at scale.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • ✗

    Post-filter the retrieved chunks in the application layer by querying Unity Catalog for the user's group memberships and dropping chunks that fail the check.

    Why it's wrong here

    Application-layer post-filtering can work, but it retrieves unauthorized chunks into the application before filtering, which is a data-exposure risk and also wastes the limited top-k slots on chunks that get discarded. It does not use Vector Search's native filtering. The scenario asks for enforcement at query time, which the metadata-filter approach handles more safely and efficiently.

  • ✗

    Create a separate Vector Search index per user and have the application route each request to the user-specific index.

    Why it's wrong here

    Per-user indexes would multiply storage and embedding costs and would need rebuilding every time a user's permissions change, which is operationally infeasible. Vector Search endpoints are not designed for one index per end user. This approach also fails to scale when documents are shared across many users, making it a poor fit for the stated requirement.

  • ✓

    Add a metadata column that stores the document's ACL principals, then pass a filter string with the caller's identity to the Vector Search query.

    Why this is correct

    Databricks Vector Search supports metadata columns on the index and accepts a filters argument at query time. Storing allowed principals (users or groups) in a metadata column and passing the caller's identity as a filter ensures only authorized chunks are returned, with no re-indexing. This is the documented pattern for per-user authorization in RAG retrieval on Databricks.

  • ✗

    Enable Delta Sharing on the source Delta table and rely on the workspace's existing table ACLs to filter Vector Search results.

    Why it's wrong here

    Delta Sharing governs access to the underlying Delta table, but a Vector Search index is a separate serving artifact that does not automatically inherit recipient-level row filters at query time. Relying on it would leave unauthorized chunks retrievable through the index endpoint. This option confuses table-level sharing with index-level filtering, so it does not satisfy the per-user ACL requirement in this scenario.

Visual reference

Source Router + ACL permit 10.0.0.0/8 deny any Server 10.0.0.5 ✓ 192.168.1.1 ✗ dropped ACLs evaluate top-down; first match wins — implicit deny all at end

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 →

How Courseiva writes practice questions · Editorial policy

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.