Databricks-DE-Assoc Implementing CI/CD Practice Question
A data engineer is configuring a CI/CD pipeline for Databricks notebooks using GitHub Actions. They need to authenticate to Databricks to deploy notebooks. Which authentication method is recommended for production CI/CD pipelines?
⚠ Common exam trap
The trap here is assuming that a personal access token is sufficient for CI/CD, when service principals with OAuth are the recommended method for production.
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
✓
Use a service principal with OAuth tokens generated via the Databricks CLI or REST API, storing the client ID and secret in GitHub Secrets.
For production CI/CD, authentication should use a service principal with OAuth. The client ID and secret are stored as secrets in the CI system, such as GitHub Secrets. The workflow can then use the Databricks CLI or REST API to authenticate. This approach decouples automation from individual users, supports permission scoping, and is more secure than personal access tokens.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use the Databricks CLI with interactive login during the CI run.
Why it's wrong here
Interactive login requires a browser and user interaction, which is not possible in an automated CI environment. CI runners are headless and cannot perform interactive authentication. This method is suitable for local development but not for pipelines.
- ✗
Store a personal access token (PAT) in GitHub Secrets and use it in the workflow.
Why it's wrong here
Personal access tokens are tied to a user identity and can be revoked if the user leaves or rotates credentials. They also grant the user's full permissions, which may be excessive. For production CI/CD, service principals are preferred because they are not tied to an individual and can have scoped permissions.
- ✓
Use a service principal with OAuth tokens generated via the Databricks CLI or REST API, storing the client ID and secret in GitHub Secrets.
Why this is correct
Service principals are non-human identities that can be granted specific permissions. Using OAuth tokens with a client ID and secret stored as secrets in GitHub Actions allows secure, automated authentication. This is the recommended practice for production CI/CD because it avoids personal credentials and supports fine-grained access control.
- ✗
Embed the Databricks username and password directly in the workflow YAML file.
Why it's wrong here
Embedding credentials in plaintext in the workflow file exposes them to anyone with repository access. GitHub Actions workflows are stored in the repository, so this is a severe security risk. Credentials should never be hardcoded; they must be stored as encrypted secrets.
About these practice questions
One of 276 original Databricks-DE-Assoc practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.