DP-750 · 2.1.3 · Secure and govern Unity Catalog objects
Azure Key Vault secrets
Access Azure Key Vault secrets from within Azure Databricks
Use a Key Vault-backed secret scope to reference secrets from Databricks without embedding credentials in code.
See the secret scope in the product
The screen makes the boundary concrete: Databricks creates a secret scope, while the actual secret material remains in Azure Key Vault. Use the diagrams below to reason about permissions and secret retrieval.
Keep credentials out of code
- 1Azure Key VaultStores the secret value
- 2Secret scopeConnects Databricks to the vault
- 3Scope plus keyIdentifies the secret
- 4Notebook or jobRetrieves it at runtime
Code should reference a secret by scope and key instead of embedding a password, token, or connection string.
Retrieval is still sensitive
- Code needs a credentialRetrieve from the secret scope
- DebuggingNever print the secret
- Persisting resultsNever write the secret to a table
A securely retrieved value can still leak through output, logs, exceptions, or persisted data.
Separate responsibilities
Control access to the Databricks secret scope and the underlying Key Vault independently. The integration reduces credential exposure but does not remove access-control design.
Key points
- Secret scope: Named boundary for retrieving secrets
- Key Vault-backed: Secrets remain managed in Azure Key Vault
- Notebook access: Retrieve by scope and key
- Security: Never print or hard-code secret values
Exam trap
Secret scopes improve handling, but privileged users may still expose retrieved values in code.
Sources · 1 Microsoft Learn page Show ▾
Checked on October 4, 2026. Report a problem
Go deeper on Microsoft Learn
Checked against Microsoft Learn on October 4, 2026. Report a problem with this card