Meridian Line's legal team wants the charter-desk assistant to call a specific third-party frontier model that Databricks does not host, but still wants the call routed through a governed Databricks endpoint so usage can be tracked and secrets stay off the client. What should the deployment team configure?
Select an answer to reveal the explanation.
Short Explanation
Foundation Model APIs is Databricks' own hosted menu. When you need someone else's model, External Models is the front door that still gives you one governed endpoint, with the key tucked away as a secret instead of sitting in application code.
Full Explanation
External Models is the Model Serving feature built for exactly this: it creates a governed serving endpoint that proxies to a supported third-party provider (OpenAI, Anthropic, and others), with the provider's API key stored as a Databricks secret rather than embedded in client code, and with the same usage tracking, access control, and unified query interface as any other served model. Foundation Model APIs, by contrast, serves Databricks-hosted foundation models — it cannot be pointed at an arbitrary third-party model name, so that option misapplies the wrong feature to the job. A Vector Search endpoint is for indexing and querying embeddings, not for proxying chat completions to an external provider; repurposing it doesn't correspond to any real configuration. A Unity Catalog function invoked directly from client code would leave the API key wherever the function's caller manages secrets and skips the endpoint-level usage tracking and access control the requirement calls for — it also bypasses the whole point of routing through one governed serving surface. Exam framing: recognizing when a requirement ('someone else's model, but governed and tracked') maps to External Models rather than Foundation Model APIs is a core model-selection distinction for Assembling and Deploying.