Databricks Generative AI Engineer Associate: Data preparation Practice Questions

Option C is correct: overlap is specifically designed to prevent relevant content from being split cleanly between two chunks where neither chunk contains the full context. Option A is correct: if a key phrase straddles a boundary, the overlapping region ensures it appears in full in at least one chunk, improving recall for boundary-spanning content. Option F is correct: each chunk that carries surrounding context (from the overlap) is more self-contained and interpretable by the LLM without requiring it to infer missing context. Option E is the opposite of the truth—overlap increases the total number of chunks and therefore increases storage costs. Option D is false: overlap does not replace a re-ranker; retrieved chunks may still be irrelevant, and a re-ranker is a separate precision-improvement mechanism. Option B is false: overlap is a fixed-size chunking parameter and has no relationship to semantic chunking failures.

Databricks Vector Search requires the source Delta table to have Change Data Feed (CDF) enabled so the index can track incremental changes and sync efficiently, and to have a primary key column that uniquely identifies each row so the index can correctly upsert and delete records. Unity Catalog (option C) is recommended but not strictly required for all Vector Search configurations—the index can be created on tables in the hive_metastore as well. Partitioning by the embedding column (option E) is not a requirement and does not affect Vector Search functionality. Option A is incorrect—the source must be a Delta table (which always has a Delta log); plain Parquet without a Delta log is not supported.

Correct (B): Document-aware chunking leverages the existing heading structure to produce chunks that align with the logical units of the content (sections). Because user queries map to individual sections, this produces chunks with high topical coherence, maximizing the chance that a relevant section is retrieved intact. — Wrong (A): Fixed-size chunking at 512 tokens ignores section boundaries and will routinely split a single section across multiple chunks or merge parts of different sections, reducing chunk coherence and retrieval precision. — Wrong (C): Semantic chunking by sentence-embedding similarity can produce reasonable groupings, but it ignores the authoritative structure already present in the document; the heading-based structure is more reliable than learned similarity for this use case. — Wrong (D): A 4,096-token fixed-size chunk risks merging multiple short sections into one chunk, reducing retrieval specificity; narrow clinical queries will retrieve chunks containing irrelevant sections alongside the relevant one.

Correct (A): Change Data Feed must be enabled on the source Delta table so that Databricks Vector Search can identify which rows have been inserted, updated, or deleted since the last sync cycle. Without CDF, incremental sync is not possible. — Correct (D): Delta Sync Indexes do propagate deletes; when a row is removed from the source Delta table, the next synchronization pass removes the corresponding embedding vector from the index, keeping the index consistent. — Wrong (B): While both continuous and triggered sync modes exist, the statement alone does not describe a requirement; it is partially correct but not one of the two most precise and complete true statements in context. More importantly, the key enabling requirement is CDF (option A). — Wrong (C): While Unity Catalog is the recommended governance layer, this absolute exclusion is an overstatement; the primary technical requirement is CDF enablement, not necessarily Unity Catalog. — Wrong (E): The primary key column is required but it does not need to be of type STRING; integer primary keys are also supported. — Wrong (F): This is false; Delta Sync Indexes do support updates and deletes in addition to inserts.

Delta Sync indexes rely on the Delta table's Change Data Feed (CDF) to identify which rows have been inserted, updated, or deleted since the last sync. If CDF was not enabled before the updates were written, those change records are not logged in the Delta log, and the Vector Search sync process has no way to detect which rows changed. As a result, the index is not updated. Option C is incorrect—partitioning has no effect on CDF or Vector Search sync behavior. Option D is incorrect—Delta Sync is the correct index type for incremental updates; snapshot indexes are less efficient for update-heavy workloads, not more. Option A is incorrect—while Unity Catalog is recommended, it is not a hard requirement for CDF to function; CDF is a Delta table feature that works in both Unity Catalog and hive_metastore contexts.