Databricks Data Engineer Associate Implementing CI/CD: 82 practice questions

12 of the 82 Implementing CI/CD questions in the Certsqill Databricks Data Engineer Associate bank, shown in full below. Each one carries an explanation for every option, not just the correct one — the wrong answers are where the marks go.

Preparing for Databricks Data Engineer Associate? Take the free 5-min readiness check →

1. Create and use a feature branch in the Git folder: Which TWO actions satisfy those requirements?

Select two. More than one option is correct — every correct one is ticked below.

1. Commit directly to the production branch, then request review of the new commit.

   Directly committing to production integrates the change before the requested review gate and does not isolate development.
2. Create and use a feature branch in the Git folder for the change. ✓

   A feature branch isolates the support-analytics work from the production branch while it is developed and reviewed.
3. Open a pull request through the integrated Git provider workflow for reviewer approval. ✓

   A pull request supplies the required review step before the feature branch is integrated into the production branch.
4. Push the edited files to the remote repository and rely on the push for deployment approval.

   A push publishes commits but does not itself provide the required review or automatically deploy the change.
5. Create a separate Git folder for the change but keep it on the production branch.

   A separate workspace folder does not provide Git branch isolation from production, even if the files are stored separately.

Use a feature branch for isolation and a pull request for review before integration.

2. Validation checks bundle configuration: What explains the result and what should CI run next?

1. Validation checks business data quality; CI should run `databricks bundle run -t prod` to create resources.

   Validation does not prove data quality, and run executes an existing resource rather than deploying the bundle configuration.
2. Validation deploys only development resources; CI should change the target name before rerunning validation.

   The selected target controls configuration, but validate remains non-deploying for both development and production targets.
3. Validation checks bundle configuration; CI should run `databricks bundle deploy -t prod` to apply resources. ✓

   The validate command checks configuration only; deploy applies declared bundle resources to the selected target workspace.
4. Validation creates resources only after a job resource is manually started from the workspace.

   Validation does not stage resources for manual creation; deployment is the command that applies declared resources.

Validate checks configuration; deploy applies the declared production resources.

3. `databricks bundle validate -t test`: Which command should it use?

1. `databricks bundle destroy -t test`

   Destroy removes deployed resources and is unrelated to validating unresolved configuration or variable references.
2. `databricks bundle deploy -t test`

   Deploy applies bundle resources to the selected target, violating the requirement not to create resources.
3. `databricks bundle run -t test resource_key`

   Run executes a declared resource and therefore requires execution beyond the requested configuration-only check.
4. `databricks bundle validate -t test` ✓

   The validate command checks the selected target configuration without deploying or running the bundle resources.

Bundle validate checks the selected configuration without deploying or running resources.

4. A production value for `target_catalog`: What prerequisite is missing?

1. A production value for `target_catalog`. ✓

   The production target must resolve `target_catalog` from bundle configuration or a target-specific supplied value.
2. A successful development run that populates production settings.

   Running a development job does not automatically populate variables for the production target.
3. A workspace directory substituted for the catalog value.

   A workspace directory is not a catalog value and cannot satisfy the variable reference.
4. A Git commit that records the variable reference.

   Git history does not provide a value for an unresolved bundle variable.

Production needs a resolved `target_catalog` value.

5. Push the commit to the remote repository: Which action is required?

1. Pull from the remote repository to publish the local change.

   Pull retrieves remote commits; it does not publish the developer’s local commit to the remote repository.
2. Push the commit to the remote repository. ✓

   Pushing publishes the local commit to the remote repository, where configured CI can detect it.
3. Edit the workspace notebook after committing and wait for CI to detect it.

   Workspace edits are separate from the committed remote state and do not publish the tested local commit.
4. Create another local commit without publishing the existing commit.

   A second local commit remains unavailable to the remote repository and therefore cannot trigger configured remote CI.

Push publishes an existing local commit to the remote repository for CI visibility.

6. Declare both resources in a bundle and deploy the selected: Which approach is appropriate?

1. Run the source notebook from a Git folder and treat its execution as deployment.

   Executing source code does not declare or provision the required Job and pipeline resources across environments.
2. Create the resources manually in each workspace after copying the notebooks.

   Manual creation duplicates environment configuration and does not provide declarative promotion of both resources from one source.
3. Declare both resources in a bundle and deploy the selected target. ✓

   Bundles package declarative resources and environment configuration, allowing one source configuration to deploy both resource types per target.
4. Commit only the job definition and create the pipeline interactively in production.

   This splits resource management and leaves the pipeline outside the requested declarative, promotable configuration.

Declare both resources in a bundle and deploy the chosen environment target.

7. Use the prod target overrides and run `databricks bundle: Which implementation best satisfies that requirement

1. Use the prod target overrides and run `databricks bundle deploy -t prod`. ✓

   The prod target supplies environment-specific configuration, and deployment applies the same bundle source to that target.
2. Copy the business code into a separate production bundle and deploy without target overrides.

   Forking business code reduces source consistency and does not use target configuration for production-specific settings.
3. Push the Git branch and assume configured source publication deploys the production resources.

   A remote push publishes source, but deployment requires an explicit configured deployment step or automation.
4. Run `databricks bundle validate -t prod` and treat successful validation as deployment.

   Validation checks configuration but does not apply the production workspace resources or settings.

Deploy the shared bundle with the production target’s environment-specific overrides.

8. prod_catalog: What catalog value does the production run receive?

1. dev_catalog

   The default variable applies unless the selected target supplies an override; production explicitly supplies a different value.
2. ${var.catalog}

   Variable substitution resolves the expression before the resource runs, so the notebook receives the configured catalog value.
3. prod_catalog ✓

   The production target overrides the variable, and `${var.catalog}` resolves to that target-specific value during deployment.
4. support_job

   The resource key identifies the job, not the catalog variable passed through notebook task parameters.

The prod target overrides `catalog` with `prod_catalog`, which is substituted into the notebook parameters.

9. Run `git pull origin main`: Which TWO actions satisfy this workflow?

Select two. More than one option is correct — every correct one is ticked below.

1. Commit local edits and merge immediately, then pull remote main after the merge completes.

   This merges before incorporating and testing the current remote changes, reversing the required workflow order.
2. Use `.gitignore` to absorb conflicting supplier files, then push without changing tracked content.

   `.gitignore` controls untracked files and does not resolve conflicts in files already tracked by Git.
3. Push the branch and assume the remote provider automatically merges it because the commit was published.

   Pushing publishes commits but does not automatically complete approval or merge them through the provider workflow.
4. Run `git pull origin main`, resolve conflicts by reviewing both versions, test, commit, and push the branch. ✓

   Pulling from remote main incorporates the required changes; deliberate conflict resolution, testing, commit, and push produce a reviewable branch.
5. Fetch and integrate remote main, resolve conflicts, test, push the branch, and open a pull request. ✓

   This sequence synchronizes the branch, validates the result, publishes it, and submits it for provider review before merging.

Synchronize with main, resolve, test, publish, and request review.

10. Declare the wheel artifact and configure its build: Which TWO remediations address the failure?

Select two. More than one option is correct — every correct one is ticked below.

1. Declare the wheel artifact and configure its build to produce `./dist/telemetry.whl`. ✓

   The bundle declaration and build produce the wheel at the path required before deployment.
2. Rename the job resource to `telemetry.whl` without producing the referenced file.

   Renaming a resource does not create the wheel at `./dist/telemetry.whl`.
3. Build the wheel in CI before deployment and confirm its path matches the job reference. ✓

   CI creates the required artifact before deployment and verifies that its location matches the configured reference.
4. Reference `./telemetry` and let deployment package the source directory automatically.

   Referencing the source directory does not create the required wheel artifact before deployment.
5. Deploy with the missing reference and build the wheel during the first job run.

   Deployment cannot satisfy a missing artifact dependency through a later job execution.

Build the wheel before deployment and match its configured path.

11. `databricks bundle run -t dev product_metrics_job`: Which command should be used?

1. `databricks bundle run -t dev product_metrics_job --notebook`

   The extra unsupported notebook selection does not represent running the declared job resource through the required command.
2. `databricks bundle validate -t dev`

   Validation checks bundle configuration but does not execute the named job resource.
3. `databricks bundle deploy -t dev`

   Deployment applies declared resources but is not the command for running one resource.
4. `databricks bundle run -t dev product_metrics_job` ✓

   The `run` operation executes the specified resource using the `dev` target configuration.

Use `bundle run` with the development target and resource key.

12. Configure the production run identity and grant: What is the missing prerequisite?

1. Configure the production run identity and grant that identity the required workspace and data permissions. ✓

   The deployed resource must run as an authorized identity with permissions appropriate to its production workspace and data.
2. Run `databricks bundle validate -t prod` again and rely on validation to grant missing access.

   Validation checks configuration syntax and structure; it does not grant permissions to the production identity.
3. Create a second copy of the event-processing source code exclusively for production execution.

   Separate business-code copies do not grant the production identity access or ensure consistent deployment behavior.
4. Commit the production credentials into the bundle YAML so the job can authenticate automatically.

   Credentials must not be committed to source control; production access should use appropriate controlled authentication and grants.

Production needs a configured run identity with the permissions required by the deployed job.

Other Databricks Data Engineer Associate domains

• Data Transformation and Modeling — 180 questions →
• Data Ingestion and Loading — 172 questions →
• Working with Lakeflow Jobs — 129 questions →
• Governance and Security — 123 questions →
• Troubleshooting, Monitoring, and Optimization — 82 questions →
• All 817 Databricks Data Engineer Associate questions →
• Databricks Data Engineer Associate certification: requirements, cost and exam format →