Microsoft's October 22, 2026 Azure Databricks walkthrough explains Private Network Gateway, currently in public preview. It creates a managed path from serverless compute into a delegated subnet, configured through a Network Connectivity Configuration, or NCC. The aim is to reach private resources without assembling separate gateway infrastructure for each destination. Microsoft's overview.
For a platform engineer, the acceptance question is specific: which route did a connection take, and which control made that destination reachable?
Keep the Preview's Boundaries Visible
The product documentation requires the Premium plan and places the gateway subnet in the same region as the NCC. It describes the gateway as complementary to Private Link, not a replacement.
My proposed pilot would start with one approved workspace, one private test service, and a named network owner. Record the preview decision and the exact workload being evaluated before extending the pattern to additional applications.
Choose a destination where a harmless request has a clear expected response. Avoid using a successful production transaction as the first proof that the network design works.
All Traffic Does Not Override Every Other Path
Microsoft documents routing precedence: matching private endpoint rules and service endpoints come before the gateway. ALL_TRAFFIC therefore handles remaining egress, not traffic already selected by those higher-priority paths. Blob storage uses the Azure service-endpoint path and cannot be redirected through the gateway. Routing behavior.
I would turn that into a small route inventory. For each representative destination, record its expected path, the control responsible, and the observation that would confirm it.
Include a private service, a resource with an existing private endpoint rule, and an approved external destination if the pilot needs internet access. Do not infer the behavior of all three from one successful connection.
Distinguish Routing from Egress Permission
The documentation also distinguishes policy behavior between modes. Configured SPECIFIC_DESTINATIONS are automatically allowed in serverless egress control. In ALL_TRAFFIC, intended destinations must be explicitly included in the egress network policy. Mode and policy requirements.
My review would keep two questions separate: does the configured path select this destination, and is the connection permitted along that path?
Ask the operator to identify both answers for the pilot service. That makes a later failure easier to diagnose than an undifferentiated report that the gateway is not working.
Test Names, Identities, and Denied Destinations
For a bounded test, I would capture the hostname requested, the expected DNS result, the chosen destination, and relevant network evidence. Confirm that the application is reaching the intended service rather than an alternative public endpoint.
Then test a harmless destination that should remain unavailable. A connectivity design needs evidence for denied access as well as allowed access.
Keep application authentication in the test plan. Reaching an endpoint does not establish that a workload has the correct identity or permissions to use it. Record network success and application authorization as separate results.
Use approved diagnostics and synthetic requests. Avoid capturing credentials or sensitive response bodies in a shared network troubleshooting record.
Retain a Reversible Change Record
My recommended record would identify the NCC attachment, delegated subnet, traffic mode, destination policy, and the teams responsible for DNS, routing, and security controls.
Before a broader rollout, agree on the effect of detaching or changing the gateway. Determine which applications could be affected and how their intended connectivity would be restored.
Repeat the relevant checks after a routing or policy change. A historical success should not become permanent evidence for a network configuration that has since changed.
Practical Cloud Engineer Takeaway
Start with a bounded preview workload and an approved destination.
Record the expected route for each connection type.
Account for paths that take precedence over the gateway.
Check egress permission separately from route selection.
Verify denied access and application authentication too.
Who Should Care?
Azure Databricks platform teams, network engineers, and application owners connecting serverless workloads to private enterprise services.
Bottom Line
Private Network Gateway can simplify connectivity setup. The operational evidence still needs to show the intended route, permission boundary, and application result—not simply that one request completed.
No gateway, subnet, NCC, network policy, or Databricks workload was created or changed for this article.
Sources
Stay radical, stay curious, and keep pushing the boundaries of what is possible in the cloud.
Chriz
Beyond Cloud with Chriz
Comments