GitHub Repository | Azure Bicep | Azure DevOps | Azure Landing Zones | Infrastructure as Code | Private Endpoint

As organizations adopt Azure Landing Zones, application teams often deploy workloads into dedicated subscriptions while shared platform services—such as Private DNS—are managed separately. This separation improves governance and security, but it also introduces a challenge: how can application teams securely integrate with centrally managed networking services without requiring broad platform permissions?

To solve this, I designed an automated Azure Private DNS onboarding solution that standardizes integration between application subscriptions and a centralized networking platform using Azure Bicep, Azure DevOps, and Azure PowerShell.

The goal wasn’t simply to automate deployments—it was to create a reusable platform capability that enables secure self-service while preserving centralized governance.

The complete implementation—including Azure Bicep modules, Azure DevOps pipelines, PowerShell automation, and deployment documentation—is available in the accompanying GitHub repository for anyone interested in exploring the solution in more detail.

The Architecture

The solution follows the Azure Landing Zone model by separating responsibilities across subscriptions.

Azure Tenant
│
├── Platform Subscription
│     ├── Private DNS Zones
│     ├── Hub Networking
│     ├── DNS Private Resolver
│     └── Shared Connectivity Services
│
└── Application Subscription
      ├── Application Resources
      ├── Private Endpoints
      ├── Virtual Network
      └── Azure DevOps Deployment Pipeline

Platform engineers retain ownership of shared networking resources while application teams manage their own infrastructure.

Instead of granting Contributor access to the Platform subscription, application teams receive only the permissions required to onboard their applications.

Figure 1. Azure Landing Zone architecture for centralized Azure Private DNS integration.

Figure 1 illustrates the Azure Landing Zone architecture used for this solution. Platform services, including Private DNS and hub networking, are centrally managed within the Platform subscription, while application teams deploy workloads into dedicated application subscriptions. A custom Azure RBAC role enables application teams to securely integrate with shared networking resources without requiring elevated permissions.

Application Team Responsibilities

Application teams own their application subscriptions and are responsible for provisioning and managing their infrastructure using Azure DevOps and Infrastructure as Code (IaC). This includes:

• Infrastructure as Code (Bicep) templates
• Azure DevOps deployment pipelines
• Application workloads
• Virtual Networks
• Private Endpoints
• Private Endpoint DNS integration
• Validation and testing of deployed resources

Their Azure DevOps IaC pipeline provisions the required Azure infrastructure, including Private Endpoints, and integrates those resources with the centrally managed Azure Private DNS platform through a delegated RBAC model.

Platform Team Responsibilities

The Platform team owns the shared networking services and maintains the centralized Azure platform, including:

• Azure Private DNS Zones
• Hub Virtual Networks
• Azure DNS Private Resolver
• Shared connectivity services
• Network governance
• Custom RBAC roles for delegated access

Rather than granting Contributor access within the Platform subscription, application teams receive a custom RBAC role that provides only the permissions necessary to integrate their infrastructure with shared networking services.

Least Privilege by Design

A custom Azure RBAC role was created specifically for the Azure DevOps service principal used by application teams.

The role follows the principle of least privilege by allowing only the operations required to associate Private DNS Zone Groups and establish Virtual Network Links to centrally managed Private DNS Zones.

This approach enables secure self-service without exposing broader administrative access to shared platform resources.

By shifting validation earlier in the deployment lifecycle, infrastructure changes become predictable, repeatable, and easier to support.

Deploying Infrastructure with Bicep

Application teams deploy their Private Endpoint using reusable Bicep modules.

resource privateDnsZoneGroup 'Microsoft.Network/privateEndpoints/privateDnsZoneGroups@2024-05-01' = {
  name: 'default'
  parent: privateEndpoint
  properties: {
    privateDnsZoneConfigs: [
      {
        name: 'blob'
        properties: {
          privateDnsZoneId: privateDnsZone.id
        }
      }
    ]
  }
}

Note: This example has been simplified for the article. The complete implementation—including reusable modules, parameter files, and deployment examples—is available in the GitHub repository linked above.

Because the DNS platform already exists, the deployment simply integrates with centrally managed resources rather than recreating them.

Modernizing Deployments

Every deployment passes through a standardized Azure DevOps pipeline.

stages:
- Validate
- WhatIf
- Deploy
- Verify

Each stage performs a specific function:

• Validate the Bicep templates
• Execute Azure What-If analysis
• Deploy infrastructure
• Verify successful Private Endpoint and DNS registration

This repeatable workflow provides confidence before infrastructure reaches production.

Operational Verification

After deployment, Azure PowerShell validates the Private Endpoint and DNS configuration.

Get-AzPrivateEndpoint `
    -ResourceGroupName $ResourceGroup `
    -Name $PrivateEndpointName

Automated verification helps ensure infrastructure has been deployed correctly and reduces troubleshooting time.

Security Through Delegation

One of the most valuable outcomes of this project was enabling secure delegation.

Application teams can deploy and integrate their own workloads with the centralized networking platform without requiring elevated permissions within the Platform subscription.

The result is a scalable operating model that balances governance, security, and developer productivity.

Custom RBAC Role Permissions (Reference)

The Azure DevOps service principal is assigned a custom role that grants only the permissions required for DNS integration.

Private DNS Zone Groups

• Microsoft.Network/privateDnsZones/read
• Microsoft.Network/privateDnsZones/join/action

Virtual Network Links

• Microsoft.Network/privateDnsZones/read
• Microsoft.Network/privateDnsZones/virtualNetworkLinks/read
• Microsoft.Network/privateDnsZones/virtualNetworkLinks/write
• Microsoft.Network/privateDnsZones/virtualNetworkLinks/delete

Conclusion

Modernizing Azure infrastructure isn’t just about adopting Infrastructure as Code—it’s about designing platforms that allow teams to move independently without compromising governance.

By combining Azure Landing Zones, custom RBAC, Azure Bicep, Azure DevOps, and automated validation, this solution transformed Azure Private DNS onboarding into a secure, reusable platform capability that can scale across subscriptions, environments, and application teams.