Articles · Databricks
Databricks Asset Bundles Interview Questions: Targets, Deployment State, and Existing Jobs
Answer Databricks Asset Bundles interview questions with target selection, deployment-state identity, existing-job binding, and deploy versus run evidence.
A bundle deploy succeeds, but a second job appears beside the production job you expected to update. Both jobs have the same display name. The deployment is green, but you now have two jobs to reconcile. For Databricks Asset Bundles interview questions, the useful answer starts with the selected target, deployment state, and tracked job ID.
Official fact: Databricks now calls the feature Declarative Automation Bundles, formerly Databricks Asset Bundles. Bundles describe resources alongside project code so teams can review and deploy them together. This guide uses current AWS documentation and original inspection exercises; it does not present these questions as a reported Databricks hiring round. Databricks bundles overview
Here, the central distinction is between a resource definition and the remote job ID that a deployment manages.
What does a bundle target actually select?
A target is a named deployment configuration inside the bundle. It can supply environment-specific settings such as workspace location, variable values, resource overrides, and run identity. Selecting a target answers “which configuration am I resolving?” It does not establish that the deployed workload has produced correct data.
Official fact: The root databricks.yml defines the bundle and can include additional configuration files. Target settings override applicable shared settings, and one target can be marked as the default. A target called prod is a name; production behavior requires the corresponding configuration. Bundle configuration
When shown a YAML file, read the common resource first, then the selected target. Ask which settings come from the shared definition and which change for this environment. Name the resolved workspace, catalog parameter, logical resource key, and identity, instead of treating all appearances of “production” as interchangeable.
Consider a developer who validated dev and then let a separate automation step deploy without specifying a target. In an interview, identify that missing selection before diagnosing networking or Spark. Your first evidence request should be the actual command and its resolved configuration.
Inspect an original two-target configuration
The following is an original configuration inspection exercise, not a complete deployable project. Workspace hosts and the production service-principal identifier are placeholders. The referenced notebook, compute choice, authentication, and permissions must be configured for an actual workspace.
bundle:
name: interview_orders
variables:
catalog:
description: Catalog passed to the notebook
resources:
jobs:
orders_daily:
name: orders_daily
tasks:
- task_key: check_orders
notebook_task:
notebook_path: ./src/check_orders.ipynb
base_parameters:
catalog: ${var.catalog}
targets:
dev:
default: true
mode: development
variables:
catalog: interview_dev
workspace:
host: https://<dev-workspace-host>
prod:
mode: production
variables:
catalog: interview_prod
workspace:
host: https://<prod-workspace-host>
root_path: /Workspace/Shared/.bundle/${bundle.name}/${bundle.target}
run_as:
service_principal_name: <production-application-id>
Official fact: Custom variables use ${var.name} substitutions, and bundle substitutions can incorporate the bundle name and target into workspace paths. These values are configuration inputs, not proof that a notebook actually honors its catalog parameter. Substitutions and variables
For prod, predict interview_prod and the path ending in interview_orders/prod. For dev, predict interview_dev and the development workspace. The resource key remains orders_daily in both targets. The YAML does not contain an existing production job ID.
That last observation explains why copying this configuration cannot, by itself, adopt a manually created job. It also gives you a specific follow-up: show where the target's state maps orders_daily to its remote counterpart.
Separate validation, deployment, and execution
Official fact: The bundle lifecycle includes validating configuration, deploying it, and running a workflow. These commands perform different jobs. Validation does not execute the workload, so a validation result alone cannot establish a successful run. Bundle lifecycle overview
After configuring a disposable practice workspace, inspect the target before considering the deployment and run steps:
databricks bundle validate -t dev
databricks bundle deploy -t dev
databricks bundle run -t dev orders_daily
No CLI execution is claimed for this article. These commands show the distinction you should explain aloud: inspect the resolved definition, apply the deployment, then execute the chosen resource.
In the original exercise, a notebook could accept catalog but accidentally build an unqualified table name. Configuration validation would not be sufficient evidence that the intended catalog received the output. Your answer should therefore separate configuration observations from execution observations and business-result checks.
Ask for three artifacts: resolved configuration, the deployed job definition and ID, and the run's output evidence. If only the first is available, say what remains unknown. If a run is green, still compare output grain, row counts, and rejected records with the input contract.
Why does a matching job name not establish identity?
Deployment state is the record that associates bundle-managed resources with remote resource IDs. It lets a deployment identify the object it should manage rather than guessing from a human-readable name.
Official fact: Databricks documents root_path as fundamental to a bundle deployment's identity. The default path incorporates the deployer, bundle name, and target. Deployment state tracks resources by ID; display names are not the correlation key. CLI bundle target and identity
Use this original ledger to discuss the duplicate-job scenario. The IDs are synthetic.
| Observation | Evidence to inspect | Explanation to defend |
|---|---|---|
| Existing production job is named orders_daily, ID 900 | Production job details | A name match alone supplies no binding |
| New prod deployment has no tracked association | Selected workspace and deployment state | Do not assume it will discover job 900 |
| Resource orders_daily is bound to job 900 for prod | Binding result and selected target | Review what the next deployment will change |
| A later deployment uses another root path | Resolved path and prior deployment records | Investigate whether deployment identity changed |
A useful hypothesis is that the automation ran under a different deployer and inherited a different default path. Another is that the workspace or target changed. These are diagnostic inferences, not conclusions from the duplicate name alone.
Compare the previous and current command, workspace, root path, and resource mapping. If those match, inspect deployment logs and the actual remote job IDs. If they differ, explain which difference could have changed the managed resource association.
How do you adopt an existing job deliberately?
Official fact: Databricks supports generating bundle configuration from an existing job, then binding a bundle resource to the corresponding remote job. Its migration guide explicitly addresses existing development and production jobs with different IDs. Migrate existing resources
For the synthetic production job, distinguish the two operations:
databricks bundle generate job --existing-job-id 900 --target prod
databricks bundle deployment bind orders_daily 900 --target prod
Inspect the generated file before using the second command. The binding key must match the resource key actually defined in your configuration; orders_daily is the key in our exercise. Generation can produce a different key, so do not copy this line blindly.
Official fact: Binding connects the local resource definition to an existing remote resource. The next deployment applies bundle-defined changes to that resource. The CLI offers a binding diff and confirmation; inspect the remote resource before confirming. Bundle deployment bind
In an interview, name the fields you would compare: task definitions, referenced notebooks, schedule, parameters, run identity, and resource permissions. An exported configuration is a starting point for review, so compare it with production requirements before allowing it to manage the existing job. It does not resolve differences between development and production automatically.
If production job 900 has a different schedule from the development job, preserve that requirement in the production target. Then ask whether deploying the reviewed definition would change the production job in the intended way.
Development mode and production mode need inspection
Official fact: Development mode applies defaults such as development prefixes and paused schedules; these defaults can be customized. Production mode includes additional checks, and Databricks recommends service principals for production. Individual resource settings can override applicable presets. Deployment modes
For the exercise, do not infer the final schedule merely from mode: development. Inspect whether the job explicitly overrides the pause setting. Likewise, mode: production does not establish a successful data-quality check or an approved business release.
Suppose the interviewer adds an explicit unpaused development schedule. Your answer should change: the deployment could now trigger work under the resolved configuration. Identify the override and ask whether the development catalog, compute, and notification recipients are suitable for that behavior.
A further follow-up might change the production path to a developer's personal folder. Explain why team ownership, repeatable identity, and access need review. Treat the configuration as a set of concrete choices with consequences, rather than as a ceremonial environment label.
Who deploys the bundle, and who runs the job?
Official fact: run_as can separate the identity deploying a bundle from the identity running its workflows. Current documentation describes support restrictions when those identities differ. It also notes that run_as is not supported for model serving endpoints. Specify a run identity
For our job-only exercise, draw two permission questions. Can the deployment identity manage the resource and referenced artifacts? Can the configured runtime identity read the input and write the intended catalog?
Changing run_as does not answer the deployment question. Changing the deployment credential does not demonstrate that the job can access its data. A failure before resource creation and a failure inside a notebook call for different evidence.
Now vary the exercise: the notebook reads successfully but cannot write its destination. Explain why replacing the YAML resource name is irrelevant to that symptom. Inspect the actual runtime identity, the resolved destination, and the required data permissions before proposing a targeted change.
A deployment rollback needs a resource review
Original reasoning: If a bad release changed both notebook code and a job schedule, restoring only the code would not restore the entire intended behavior. Compare the resource configuration and artifacts with the last approved version, then examine what the proposed deployment would change.
Also separate deployment rollback from data repair. If a run already wrote duplicate records, restoring a configuration cannot prove those records disappeared. Preserve the run history and reconcile the affected output before resuming scheduled processing.
For adoption, keep a record of the original job ID and reviewed configuration. After a change, inspect that same ID and verify the selected target. Your explanation should identify what was changed, what was observed afterward, and which business effects still require investigation.
This discussion fits bundle deployment intent. Task repair and retry behavior deserve their own analysis; use the original resource's run history instead of assuming that redeploying fixes every execution failure.
Five questions for deployment reasoning
| Question | Follow-up to rehearse |
|---|---|
| Design a CI/CD pipeline with scheduler | Separate configuration, deployment and execution evidence. |
| Design a Dependency-Aware CI/CD Pipeline | Describe target-specific resources and the release dependencies. |
| Discuss an Interesting Project and a Deployment Mistake | Explain the wrong target or identity and the evidence that exposed it. |
| Diagnose data quality and pipeline performance issues | Verify the intended data destination after the deployed job runs. |
| Forward Deployed Engineer Screen: Role Fit, Client Work and Databricks Projects | Discuss Databricks project ownership; this record concerns an FDE screen. |
Rehearse the duplicate-job case before memorizing more commands. Start with the selected target and remote workspace, inspect the root path and tracked ID, then decide whether you need configuration changes or deliberate adoption.
For each practice answer, add a changed assumption: another deployer, a production-specific schedule, a new runtime identity, or an already-written output. Explain how that assumption changes the evidence you request.