There is no virtual network peering between VM4's VNet (VNet3) and VM5's VNet (VNet4). To enable the VMs to communicate over the Microsoft backbone network a VNet peering is required between VNet3 and VNet4.
Topic 3, Proseware. Inc
Overview
Existing Environment
Proseware. Inc. is a financial services company that has a main office in New York City and a branch office in San Francisco.
Hybrid Environment
Proseware has an on-premises Active Directory Domain Services (AD DS) forest named corp.proseware.com that syncs with a Microsoft Entra tenant named proseware.com.
Proseware has an Azure subscription that is linked to proseware.com.
Proseware has an internal certification authority (CA).
Network infrashtructure
The offices contain the resources shown in the following table.
NYCNet connects to Azure by using an ExptessRoute circuit.
SFONet connects to Azure by using a Site to-Site (S2S) VPN.
The Azure subscriotion contains the virtual networks and subnets shown in the followina table.

The subscription contains four virtual machines named VM1, VM2, VM3, and VM4. VM1 and VM2 host an app named App1.
VM3 and VM4 host a web app named App2 that is accessed by using a FQDN of app2.proseware.com. Users access app2.proseware.com by using HTTP or HTTPS.
VM1, VM2, and VM4 are connected to SpokeVNet
The subscription contains Application Gateway resources shown in the following table.

The subscription contains an Azure Front Door Standard profile named FD1. FD1 contains a single origin group that targets APPGW1 by using the default endpoint name.
HubVNet connects to NYCNet by using an ExpressRoute gateway named ERGW1.
The subscription contains an Azure Private DNS zone named DNSZonel in the East US region. DNSZonel hosts a namespace of azure.piosewaie.com and is linked to HubVNet The subscription contains a Standard Azure load balancer named LBS1 in the East US region. LBS1 contains a backend pool that hosts VM1 and VM2.
Planned Changes
Proseware plans to implement the following changes:
* Deploy an Azure Private DNS Resolver named PRDNSl to HubVNet and link PRDNS1 to SpokeVNet.
* Create a DNS forwarding ruleset named DNSRS1 and associate DNSRS1 with PRDNSl
* Deploy Azure Virtual Network Manager and implement the following rules:
o Allow inbound connections on TCP port 3389 from the on-premises networks to SU8NET-JUMPHOSTS. o Block inbound connections on TCP poit 80 from the internet to SpokeVNet.
* Ensure that Azure Virtual Network Manager rules take precedence over conflicting NSG rules.
* Deploy two network virtual appliances (NVAs) named NVA1 and NVA2 to HubVNet.
* Deploy a gateway load balancer named L8GW1 to HubVNet.
* Configure LBGW1 to inspect traffic on TCP ports 443, 1433, and 1434 from LBS1 by using NVA1 and NVA2.
* Ensure that all the traffic to App2 is processed by using FD1.
Connectivity Requirements
Proseware identifies the following connectivity requirements:
* Minimize the complexity of the Azure Virtual Network Manager deployment.
* Route traffic between NYCNet and SFONet via the ExpressRoute circuit and the S2S VPN
* Ensure that remote users on Windows 11 devices can connect to HubVNet by using a Point-to-Site (P2S) VP and their proseware.com credentials.
Security Requirements
Proseware identifies the following general requirements:
* Minimize the IP address space required to deploy platform-managed resources to the virtual networks.
* From SpokeVNet, resolve name resolution requests for the azure.proseware.com namespace and the corp.
proseware.com namespace by using PRDNS1.
* Whenever possible, minimize administrative effort.