Water utility notebooks must read ADLS without embedding storage keys in source code. How should secrets be obtained from within Azure Databricks?
Select an answer to reveal the explanation.
Short Explanation
Key Vault plus a Databricks secret scope is the locked utility closet—notebooks ask for the ADLS key at runtime instead of taping it to the Git repo wall. Hardcoded keys in markdown are how leaks start.
Full Explanation
Water utility notebooks should obtain ADLS secrets at runtime from Azure Key Vault via an Azure Databricks secret scope rather than embedding keys in source. The secret scope references Key Vault so spark/config or dbutils-style retrieval pulls credentials into the session without committing them to Git. That is the locked utility closet pattern: code asks for the key when needed; the repo wall stays clean.
Hardcoding storage account keys in notebook markdown checked into Git is a classic leak vector and fails secret hygiene. Pasting Key Vault secrets into a shared PowerPoint spreads secrets outside audited secret stores. Disabling storage authentication for anonymous public read on utility telemetry is unacceptable for municipal infrastructure data.
Exam caveat: secret scopes must be backed by proper Key Vault permissions for the Databricks identity; storing secrets in UC volumes or widgets is not equivalent. Prefer managed identities for Azure Storage when possible; when keys/SAS are required, still retrieve them from Key Vault rather than source. Operational check: create/backends the secret scope to Key Vault, grant the job/compute identity get permissions on the ADLS secret, remove hardcoded keys from notebooks, run a read against ADLS, and verify Git history no longer contains live keys.
Prefer to study offline? Printable PDF study book + test engine ($7.50, unofficial). These questions stay free here.