Meridian Line configures an External Models endpoint that routes the marine-insurance underwriting assistant's calls to a third-party provider's API. Where should the provider's API key live so it is never exposed in notebook code, application logs, or version control?
Select an answer to reveal the explanation.
Short Explanation
A private repo is still a place the key sits in plain text, readable by anyone with repo access and permanently in history. Databricks secrets exist so the key lives in exactly one governed place and the endpoint config just points at it.
Full Explanation
Databricks secrets, stored in a secret scope, are the platform's mechanism for holding credentials like a third-party API key without embedding them in code, notebooks, or configuration files; the External Models endpoint configuration references the secret rather than containing the raw key, so the key never appears in a place that gets logged, diffed, or committed. Hard-coding it as a string constant leaves the raw key sitting in plaintext in the source file — 'private repository' doesn't prevent it from persisting in git history, being visible to every collaborator with repo access, or leaking through logs or copy-paste, and it's exactly the anti-pattern secrets exist to avoid. The payload-logging configuration field is for capturing request/response content for evaluation purposes, not for storing credentials — putting a key there is a misuse of a completely different feature, and there's no basis for assuming it's an appropriate credential store even if technically encrypted at rest. Manually setting a cluster environment variable requires re-doing the exposure on every new cluster, leaves the key visible to anyone who can read that cluster's configuration or environment, and doesn't tie the credential to the endpoint the way a referenced secret scope does. Exam framing: this is a governance-adjacent but Assembling-and-Deploying-scoped point — secret scopes are how deployed endpoints hold third-party credentials safely.