Courseiva
Implementing CI/CD →mediumMultiple Select

Databricks-DE-Assoc Implementing CI/CD Practice Question

A team is setting up a CI/CD pipeline that deploys Databricks Asset Bundles to production. They want the pipeline to be secure and to fail fast before any production resources are changed. Which TWO practices should they implement? (Choose two.)

⚠ Common exam trap

The trap here is treating broad permissions or early deployment as safety measures, when least privilege and pre-deploy validation are what actually protect 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

✓

Authenticate the deployment using a service principal with credentials injected from the CI system's secret manager at runtime.

Failing fast and staying secure means validating the bundle before deploying and authenticating with a service principal whose secret comes from the CI secret manager. Validation catches configuration errors before production is touched, and the secret manager keeps credentials out of the repository. Plaintext secrets, admin-level permissions, and branch-agnostic production deploys all increase risk without meeting the stated goals.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • ✗

    Run the deployment on every push to any branch so problems are discovered as early as possible in feature development.

    Why it's wrong here

    Deploying to production from every branch would push unreviewed feature code into the production workspace, bypassing code review and risking broken resources. Fail-fast validation belongs earlier in the pipeline, but production deployment must be gated to the main branch or an approved release. This practice undermines both safety and review requirements.

  • ✓

    Authenticate the deployment using a service principal with credentials injected from the CI system's secret manager at runtime.

    Why this is correct

    A service principal provides non-interactive, auditable automation identity, and injecting its secret from the CI secret manager at runtime keeps credentials out of the repository and logs. This is the recommended way to authenticate deployments in CI/CD. It satisfies the security requirement while allowing the pipeline to deploy to production reliably across runs.

  • ✓

    Run databricks bundle validate in an earlier pipeline stage so configuration errors are caught before the deploy step executes.

    Why this is correct

    bundle validate checks the databricks.yml and resource definitions for errors without modifying the workspace. Running it in an earlier stage means broken configuration fails the pipeline before the deploy step, so production is never touched by an invalid bundle. This directly supports the goal of failing fast and protecting production from partial or erroneous deployments.

  • ✗

    Store the service principal secret as a plaintext variable in the repository's CI configuration file so all pipeline stages can read it.

    Why it's wrong here

    Committing a service principal secret in plaintext exposes production credentials to anyone with repository read access and to the Git history permanently. Pipelines should retrieve credentials from the CI system's secret manager, which masks them in logs and restricts access. Plaintext storage is insecure and fails the requirement for a secure deployment pipeline.

  • ✗

    Grant the service principal workspace admin rights so it can deploy any resource without encountering permission errors.

    Why it's wrong here

    Workspace admin is far broader than deployment requires and violates least privilege. If the credential is compromised, an admin service principal can alter or delete any workspace resource. A deployment identity needs only the permissions required to manage the specific jobs and pipelines in the bundle, so elevating to admin introduces unnecessary risk.

About these practice questions

Courseiva writes every Databricks-DE-Assoc question from scratch — 276 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

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.