Build the Databricks Network Connectivity Configuration, private endpoint rules and workspace binding that let a serverless SQL warehouse reach Azure Data Lake Gen2 over a private path.
Create NCC
mws_network_connectivity_config
Create blob + dfs rules
mws_ncc_private_endpoint_rule
Bind workspace
mws_ncc_binding
Approve on Azure resource
Private endpoint connection becomes usable
Terraform creates the Databricks-side intent. The Azure resource owner still controls private endpoint approval.
What this guide builds
The target is deliberately narrow: a Databricks serverless SQL warehouse must query data stored in an Azure Data Lake Gen2 account whose public network access is restricted.
This guide automates the Databricks account objects that establish that path. It does not replace inbound Private Link, classic-compute VNet design or Unity Catalog permissions.
Need the architecture decision first? Read Private Link vs NCCScope of this implementation
Serverless SQL
Databricks-managed serverless compute plane
ADLS Gen2
Customer-owned Azure Storage
Runtime path
Serverless compute does not run inside your VNet-injected classic compute subnets. Private outbound access to customer-owned Azure resources is therefore configured through a Network Connectivity Configuration.
Serverless SQL private data path
This is outbound connectivity from Databricks to your Azure resource.
Compute
Serverless SQL warehouse
Runs in the Azure Databricks serverless compute plane.
Network control
NCC + private endpoint rule
Account-level configuration attached to the workspace.
Destination
Azure Data Lake Gen2
Private endpoint connection approved on the storage account.
Not inbound Private Link
User-to-workspace access is a different network path.
Not VNet injection
That pattern belongs to classic compute networking.
Still needs data authorization
Private transport does not grant Unity Catalog or Azure storage permissions.
Terraform resources
All three resources are account-level. The NCC and workspace must be in the same Azure region, and a workspace can be bound to only one NCC at a time.
If a workspace needs multiple private destinations, put the endpoint rules in the same NCC instead of trying to bind multiple NCCs.
databricks_mws_network_connectivity_config
Creates the regional NCC
The container for serverless egress rules.
databricks_mws_ncc_private_endpoint_rule
Requests a private endpoint
Targets an Azure resource ID and subresource such as blob or dfs.
databricks_mws_ncc_binding
Attaches the NCC to the workspace
Makes the NCC configuration available to serverless workloads in that workspace.
Requirements
Most failed implementations are not HCL problems. They are mismatches between the Databricks account boundary, workspace region, Azure resource permissions and endpoint approval ownership.
Outbound Private Link for serverless compute requires the Premium plan.
NCCs and private endpoint rules are managed at the Databricks account level.
The NCC must match the Azure region of the workspace it is attached to.
The target resource owner must approve the pending private endpoint connection.
Dependency graph
Create the regional NCC first. Endpoint rules reference that NCC and the Azure Storage resource. The workspace binding references the NCC. Resource-side approval is the final gate before the private endpoint rule becomes usable.
Terraform reference edges already create most of the ordering. Use explicit dependencies only where the external approval workflow needs them.
NCC
regional object
endpoint rules
blob + dfs
workspace binding
same region
Azure approval
PENDING → ESTABLISHED
Provider setup
NCC resources are not workspace resources. Configure a Databricks provider alias for the account console and use that alias on all three NCC resources.
Host: https://accounts.azuredatabricks.net
Account ID: your Azure Databricks account identifier
Authentication: use Databricks unified authentication appropriate for local or CI execution
terraform {
required_providers {
azurerm = {
source = "hashicorp/azurerm"
}
databricks = {
source = "databricks/databricks"
}
}
}
provider "azurerm" {
features {}
}
provider "databricks" {
alias = "accounts"
host = "https://accounts.azuredatabricks.net"
account_id = var.databricks_account_id
}
variable "databricks_account_id" { type = string }
variable "location" { type = string }
variable "workspace_id" { type = number }Implementation
The resource names below preserve the three Databricks account resources used by the existing implementation. Replace the example resource references with your own workspace and storage resources.
The NCC is regional. Use the same region as the workspace that will consume it.
resource "databricks_mws_network_connectivity_config" "ffa_titan_ncc" {
provider = databricks.accounts
name = "ffa-titan-ncc"
region = var.location
}For this ADLS Gen2 implementation we create separate rules for the blob and dfs subresources.
resource "databricks_mws_ncc_private_endpoint_rule" "blob" {
provider = databricks.accounts
network_connectivity_config_id =
databricks_mws_network_connectivity_config.ffa_titan_ncc.network_connectivity_config_id
resource_id = azurerm_storage_account.ffa_titan_adls_gen2.id
group_id = "blob"
}resource "databricks_mws_ncc_private_endpoint_rule" "dfs" {
provider = databricks.accounts
network_connectivity_config_id =
databricks_mws_network_connectivity_config.ffa_titan_ncc.network_connectivity_config_id
resource_id = azurerm_storage_account.ffa_titan_adls_gen2.id
group_id = "dfs"
}The Azure resource owner must still approve the private endpoint connections. Creating the rules alone does not make them usable.
A workspace can have one active NCC binding. Add all required private endpoint rules to that NCC.
resource "databricks_mws_ncc_binding" "ffa_titan_ncc_binding" {
provider = databricks.accounts
network_connectivity_config_id =
databricks_mws_network_connectivity_config.ffa_titan_ncc.network_connectivity_config_id
workspace_id = var.workspace_id
}Approval happens on the target Azure resource. In CI/CD, run this with an Azure identity that has only the permissions required to approve private endpoint connections.
resource "terraform_data" "approve_storage_private_endpoints" {
triggers_replace = [
databricks_mws_ncc_private_endpoint_rule.blob.rule_id,
databricks_mws_ncc_private_endpoint_rule.dfs.rule_id
]
provisioner "local-exec" {
interpreter = ["bash", "-c"]
command = <<-EOT
for id in $(az network private-endpoint-connection list \
--id "${azurerm_storage_account.ffa_titan_adls_gen2.id}" \
--query "[?properties.privateLinkServiceConnectionState.status=='Pending'].id" \
-o tsv); do
az network private-endpoint-connection approve \
--id "$id" \
--description "Approved by FFA Titan Terraform"
done
EOT
}
}Approval lifecycle
Creating a private endpoint rule sends a request to the target Azure resource. Until that request is approved, the Databricks rule cannot carry production traffic.
Rules that remain PENDING, REJECTED or DISCONNECTED can expire after 14 days, so approval and validation should be part of the deployment workflow.
Databricks provisions the endpoint request.
Waiting for Azure resource approval.
Private endpoint is ready for serverless use.
Databricks states that most private endpoint rule changes propagate within 10 minutes, but they can take up to 24 hours to fully apply. Restart running serverless services after changing the workspace NCC attachment.
Validation
A successful Terraform apply is only one checkpoint. Prove that the endpoint is established, the NCC is attached to the intended workspace and the serverless SQL warehouse can read the governed data path.
Validation sequence
Terraform state
NCC, blob rule, dfs rule and workspace binding exist.
Endpoint state
Private endpoint rules report ESTABLISHED.
Workspace attachment
The expected NCC is attached to the same-region workspace.
Serverless query
Run the real SQL query against the Unity Catalog object backed by ADLS Gen2.
Public-path test
Confirm the storage security posture still blocks paths that should not be public.
Expected outcome
Network
Serverless traffic reaches the storage account through the approved private endpoint.
Identity
Azure storage authorization remains separate from the private network path.
Governance
Unity Catalog permissions still determine who can query the external data.
Common mistakes
Avoid
Using a workspace-level provider for NCC resources
Better default
Use an account-level Databricks provider alias
Avoid
Assuming endpoint creation equals approval
Better default
Wait for ESTABLISHED before validating SQL
Avoid
Binding multiple NCCs to one workspace
Better default
Put all required private endpoint rules in one NCC
Avoid
Treating private networking as data authorization
Better default
Validate Azure RBAC and Unity Catalog separately
Avoid
Hard-coding credentials in local-exec
Better default
Run approval with your authenticated CI identity and least privilege
Avoid
Testing only from classic compute
Better default
Test from the serverless SQL workload this NCC is designed for
How Food For Analytics implements it
In Titan, the NCC, destination rules and workspace attachment are managed as infrastructure code alongside the Azure resource boundary. Validation is performed from the serverless workload that will use the connection.
Explore TitanTitan network deployment
01
Declare
NCC, rules and binding in Terraform.
02
Approve
Controlled Azure resource-side approval.
03
Prove
End-to-end serverless query validation.
FAQ
Practical answers about Network Connectivity Configuration, Terraform, private endpoint rules and Serverless SQL access to Azure Data Lake Gen2.
An NCC is an account-level regional configuration that manages serverless network connectivity, including private endpoint rules. An NCC can be attached to multiple workspaces in the same region, but each workspace can have only one active NCC binding.
The core Databricks account resources are databricks_mws_network_connectivity_config, databricks_mws_ncc_private_endpoint_rule and databricks_mws_ncc_binding.
Use an account-level Databricks provider. For Azure, the account console host is https://accounts.azuredatabricks.net and the provider must know the Databricks account ID.
It creates a private endpoint rule inside an NCC for a target resource. On Azure you provide the target Azure resource ID and the relevant subresource group ID, such as blob or dfs for Azure Storage.
No. A workspace can have one active NCC binding. If the workspace needs several private destinations, add the required private endpoint rules to the same NCC.
No. The target Azure resource owner must approve the private endpoint connection. The Databricks private endpoint rule becomes usable when its connection state is ESTABLISHED.
This implementation creates separate private endpoint rules for the blob and dfs Azure Storage subresources. Confirm the exact subresources required by your workload before standardizing the pattern.
Databricks documentation advises waiting about 10 minutes after attaching an NCC to a workspace and restarting running serverless services. Private endpoint rule changes usually propagate quickly, but full propagation can take longer.
No. VNet Injection is a classic compute networking pattern. NCC controls outbound connectivity from the Azure Databricks serverless compute plane to customer resources.
No. Network reachability, Azure resource authorization and Unity Catalog privileges are separate controls. An ESTABLISHED endpoint does not grant storage or catalog permissions.
Current Azure Databricks documentation lists up to 10 NCCs per region per account, 100 private endpoints per region across those NCCs and up to 50 workspace attachments per NCC.
Need implementation support?
We can review the NCC design, Terraform graph, Azure approval flow and the surrounding Unity Catalog and storage permissions.
Implementation review