Meridian wants its charter-clause Delta table to stay continuously synchronized with a Delta Sync Vector Search index, so that a newly added clause chunk appears in the index without a manual full re-index. What must be enabled on the source Delta table for this?
Select an answer to reveal the explanation.
Short Explanation
Continuous sync only works if the table can tell the index 'here's exactly what rows changed since last time,' and that row-level change tracking is precisely what Change Data Feed turns on.
Full Explanation
Change Data Feed is correct because a Delta Sync Vector Search index that stays continuously synchronized needs a way to identify exactly which rows were added, updated, or deleted since the last sync, and Change Data Feed is the Delta Lake feature that records and exposes that row-level change information for the index to consume. A foreign-key constraint to the Vector Search index is wrong because Delta tables and Vector Search indexes are not related through relational foreign-key constraints - the sync relationship is a Databricks-managed pipeline mechanism, not a database-style referential-integrity constraint, and no such constraint type ties a table to an index. Photon acceleration is wrong because Photon is a query-execution engine that speeds up SQL and DataFrame workloads; it has no bearing on whether an index can detect and consume incremental row-level changes to a source table. Table access control lists on the schema are wrong because permissions govern who can read or write the table, not whether the table exposes a change stream - a fully change-feed-disabled table could still have generous access controls and would still fail to support continuous sync. The exam-relevant fact is that Change Data Feed is the specific named prerequisite Databricks documents for continuous Delta Sync indexing.