Databricks Landing Zone Azure: What Must Be Ready Before Launch
Week 3, Thursday: The first use case is defined, and the project team is in place. Now cloud architecture and IT security need to know whether the platform is ready to launch. For your Databricks Landing Zone Azure setup, a provisioned workspace is not enough. Identities, network access, storage connections and environment boundaries must work demonstrably, and the configuration must be reproducible. This article provides a technical approval checklist, not a vendor comparison.
In short: A Databricks landing zone on Azure is ready when identities, network paths, data access and environment boundaries have been implemented and tested for the chosen architecture. Infrastructure as Code, audit evidence and named operational owners make these foundations verifiable. An accessible workspace alone does not constitute technical approval.
What belongs in a Databricks Landing Zone Azure setup?
A Databricks landing zone on Azure comprises the cloud and governance foundations needed to operate Azure Databricks securely. It connects the enterprise Azure landing zone with the requirements of specific Databricks workloads.
This includes subscriptions and resource groups, identities, networks, storage, policies and operational processes. A workspace is one component, not the entire landing zone. Before the review, define what you are approving: a development environment using test data, or production processing of sensitive information.
Decide on compute before approving the network
Distinguish between classic compute and serverless compute. Classic compute may require VNet Injection, subnets and egress controls. Serverless compute uses different networking mechanisms; requirements and available features need separate verification for the region and workload. Approval of a classic network topology therefore does not automatically cover serverless.
How do you verify identities and permissions before launch?
Identity approval requires separate human and workload identities, central management and least-privilege access. Successful sign-in is only part of the test: access revocation must also work demonstrably.
Microsoft Entra ID provides the foundation for enterprise identities. Define how users and groups are provisioned into Databricks, for example through a supported provisioning mechanism such as SCIM. Avoid individual permission assignments where groups can represent the required roles.
Check the following:
- Administrative roles: Who manages Azure resources, the Databricks account, workspaces and Unity Catalog?
- Workload identities: Which service principals run deployments and jobs? Which authentication methods are supported and used?
- Lifecycle: How do onboarding, role changes and departures affect existing access?
- Emergency access: Who can use it, and how is its use logged and reviewed?
Evidence should include a role matrix and tests using representative identities. Include a negative test: once a permission has been revoked, the previously permitted access must no longer succeed.
Which network connections need approval?
Network approval must cover every required connection and effectively prevent unwanted access. Reaching the workspace in a browser proves neither connectivity to data sources nor control over outbound traffic.
Document the paths connecting users, the workspace, compute, storage and other data sources. Include DNS resolution, routing, firewall rules and required connections to platform services and package repositories.
Private Link does not replace end-to-end testing
Azure Private Link can provide private connectivity for specific connections. Whether public endpoints can be disabled, and which additional settings are needed, depends on the connection path and architecture. Private endpoints without the appropriate DNS configuration do not establish working private access.
Approval requires:
- a positive test from the intended corporate network or compute environment;
- a negative test from an unauthorized network;
- a documented egress test for external destinations;
- verification of DNS resolution from the relevant execution environments.
Test using the actual compute type. Successful access from an administrator’s laptop does not replace a job-level test.
How do you connect Azure Storage securely to Databricks?
A secure storage connection requires both an authorized network path and appropriate data permissions. Unity Catalog governs access within Databricks, while Azure permissions and storage network rules remain relevant additional controls.
For Azure Data Lake Storage Gen2, one option is an Azure Databricks Access Connector with a managed identity. Corresponding storage credentials and external locations are configured in Unity Catalog. Azure roles and, where applicable, ACLs must support the intended access without exposing unnecessarily broad data areas.
Verify each layer separately:
- Identity: Which managed identity accesses which storage area?
- Governance: Who can use or manage storage credentials, external locations, tables and volumes?
- Network: Can the selected compute actually reach the storage?
- Boundaries: Does access to unauthorized containers or paths fail?
Personal credentials and widely shared storage keys are not a sustainable default connection model. In particular, avoid making production jobs permanently dependent on an individual employee’s permissions.
How do you separate environments and secure Infrastructure as Code?
Development, test and production need verifiable boundaries for data, permissions and changes. Infrastructure as Code makes those boundaries reproducible, but it replaces neither a security design nor deployment approval.
The required separation depends on the sensitivity and criticality of the workload. Separate workspaces may be appropriate; additional boundaries across subscriptions, networks and storage can reduce the potential impact of an incident. A shared Unity Catalog metastore does not inherently mean weak separation, but requires carefully configured permissions and, where appropriate, workspace bindings.
Reproducible, not merely documented
Manage the intended resources and policies with suitable tools such as Terraform or Bicep. Check their supported scope: Azure resources and Databricks configurations are not necessarily managed through the same interface.
Before approval, establish code reviews, protected deployment identities, secure state storage, secret management and a controlled process for manual changes. Redeployment must be able to produce the expected configuration. Document how failed changes will be corrected as well.
Introducing Databricks in your company: Which prerequisites are still missing?
Any prerequisite without reliable test evidence or a named owner remains unresolved. The launch decision should therefore rest on verifiable acceptance criteria, not a status update saying “workspace created.”
Use this checklist in a joint review with cloud architecture, IT security and the platform team:
| Review area | Required evidence | Launch blocker |
|---|---|---|
| Identities | Role matrix, tested sign-in and access revocation | Unclear administrative rights or shared personal credentials |
| Network | Approved paths, DNS and egress tests | Unresolved public exposure or uncontrolled egress |
| Storage | Read, write and negative tests for each intended role | Excessive permissions or unclear data access |
| Environments | Tested separation of data and deployment permissions | Development can change production without appropriate controls |
| Infrastructure as Code | Version-controlled code and verified deployment | Critical configuration exists only as manual changes |
| Operations | Ownership, audit logs, alerting and cost accountability | No designated owner for security events |
Not every open task blocks every launch. A documented exception may be acceptable for a limited test environment if data sensitivity, compensating controls, ownership and an expiry date are explicit. Production data remains subject to the agreed approval criteria; a pilot must not silently replace them.
How we approach the review
At Ailio, based in Bielefeld and Hamburg, we structure the architecture review around actual access paths and the intended operating model. The findings should give your team a clear basis for its launch decision.
- Define the approval scope: We clarify the workload, data classification, compute type and environments involved.
- Review configuration and evidence: Together, we examine architecture, roles, network rules, storage connections and Infrastructure as Code.
- Test critical paths: We verify permitted and prohibited access using the intended identities and execution environments.
- Prioritize gaps: The result is a list of launch blockers, corrective actions, owners and required retests.
This turns a broad security discussion into a concrete technical decision. Implementation can then focus on the prerequisites that are actually missing.
Ready for technical launch approval?
You do not need every future platform capability in place before launch. But the security foundations must meet your defined approval scope. With our Databricks consulting, you can review the architecture, prioritize outstanding issues and prepare for implementation on Azure.