The port-operations copilot needs semantic search over the circulars-and-notices Delta table, and the team is assembling the full deployed application. Beyond writing the index-creation call, what infrastructure must exist first for a Delta Sync Vector Search index to be created against that table?
Select an answer to reveal the explanation.
Short Explanation
Two things have to exist before a Delta Sync index will take: somewhere for it to live (an endpoint) and a way for it to hear about changes (Change Data Feed on the source table). Skip either and index creation fails.
Full Explanation
A Delta Sync Vector Search index needs a Vector Search endpoint to be created and attached to — the endpoint is the compute that serves queries against the index, analogous to how a Model Serving endpoint hosts a model. It also requires Change Data Feed to be enabled on the source Delta table, because Delta Sync indexes track and apply incremental changes from the table's change feed rather than rescanning the whole table on every sync. Without CDF enabled, index creation against that table fails outright. An embedding-model serving endpoint may well be involved if the index uses Databricks-computed embeddings, but it doesn't need to be independently load-tested before index creation — that's an invented prerequisite, and self-managed-embeddings indexes don't need a serving endpoint for embedding at all. A manual Parquet export to a volume isn't part of the Delta Sync path; Delta Sync reads the managed Delta table directly via its change feed, so exporting rows elsewhere is unnecessary and actually breaks the sync relationship. Duplicating the table with string-cast columns is not a real requirement and would just create a second, unsynchronized copy of the data. Exam framing: 'create and configure Vector Search endpoints and indexes as part of the deployed application' includes knowing the source-table prerequisites, not just the index-creation call itself.