Data-Engineer-Associate - Implementing CI/CD (10% of the exam) - Section 5.4

Understand the Databricks CLI to validate, deploy and manage bundles and other workspace assets in automated CI/CD workflows.

Use the Databricks CLI bundle commands to validate, deploy, run and destroy a bundle from a CI/CD pipeline, authenticating with a service principal. Order the steps a pipeline runs and place validation before deployment.

Databricks CLIbundle validatebundle deployservice principalsCI/CD pipeline

Practice question for this objective

Free sampleImplementing CI/CDmedium

A continuous integration pipeline deploys a bundle to the prod target on every merge, using a service principal's credentials, and the deployed nightly job currently executes under whichever identity performed the deployment. Governance requires the job itself to execute under a named service principal, declared in the bundle so that it survives every future deployment. Which change to the bundle meets the requirement?

targets:
  prod:
    mode: production
    workspace:
      host: acme-prod.cloud.databricks.com

AAdd a permissions block to the prod target granting CAN_MANAGE on the job to the service principal, so that it becomes the identity the job executes under.
BRely on mode: production in the prod target, since that mode makes every deployed job execute under a service principal rather than a user.
CChange the job's run as identity in the workspace user interface after the deployment finishes, and record the value in the team's runbook.
DAdd a run_as block to the prod target naming the service principal, so the deployed job executes under that identity on every deployment. Correct

Declare run_as in a bundle target so a deployed job executes under a named service principal on every deployment. A bundle deployment reconciles the workspace resource with the declared configuration, so any execution identity that is not written into the bundle is replaced at the next deploy. The run_as block is the declaration that pins the identity, while permissions governs access to the resource and production mode governs naming, schedules and validation rather than the principal that runs the tasks.

Why A is wrong: Tempting because permissions is a real bundle key and the service principal does need access, but it controls who may view, manage or run the resource; the identity the tasks execute under is a separate setting and stays unchanged.

Why B is wrong: Tempting because production mode does tighten behaviour, keeping schedules active and names unprefixed, but it does not choose an execution identity by itself; it validates the configuration rather than supplying the principal.

Why C is wrong: Tempting because the interface does expose that setting and the change works immediately, but the bundle is the source of truth for the deployed job, so the next deployment overwrites the manual edit and the requirement fails silently.

Why D is correct: Correct: run_as sets the identity that the deployed resources execute under, and placing it in the prod target means each deployment of that target reasserts the service principal without any manual step.

See more Data-Engineer-Associate practice questions, answers explained.

Exam traps in Implementing CI/CD

Answers that look right on this material and are not. Each one is a distractor from a different question in the Data-Engineer-Associate bank for this domain.

Write the dev identifier as the variable default, deploy both targets from it, and have an operator edit the job in the prod workspace user interface afterwards so it points at the prod warehouse.
Why it is wrong: It is tempting because it needs no extra bundle syntax, but a hand edit in the target workspace is undone by the next deployment and leaves prod differing from the codebase that is supposed to define it.
Store a personal access token belonging to the engineer who built the pipeline in the runner's secret store, and export it as DATABRICKS_TOKEN before the deploy step.
Why it is wrong: It authenticates the command line interface without a prompt, which is why teams reach for it, but the deployment then depends on one employee's account and breaks when that person leaves.
Run the CLI login command as the first step of the pipeline so the CLI opens an OAuth session for the service principal before the deployment step runs.
Why it is wrong: Tempting because that login command is the usual way an engineer authenticates a laptop, but it expects a browser and a person to complete the consent, so it cannot finish on a headless runner.

Examworthy is not affiliated with or endorsed by Databricks. Original, blueprint-aligned practice material only.