The Databricks Terraform Provider lets you declaratively manage Databricks resources — workspaces, clusters, jobs, Unity Catalog, networking, and more — using HashiCorp Terraform (HCL). Infrastructure as Code (IaC) eliminates manual operations and gives you reproducibility and auditability for every environment.
This article walks through the basic configuration of the Terraform Provider, a catalog of key resources, HCL examples, state management best practices, and how to split responsibilities between Terraform and DABs.
The Databricks Terraform Provider is an officially maintained HashiCorp Terraform plugin. It is published on the Terraform Registry and is declared inside an HCL file as shown below.
terraform {
required_providers {
databricks = {
source = "databricks/databricks"
version = "~> 1.40"
}
}
}
provider "databricks" {
host = var.databricks_host
token = var.databricks_token
}You can authenticate with a Personal Access Token (PAT), a service principal, an Azure Managed Identity, or an AWS IAM role. The standard for production is to use service principals and run from a CI/CD pipeline rather than relying on PATs.
| Category | Terraform Resource | What it manages |
|---|---|---|
| Workspace | databricks_mws_workspaces | Workspace creation (E2 architecture) |
| Cluster | databricks_cluster | All-Purpose Cluster definitions |
| Cluster Policy | databricks_cluster_policy | JSON definitions for cluster creation constraints |
| Instance Pool | databricks_instance_pool | Pre-allocated instance pools |
| Job | databricks_job | Workflow job definitions |
| Secret | databricks_secret_scope / databricks_secret | Secret scopes and secret values |
| Unity Catalog | databricks_catalog / databricks_schema / databricks_grants | Catalogs, schemas, and grants |
| External Location | databricks_external_location | External storage location definitions |
| Storage Credential | databricks_storage_credential | Credentials for cloud storage |
| Network | databricks_mws_networks / databricks_mws_private_access_settings | VPC / VNet configuration, Private Link |
| Groups & Users | databricks_group / databricks_user / databricks_service_principal | Identity management and service principals |
The example below is a baseline configuration that creates a Unity Catalog catalog and schema and defines a cluster policy.
resource "databricks_catalog" "analytics" {
name = "analytics"
comment = "分析チーム用カタログ"
}
resource "databricks_schema" "bronze" {
catalog_name = databricks_catalog.analytics.name
name = "bronze"
comment = "RAWデータ格納用スキーマ"
}
resource "databricks_grants" "bronze_grants" {
schema = databricks_schema.bronze.id
grant {
principal = "data-engineers"
privileges = ["USE_SCHEMA", "CREATE_TABLE", "SELECT"]
}
grant {
principal = "data-analysts"
privileges = ["USE_SCHEMA", "SELECT"]
}
}
resource "databricks_cluster_policy" "standard" {
name = "standard-policy"
definition = jsonencode({
"spark_version" : {
"type" : "regex",
"pattern" : "14\\.3\\.x-scala.*"
},
"num_workers" : {
"type" : "range",
"minValue" : 1,
"maxValue" : 8,
"defaultValue" : 2
},
"autotermination_minutes" : {
"type" : "range",
"minValue" : 10,
"maxValue" : 60,
"defaultValue" : 20
},
"custom_tags.CostCenter" : {
"type" : "fixed",
"value" : "analytics-team"
}
})
}
resource "databricks_secret_scope" "app_secrets" {
name = "app-secrets"
}The Terraform state file (terraform.tfstate) records the current state of every managed resource. For team development, follow these best practices.
| Requirement | AWS configuration | Azure configuration |
|---|---|---|
| State file storage | S3 bucket | Azure Storage Account (Blob) |
| Exclusive locking | DynamoDB | Blob Lease |
| Encryption | S3 SSE (AES-256 / KMS) | Azure Storage Service Encryption |
| Versioning | S3 versioning enabled | Blob Versioning enabled |
| Access control | Restricted via IAM policies | Restricted via Azure RBAC |
# AWSの場合のバックエンド設定
terraform {
backend "s3" {
bucket = "my-terraform-state"
key = "databricks/prod/terraform.tfstate"
region = "ap-northeast-1"
dynamodb_table = "terraform-locks"
encrypt = true
}
}There are two main approaches for managing per-environment differences in Terraform.
| Comparison item | Terraform | Databricks Asset Bundles |
|---|---|---|
| Sweet spot | Infrastructure base (workspaces, networking, UC, policies) | Application assets (jobs, DLT, notebooks, ML) |
| Definition language | HCL | YAML (databricks.yml) |
| State management | Explicit (tfstate + remote backend) | Implicit, managed on the Databricks workspace side |
| plan/preview | Preview diffs with terraform plan | Validate with databricks bundle validate |
| Multi-cloud | Can manage AWS / Azure / GCP resources alongside Databricks | Databricks assets only |
| Learning curve | Medium-to-high (HCL syntax + understanding state management) | Low (YAML + Databricks CLI) |
| Best fit for | Infrastructure / platform engineers | Data engineers / ML engineers |
Platform Admin / Data Engineer Professional
問題 1
A platform team wants to manage workspace creation, Unity Catalog metastore configuration, cluster policy definitions, and network setup (VPC Peering) as code, all in one pipeline. Which tool is the most appropriate?
正解: C
Workspace creation, UC metastore configuration, cluster policies, and network setup are all infrastructure-base concerns — Terraform's sweet spot. DABs specializes in application assets like jobs, DLT pipelines, and notebooks, and does not handle workspace creation or VPC Peering. Manual builds and JSON exports lack reproducibility and auditability.
How do I configure authentication for the Databricks Terraform Provider?
There are three main approaches: (1) set a Personal Access Token (PAT) via the DATABRICKS_TOKEN environment variable, (2) authenticate via an Azure AD / AWS IAM / GCP service account, or (3) use Databricks CLI profile authentication. For production, the recommended approach is service principals running from a CI/CD pipeline. Limit PATs to individual development use and always set a token expiration.
Where should the Terraform state file be stored?
Do not keep state on the local filesystem. Use a remote backend (AWS S3 + DynamoDB, Azure Storage Account + Blob, GCS, or Terraform Cloud). For team development, exclusive state locking is critical — enable it through DynamoDB (AWS) or Blob Lease (Azure). State files can contain secrets, so encryption is also mandatory.
Should I use Terraform or Databricks Asset Bundles (DABs)?
A two-layer split is recommended: manage the infrastructure base layer (workspace creation, UC metastore, cluster policies, network configuration, Secret Scopes) with Terraform, and the application layer (jobs, DLT pipelines, notebooks, ML models) with DABs. Terraform can manage jobs too, but DABs lets you describe them natively in databricks.yml and offers cleaner environment-target management.
Practice with certification-focused question sets
無料で問題を解いてみるNicheeLab Editorial Team
NicheeLab editorial team focused on data engineering and cloud certification learning. Content is structured around practical study needs and official exam domains.
Databricks Certifications: All 7 Exams, Difficulty & Study Plan (2026)
Complete guide to all 7 Databricks certifications — Data Eng...
Databricks Exam Difficulty Ranking: All 7 Certs Compared (2026)
Every Databricks certification ranked by difficulty, with st...
Databricks Study Guide: Fastest Pass Route & Time Estimates (2026)
How to pass Databricks certifications efficiently. Official ...
Databricks Data Engineer Associate: Complete Guide (2026)
Domain-by-domain breakdown of the Databricks Certified Data ...
Databricks Data Engineer Professional: Complete Guide (2026)
Tactics for the Databricks Certified Data Engineer Professio...