Databricks-GenAI-Assoc Design Applications Practice Question
An engineer is designing a GenAI application that must call an external LLM provider's API. The provider key must not appear in notebook code, job logs, or Git. The team already uses Databricks and wants the key to be injected into the serving endpoint at runtime. Which Databricks capability should the engineer use?
⚠ Common exam trap
A common mix-up: candidates confuse governed storage such as Unity Catalog volumes with secret management, even though volumes are not designed to protect credentials from readers.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Databricks secrets stored in a secret scope, referenced from the serving endpoint configuration using secret references.
Databricks secret scopes with secret references keep credentials encrypted and out of source control, logs, and notebooks, while still allowing Model Serving to inject them at runtime. Spark config values, Unity Catalog volume files, and model signature parameters all expose the key through metadata, logs, or request payloads and do not provide runtime injection for serving endpoints.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Hard-coding the provider key in the model signature so the endpoint receives it as a request parameter.
Why it's wrong here
Embedding the key in the model signature exposes it in the endpoint metadata and in every inference request payload, which is worse than storing it in code. Request payloads may be logged, and signature metadata is visible to workspace users, so this design leaks the credential and violates the stated constraints.
- ✓
Databricks secrets stored in a secret scope, referenced from the serving endpoint configuration using secret references.
Why this is correct
Databricks secret scopes store credentials in an encrypted backend, and secret references let the serving endpoint configuration pull the key at runtime without exposing it in code, logs, or Git. This directly satisfies the requirement that the provider key never appear in notebook code or job logs while still being available to the endpoint.
- ✗
A Unity Catalog volume containing a text file with the provider key, mounted into the serving endpoint.
Why it's wrong here
A Unity Catalog volume is a governed storage location, not a secret store, and the contents are readable by anyone with volume privileges. Writing the key to a file exposes it to browsing, versioning, and accidental download, and Model Serving does not mount volumes for secret injection, so this fails the security requirement.
- ✗
Environment variables defined in the cluster's Spark configuration and read by the notebook at runtime.
Why it's wrong here
Spark configuration values are visible in cluster configuration, job definitions, and sometimes logs, so a provider key placed there can leak through the same channels the scenario forbids. It also does not integrate with Model Serving endpoint configuration, meaning the key would not be injected into the serving runtime as required.
About these practice questions
This Databricks-GenAI-Assoc question is part of Courseiva's 330-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Databricks exam blueprint
This Databricks-GenAI-Assoc practice question is part of Courseiva's free Databricks certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the Databricks-GenAI-Assoc exam.