Databricks enablement checklist
Account, workspace, fixture, identity, cost, and evidence prerequisites for live Fabric Experiments certification.
Use this checklist when preparing a Databricks environment for the complete Fabric Experiments workload matrix. Package support is not a live certification: each workload remains blocked until its workspace feature, fixture, restricted OAuth identity, assertions, and retained Quality evidence are available in the named environment.
Environment of record
The current Azure certification environment is:
- Databricks workspace:
tf-databricks - GitHub environment:
databricks-live - Authentication: OAuth machine-to-machine for CI; a developer session may be used for diagnostics but cannot produce release evidence
- Evidence: Quality Center plus the retained CI artifact for the exact candidate
AWS and Google Cloud require separate named workspaces, OAuth service principals, network and storage configuration, supported node types, and a complete run of the same required matrix. Private Link, customer-managed keys, custom egress, regional SKU restrictions, and customer-owned data or models remain separate topology certifications.
Account and workspace prerequisites
| Requirement | Owner or approval | Completion evidence |
|---|---|---|
| MLflow 3 production monitoring Beta/backend is enabled and healthy | Databricks account team or workspace admin | Built-in Safety scorer produces asynchronous feedback for a new trace within the bounded certification window |
| Unity Catalog Agent Services Beta is enabled | Databricks account team | A restricted customer-owned Harness agent can be registered, discovered, inspected, and granted EXECUTE |
| Genie Responses API and Agent Mode are enabled | Databricks account team | Responses API assertion passes in addition to the classic Genie conversation check |
| Knowledge Assistant, Supervisor Agent, and Responses APIs are usable by M2M | Workspace owner and Databricks account team if the APIs remain gated | The visible creation surfaces are backed by grounded Knowledge Assistant, multi-agent, and Responses assertions under the restricted principal |
| AI Runtime serverless GPU is available in a supported region | Databricks account team and cost owner | Training, evaluation, and exact Unity Catalog model assertions pass |
| Lakebase Autoscaling Online Feature Store and Feature Serving are enabled | Databricks account team | Online publication, serving, and freshness assertions pass |
| Marketplace provider and private exchange access is granted | Account admin, Marketplace admin, and legal/account owner | Marketplace admin role and provider profile exist; private listing, recipient, and governed asset assertions pass |
| Data Quality Monitoring baseline is complete | Workspace owner; Databricks builds the baseline | Latest freshness and completeness results are both Healthy; Training is not a pass |
Do not provision paid GPU or dedicated model capacity, accept Marketplace terms, or enter a provider agreement merely to make certification green. Those actions require an explicit cost or contract owner. Serverless AI Functions, MLflow evaluation, model inference, and AI Runtime training may also incur usage costs. Provisioned throughput is optional and requires separate approval.
Agent Services certification reflects the current Beta boundary: registration, discovery, metadata, and permissions. It does not claim runtime invocation until Databricks exposes and supports that API.
Observed workspace audit
The authenticated browser audit on July 20, 2026 confirmed that tf-databricks
already exposes:
- Knowledge Assistant, Supervisor Agent, custom agent, and Genie Agent creation;
- MCP registration, Databricks Apps-hosted MCP templates, and Marketplace MCP installation;
- Databricks Marketplace powered by OpenSharing; and
- the Marketplace provider console.
These visible surfaces remove the need to request basic UI enablement, but they do not replace API or M2M certification. The provider console specifically shows two unfinished provider prerequisites: an account admin must assign the Marketplace admin role, and that admin must create a provider profile. No role, provider profile, listing, paid capacity, or Marketplace agreement was created or accepted during the audit.
The GitHub databricks-live environment contained 19 secrets and 76 variables,
including the restricted OAuth identity and earlier live fixtures. None of the
new workload variables listed below was present. They must be added with real
fixture values after provisioning; placeholders are intentionally prohibited.
Live fixture variables
Configure these variables in the GitHub databricks-live environment only after
the corresponding durable Job or SQL assertion exists. Empty or synthetic values
do not satisfy readiness.
| Target pack | GitHub environment variables |
|---|---|
semantic-analytics | DBX_TEST_SEMANTIC_ANALYTICS_JOB_ID, DBX_TEST_METRIC_VIEW_ASSERTION_SQL, DBX_TEST_METRIC_MATERIALIZATION_ASSERTION_SQL, DBX_TEST_SQL_ALERT_ASSERTION_SQL, DBX_TEST_QUERY_PERFORMANCE_ASSERTION_SQL |
ai-functions-batch-inference | DBX_TEST_AI_FUNCTIONS_JOB_ID, DBX_TEST_AI_FUNCTIONS_OUTPUT_ASSERTION_SQL, DBX_TEST_BATCH_INFERENCE_QUALITY_ASSERTION_SQL, DBX_TEST_BATCH_INFERENCE_LINEAGE_ASSERTION_SQL |
agent-orchestration-responses | DBX_TEST_AGENT_ORCHESTRATION_JOB_ID, DBX_TEST_KNOWLEDGE_ASSISTANT_ASSERTION_SQL, DBX_TEST_MULTI_AGENT_ASSERTION_SQL, DBX_TEST_RESPONSES_API_ASSERTION_SQL, DBX_TEST_AGENT_GROUNDEDNESS_ASSERTION_SQL |
ai-runtime-training | DBX_TEST_AI_RUNTIME_JOB_ID, DBX_TEST_AI_RUNTIME_RUN_ASSERTION_SQL, DBX_TEST_AI_RUNTIME_EVAL_ASSERTION_SQL, DBX_TEST_AI_RUNTIME_MODEL_ASSERTION_SQL |
lakebase-autoscaling-features | DBX_TEST_ONLINE_FEATURE_STORE_JOB_ID, DBX_TEST_ONLINE_STORE_ASSERTION_SQL, DBX_TEST_FEATURE_SERVING_ASSERTION_SQL, DBX_TEST_ONLINE_FEATURE_FRESHNESS_ASSERTION_SQL |
declarative-bundles | DBX_TEST_BUNDLE_JOB_ID, DBX_TEST_BUNDLE_PROVENANCE_ASSERTION_SQL, DBX_TEST_BUNDLE_CANDIDATE_ASSERTION_SQL, DBX_TEST_BUNDLE_ROLLBACK_ASSERTION_SQL |
lakehouse-optimization | DBX_TEST_PREDICTIVE_OPTIMIZATION_ASSERTION_SQL, DBX_TEST_LIQUID_CLUSTERING_ASSERTION_SQL, DBX_TEST_ICEBERG_INTEROP_ASSERTION_SQL |
marketplace-open-sharing | DBX_TEST_MARKETPLACE_JOB_ID, DBX_TEST_MARKETPLACE_LISTING_ASSERTION_SQL, DBX_TEST_OPEN_SHARING_RECIPIENT_ASSERTION_SQL, DBX_TEST_MARKETPLACE_ASSET_ASSERTION_SQL |
The workflow already consumes these names. Keep credential material in GitHub environment secrets, never variables, logs, fixture output, or documentation.
Acceptance gate
For every target pack:
- Provision a deterministic, rerunnable fixture through the governed Databricks boundary and record its immutable Job ID or durable SQL assertion.
- Run
fx targets doctor <pack>and resolve every required diagnostic. - Run the pack live with the restricted OAuth M2M principal. A developer token
cannot satisfy the
restricted-principalcheck. - Require every Job and SQL assertion to pass; preview or unavailable features fail closed rather than becoming warnings.
- Publish Quality Center evidence and retain the CI artifact for the exact package and application candidate.
- Observe the staging environment for seven consecutive nights, regenerate evidence with M2M, and investigate any intermittent or freshness failure.
The release remains blocked while any required pack is workspace-gated, account-gated, baseline-gated, or awaiting live evidence. See the workload support matrix for the current status of every pack and certification evidence for evidence handling.