HOTSPOT -
You have the Azure resources shown in the following table.
WebApp1 uses the Standard pricing tier.
You need to ensure that WebApp1 can access the virtual machines deployed to Vnet1\Subnet1 and Vnet2\Subnet1. The solution must minimize costs.
What should you create in each virtual network? To answer, select the appropriate options in the answer area.
Hot Area:
Box 1: An additional subnet -
Regional virtual network integration: When you connect to virtual networks in the same region, you must have a dedicated subnet in the virtual network you're integrating with.
Box 2: A VPN gateway -
Gateway-required virtual network integration: When you connect directly to virtual networks in other regions or to a classic virtual network in the same region, you need an Azure Virtual Network gateway created in the target virtual network.
Note: If your app is in an App Service Environment, it's already in a virtual network and doesn't require use of the VNet integration feature to reach resources in the same virtual network.
Reference:
https://docs.microsoft.com/en-us/azure/app-service/overview-vnet-integration
Answer is correct. You need to create for VNET1 a subnet, because you can do Regional VNET integration since the web app and the VNET1 are in the same region. VNET2 is in a different region so you would need a VPN gate and a P2S ( consider that in VNET2 you already have a GatewaySubnet which doesn't necesarily mean you have a VPN gate created, it just means you created a subnet called GatewaySubnet ).
Thanks Cristoicach91 !
not to mention "minimize costs"; peering is free.
Answer given is not correct. Correct answer: Vnet1 - an additional subnet Correct answer: Vnet2 - a peering connection From same attached documentation: https://learn.microsoft.com/en-us/azure/app-service/overview-vnet-integration Regional virtual network integration: When you connect to virtual networks in the same region, you must have a dedicated subnet in the virtual network you're integrating with. Using regional virtual network integration enables your app to access: Resources in the virtual network you're integrated with. Resources in virtual networks peered to the virtual network your app is integrated with including global peering connections. (you could use a gateway if you wanted to connect directly, but it is not a requirement here. Cost is.)
This is the answer as it says minimizing costs and the public doc says integration allows access to include global peering connections.
I were the architect, I would use peering between VNETs as opposed to a `VPN or private end points can be created in VNET1 to reach out to services in VNET2. I dont agree with the answer given in box 2
Ans: Additional subnet and Peering connection Explanation: Using regional virtual network integration enables your app to access: 1)Resources in the virtual network you're integrated with. 2)Resources in virtual networks peered to the virtual network your app is integrated with including global peering connections. https://learn.microsoft.com/en-us/azure/app-service/overview-vnet-integration#regional-virtual-network-integration
I agree that the first option is an additional subnet for vnet integration. For the second option, I would personally create a peering (between vnet1 and vnet2) - it works - it requires no additional steps - cost difference is hard to know without knowing the traffic details VPN: pay for 2 gateways and egress traffic Peering: pay for ingress/egress traffic Problems with the VPN choice - it does not work without also creating a VPN gateway in vnet 1 - Does the existence of gateway subnets imply that I can use them? Or that they are in use? I have no way of knowing. - Not addressed in the question, but it limits my bandwidth.
your right... Same question raised for me... if enabled peering between Vnet-1 and vnet-2 ,it will be less cost and easy to manage the connectivity... But if we used VPN gateway need more configuration for enable the connectivity
Think the flaw in the logic is that VNET1 and VNET2 have to have connectivity. App Service plans can't have more than two virtual network integrations per App Service plan. Multiple apps in the same App Service plan can use the same virtual network integration. Currently you can only configure the first integration through Azure portal. The second integration must be created using Azure Resource Manager templates or Azure CLI commands. The suggested answer assumes you use the VNET integration model to connect to VNET1, and the Gateway required VNET integration model to connect to VNET2. No interconnectivity between VNET1 and VNET2. The documentation is not clear on if these 2 models can exist together. I would go with peering myself for the 2nd answer.
So found some additional information that provides the correct context for this question. The question states 'WebApp1 uses the Standard pricing tier.' Not sure what it was at the time of the question months ago, but when you create an App Service Plan, only the Windows Operating System option has a Standard pricing tier. When I create a standard Windows App Service Plan and go to the Networking section under settings and then click on 'Click here to manage', I am brought to the VNET Integration management page where it states: Regional VNET Integrations 0/2 Gateway required VNET Integrations 0/5 This confirms that the 2 models can exist together. So the correct answer is an additional subnet in VNET1 and a virtual network gateway in VNET2.
Answer is correct. There is no need to have connectivity between Vnet1 and Vnet2 (might actually not be allowed).. The requirements only states App Service needs connection to Vnet1 and Vnet2
It mentions minimizing cost. The most cost effective way to achieve the goal is to use a new subnet (for app integration) + peering
correct.
So helpful, truly appreciate your valuable contributions
I think there are multiple right answers to this. After evaluating in my lab i would go for private endpoint. Why? Because it establishes a connection between the PaaS Service WebApp and your VM. Private endpoints are typically less expensive than VPN Gateways, so i would go for it. VNet peering seems also a way but, the App is not in a Vnet and the question is what are you creating in each VNet, so I would go for Private Endpoint. Let me know what you think about this.
Correct myself. Private endpoint is only used for incoming traffic to your app. Outgoing traffic won't use this private endpoint. You can inject outgoing traffic to your network in a different subnet through the virtual network integration feature. So i would go for subnet in the same region an VNet peering
At first glance you would look at VNet-to-VNet, however the focus is AppServices connectivity to both VNet. Therefore integration between AppService and Virtual networks requires a unique subnet. Note. The virtual network integration feature has no extra charge for use beyond the App Service plan pricing tier charges. On the other side is a required -gateway to enable Vnet to connect.
exam topic answer seem to be correct
because there are 2 VNETs involved and now VNET integration supports global peering connections .. I will go with vnet peering for second question..first is correct
If it is single VNET scenario where App Service and VNET are in different region then the only option for direct integration is set up VPN gateway and SSTP P2S VPN
Answer: An additional subnet ------> Regional virtual network integration: When you connect to virtual networks in ---> the same region <--- , you must have a dedicated subnet in the virtual network you're integrating with. A VPN gateway ------> Gateway-required virtual network integration: When you connect directly to virtual networks in ---> other regions <--- or to a classic virtual network in the same region, you need an Azure Virtual Network gateway created in the target virtual network.
I feel since these are both connected by the Azure global network and if these are both in the same tenant and owned by the same owner, if you have a vnet in US East and a vnet is US West, then in my mind Answer 1 is 'vnet peering' and Answer 2 is 'vnet peering'.
not to mention "minimize costs"; peering is free.
having the gateway subnet is irrelevant, its meant to confuse.