An engineer at Meridian Line tries to create a Delta Sync index over the port_circulars Delta table and the creation call fails complaining about the source table's configuration. The table exists in Unity Catalog, has a primary key column, and the engineer has SELECT on it. What is the most likely missing prerequisite?
Select an answer to reveal the explanation.
Short Explanation
A Delta Sync index works by tailing the changes on your table, and the thing that produces that change stream is Change Data Feed. No CDF, no change stream, no sync. It is the single most common setup failure on this feature, so make it the first thing you check.
Full Explanation
A Delta Sync index does not re-scan the whole source table every time something changes; it consumes row-level change events, and on Delta those come from Change Data Feed. If CDF was never enabled on the table (delta.enableChangeDataFeed), Vector Search has no change stream to consume and index creation is rejected. Enabling CDF and, where needed, backfilling the table is the fix. The 'embedding column' distractor is the closest-looking trap because it is true for one configuration and false for the other: with Databricks-computed embeddings you supply only text and Databricks embeds it, and with self-managed embeddings you do supply a vector column — but neither situation is what the error describes, and no configuration requires a column literally named 'embedding'. Z-ordering is a Delta file-layout optimization that affects query pruning, not change capture, and has no role in index creation. The managed-versus-external claim is fabricated in both directions: Delta Sync indexes work over Unity Catalog tables regardless of managed or external storage. For the exam, hold the full prerequisite list together: a Unity Catalog Delta table, a primary key, Change Data Feed enabled, and a Vector Search endpoint to host the index.