Generative AI Engineer Associate · Domain 4: Assembling and Deploying Applications · 22% of the exam
Task 4.2: Create and query a Vector Search index; Explain the key concepts and components of Mosaic AI Vector Search; Configure vector search for a particular solution based on number of embeddings, update frequency, latency, and cost requirements
AI Search (formerly Vector Search) endpoints and indexes, Delta Sync and Direct Vector Access, managed and self-managed embeddings, standard and storage-optimized endpoints, sync modes and filters.
Study it
AI Search endpoints and indexes: sync, embeddings, filters and SKUs
Try each one before opening the answer. Every option is explained, with the Databricks documentation page that proves it.
Question 1 · choose 1
A catalog search must hold 600 million 768-dimension vectors, refreshed nightly. The business accepts about 400 ms per query but wants the lowest cost per vector. How should the engineer configure AI Search?
AA standard endpoint with a continuous Delta Sync index so the newest catalog data is always searchable
BA storage-optimized endpoint with a continuous Delta Sync index
CA standard endpoint with a target QPS set for high throughput
DA storage-optimized endpoint with a triggered Delta Sync index, synced after each nightly load
Show the answer and why
AA standard endpoint with a continuous Delta Sync index so the newest catalog data is always searchable
Incorrect
600 million 768-dimension vectors exceed what one standard endpoint holds, and continuous sync adds streaming cost that nightly data does not need.
BA storage-optimized endpoint with a continuous Delta Sync index
Incorrect
Continuous sync is not supported on storage-optimized endpoints.
CA standard endpoint with a target QPS set for high throughput
Incorrect
High QPS raises throughput and cost; it does not lift the standard endpoint's capacity limit.
DA storage-optimized endpoint with a triggered Delta Sync index, synced after each nightly load
Correct
Storage-optimized endpoints hold over a billion 768-dimension vectors at lower cost per vector with a few hundred milliseconds of latency, and they support only triggered sync.
Choose standard endpoints when latency is critical and the index fits well within their capacity, and storage-optimized endpoints for 10 million or more vectors when some extra latency is acceptable and cost per vector matters.
An architect reviews AI Search index options. Which TWO statements are accurate? (Choose TWO.)
AA Direct Vector Access index is created and updated only through the REST API or the SDK
BA Direct Vector Access index refreshes automatically when its Delta table changes
CA self-managed embedding index can later be switched to managed embeddings
DAdding a column to the source table is picked up by the index without a rebuild
EA self-managed embedding index needs an array<float> vector column and its dimension when created
Show the answer and why
AA Direct Vector Access index is created and updated only through the REST API or the SDK
Correct
Direct Vector Access indexes cannot be created in the UI; you upsert and delete vectors yourself through the API or SDK.
BA Direct Vector Access index refreshes automatically when its Delta table changes
Incorrect
Automatic syncing from a source table is the Delta Sync index; direct access indexes are updated by your own calls.
CA self-managed embedding index can later be switched to managed embeddings
Incorrect
Converting a self-managed embedding index to a Databricks-managed one is not possible; a new index is needed.
DAdding a column to the source table is picked up by the index without a rebuild
Incorrect
The index schema is fixed at creation, so schema changes require creating a new index.
EA self-managed embedding index needs an array<float> vector column and its dimension when created
Correct
With self-managed embeddings you name the precomputed embedding column, which must be array[float], and give the embedding dimension.
Delta Sync indexes sync incrementally from a source table; Direct Vector Access indexes are written through the API. Embedding options and the index schema are fixed when the index is created.
After moving an index from a standard to a storage-optimized endpoint, queries that pass filters as a Python dictionary fail, and queries filtered to a rare product line sometimes return no rows even though matching chunks exist. What explains both symptoms?
AThey take SQL-like filter strings and filter an overfetched candidate set
BFilters are not supported there, and rare values need full-text queries
CDictionary filters need an extra index rebuild, and rare values need reranking
DHybrid queries ignore filters, and the product line column was not synced
Show the answer and why
AThey take SQL-like filter strings and filter an overfetched candidate set
Correct
Storage-optimized endpoints use a SQL-like filter string, and because results are overfetched and then filtered, matches that are not among the top candidates can be missing.
BFilters are not supported there, and rare values need full-text queries
Incorrect
Filtering is supported on both endpoint types; only the filter syntax differs.
CDictionary filters need an extra index rebuild, and rare values need reranking
Incorrect
No rebuild changes the filter syntax, and a reranker reorders results rather than recovering filtered-out matches.
DHybrid queries ignore filters, and the product line column was not synced
Incorrect
Hybrid queries accept filters, and an unsynced column would fail every filtered query, not only rare ones.
Standard endpoints use a filter dictionary; storage-optimized endpoints use a SQL-like filter string. On storage-optimized endpoints filters are applied to an overfetched set, so a query can return nothing when matching documents score below the top.