Databricks-DE-Assoc Implementing CI/CD Practice Question
A team is using the Databricks CLI in their CI/CD pipeline to deploy jobs and notebooks. They need the pipeline to authenticate to a production workspace without embedding a personal user's credentials. Which authentication method should they configure for the CLI?
⚠ Common exam trap
The trap here is assuming any valid Databricks credential works for CI/CD, when automation should use a non-human service principal rather than a personal token.
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
✓
A service principal with an OAuth token or client credentials configured in the CLI profile.
For CI/CD automation, Databricks recommends authenticating the CLI with a service principal rather than a personal user identity. Service principals are non-human accounts that can be granted scoped permissions, and the CLI supports OAuth client credentials or service principal tokens. This avoids coupling deployments to an employee's account and supports credential rotation, auditing, and least privilege in production pipelines.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
A personal access token generated from a developer's Databricks account.
Why it's wrong here
A personal access token is tied to an individual user and breaks when that user leaves or rotates credentials. It also grants the user's full permissions, which violates least privilege for automation. CI/CD pipelines should use non-human identities so that access can be scoped and audited independently of any employee.
- ✓
A service principal with an OAuth token or client credentials configured in the CLI profile.
Why this is correct
Service principals are non-human identities designed for automation. The Databricks CLI supports authenticating as a service principal using OAuth client credentials or a service principal token, which can be scoped to only the needed workspace permissions. This avoids dependency on individual users and supports rotation and auditing in CI/CD.
- ✗
The workspace's built-in admin username and password stored in the CI environment variables.
Why it's wrong here
Databricks workspaces do not use a built-in admin username and password for API or CLI access. Storing such credentials in environment variables would also be insecure and overly privileged. This option describes a pattern that does not exist in Databricks authentication and would fail at runtime.
- ✗
An SSH key pair registered in the Databricks workspace under the deploying user's profile.
Why it's wrong here
SSH keys are used for Git operations or compute access, not for authenticating the Databricks CLI to the workspace API. Databricks CLI authentication relies on PATs, OAuth, or service principal credentials. Registering an SSH key would not grant the CLI the API permissions needed to deploy jobs or notebooks.
About these practice questions
This Databricks-DE-Assoc question is part of Courseiva's 276-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-DE-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-DE-Assoc exam.