Question 84

Your organization deploys Databricks Asset Bundles from a GitHub Actions CI pipeline. On every merge to `main`, the pipeline must authenticate non-interactively to the Azure Databricks workspace, validate the bundle, and deploy it to the `prod` target. A draft workflow uses the Databricks-provided `databricks/setup-cli` action and then runs `bundle` commands. ```yaml jobs: deploy: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: databricks/setup-cli@main - run: databricks bundle validate -t prod env: DATABRICKS_TOKEN: ${{ secrets.SP_TOKEN }} - run: databricks bundle deploy -t prod env: DATABRICKS_TOKEN: ${{ secrets.SP_TOKEN }} ``` Which TWO statements describe Databricks-recommended practices for this CI deployment? (Choose TWO.)

• AThe pipeline should authenticate as a Databricks service principal (for example, using an OAuth machine-to-machine token or workload identity federation) rather than an interactive user, so that automated deploys do not depend on a human's credentials.
• BYou should run `databricks bundle validate` before `databricks bundle deploy` so that misconfigurations in `databricks.yml` are caught early in the pipeline, before any resources are created in the workspace.
• CService principals cannot be used for automated bundle deployment; the workflow must store a personal access token belonging to a workspace admin in `secrets.SP_TOKEN`.
• DBecause bundles are declarative, you must edit each job and pipeline manually in the workspace UI after deployment to point it at the production cluster; the bundle cannot set environment-specific values.
• EWorkload identity federation is discouraged for CI/CD because it requires storing a long-lived Databricks secret in the repository, which is less secure than a static token.