Automating Multi-Tenant Private Endpoint DNS with Azure Policy and Lighthouse

Microsoft's Azure Infrastructure engineering group detailed a production-ready architectural pattern that automates Private Endpoint DNS lifecycle management across distinct Microsoft Entra tenants. By combining Azure Policy DeployIfNotExists (DINE) policies, user-assigned managed identities, and Azure Lighthouse scoped delegations, organizations hosting centralized Private DNS zones can allow spoke or workload tenants to automatically create, maintain, and decommission Private Endpoint DNS records without granting long-lived cross-tenant credentials or direct access to core networking subscriptions. For enterprise platform and networking teams, private endpoint adoption frequently breaks at multi-tenant boundaries. While single-tenant hub-and-spoke models seamlessly attach private DNS zone groups via Azure Policy, multi-tenant and multi-organization landing zones typically stall. In those architectures, workload owners spinning up storage accounts, container registries, or database endpoints either rely on slow manual ticketing or demand over-privileged service principals into central networking zones. This pattern bridges that governance gap by scoping delegation strictly to the dedicated DNS resource group via Azure Lighthouse, allowing local policy remediation agents to register `privateDnsZoneGroup` configurations autonomously. This architecture directly aligns with the industry-wide transition toward zero-standing-privilege (ZSP) cloud operations and platform engineering self-service. Modern enterprise landing zones are increasingly fragmented across segregated billing and identity tenants due to compliance boundaries, mergers and acquisitions, or operational silos. As cloud-native architectures standardize on private access by default, platform teams require infrastructure-as-code and native policy mechanisms that avoid brittle webhook relays, central Lambda/Azure Function dispatchers, and stored access secrets. In practice, cloud engineers implementing this model should establish their central Private DNS zones, resolution infrastructure (such as Azure DNS Private Resolver), and virtual network links before deploying the Lighthouse delegation. Delegations must be restricted solely to the Private DNS Zone Contributor role at the resource group scope rather than subscription-wide. Platform teams must also account for policy assignment ordering and run baseline remediation tasks across existing endpoints. Finally, monitoring Lighthouse registration assignments and ensuring bi-directional lifecycle testing—verifying record purge on resource deletion—is critical to prevent orphaned DNS records and potential routing collisions.