What should you do?

You have several Windows Server and Ubuntu Linux virtual machines (VMs) distributed across two virtual networks (VNets):

– prod-vnet-west (West US region)

– prod-vnet-east (East US region)

You need to allow VMs in either VNet to connect and to share resources by using only the Azure backbone network.

Your solution must minimize cost, complexity, and deployment time.

What should you do?
A . Add a service endpoint to each VNet.
B. Configure peering between prod-vnet-west and prod-vnet-west.
C. Create a private zone in Azure DNS.
D. Deploy a VNet-to-VNet virtual private network (VPN).

View Answer

Answer: B

Explanation:

You should configure peering between prod-vnet-west and prod-vnet-west. Peering enables VMs located on two different Azure VNets to be grouped logically together and thereby connect and share resources. Traditional VNet peering involves two VNets located in the same region. However, global VNet peering, generally available in summer 2018, supports VNets distributed across any Azure public region.

You should not deploy a VNet-to-VNet VPN. First, global VNet peering means that you are no longer required to use a VPN gateway to link VNets located in different Azure regions. Second, the scenario requires that you minimize cost and complexity.

You should not create a private zone in Azure DNS. This action would be necessary for resources in peered VNets to resolve each other’s DNS host names. However, the scenario makes no requirement for private host name resolution.

You should not add a service endpoint to each VNet. Service endpoints allow you to limit access to certain Azure resources, such as storage accounts and Azure SQL databases, to resources located on a single VNet. Thus, this feature cannot be used to link two VNets as the scenario mandates.