The charter-desk assistant's External Models endpoint needs an API key for a third-party provider. Where should that credential be configured so it is never exposed in application code or in the endpoint's visible configuration?
Select an answer to reveal the explanation.
Short Explanation
A secret belongs in the vault, not taped to the door. Databricks secrets let the endpoint reference the key by name and resolve it only when needed, so the raw value never sits in source code, notebooks, or visible config.
Full Explanation
Databricks secrets provide a managed way to store sensitive values like API keys, with access controlled separately from the code or configuration that uses them; an External Models endpoint configuration references the secret by scope and key name, and the platform resolves the actual value at request time without ever displaying or persisting the raw credential in application code or in the visible endpoint configuration. This is the correct and intended pattern for exactly the scenario described. Hardcoding the key as a string literal in source code is the most common real-world credential leak vector — it ends up in version control history and is visible to anyone who can read the file. A plaintext comment in a notebook is equally exposed and arguably worse, since notebooks are often shared or exported. Appending the key as a URL query parameter exposes it in logs, browser history, and any proxy or gateway that records request URLs, which is a well-known anti-pattern for credential handling. For the exam, remember that Databricks secrets are the governed mechanism for any credential an endpoint or job needs, and that External Models specifically relies on this to keep third-party provider keys out of code and config.