Skip to main content

Technical Lab: Configure networking settings for an App Service

Questions​

Question 1 — Multiple Choice​

A development team needs to ensure that their App Service can communicate with a database hosted on a private Azure Virtual Network, without exposing this database to the internet. The App Service is on the Standard S2 plan.

Which functionality should be enabled on the App Service to meet this requirement?

A) Private Endpoint on the App Service, pointing to the database subnet

B) VNet Integration, connecting the App Service to the subnet where the database resides

C) Service Endpoint on the App Service subnet, authorized in the database firewall

D) Hybrid Connection, configuring a relay between the App Service and the private VNet

Question 2 — Technical Scenario​

A developer reports that after enabling regional VNet Integration on their App Service, calls to resources within the integrated VNet continue to fail. Upon investigation, you identify the following configuration on the App Service:

WEBSITE_VNET_ROUTE_ALL = 0

The target database is at 10.1.2.5, within a subnet of the integrated VNet.

What is the most likely cause of the failure?

A) Regional VNet Integration doesn't support communication with RFC 1918 addresses without additional DNS configuration

B) The WEBSITE_VNET_ROUTE_ALL = 0 configuration prevents traffic destined for private addresses from being routed through the VNet

C) The App Service needs to be on the Premium plan to access resources in subnets other than its own integration subnet

D) The integration subnet cannot contain other resources besides the App Service delegated to it

Question 3 — Multiple Choice​

You need to block access to your App Service so that only requests originating from a specific corporate IP address (203.0.113.45) are accepted. All others should be rejected with status 403.

What is the correct approach using native App Service features?

A) Configure an Access Restriction rule of type "Allow" for IP 203.0.113.45 and, since the default rule implicitly denies everything else, no other action is necessary

B) Configure an "Allow" rule for 203.0.113.45 and an explicit "Deny" rule for 0.0.0.0/0 with lower priority

C) Associate a Network Security Group (NSG) to the App Service subnet and add an inbound rule allowing only 203.0.113.45

D) Enable VNet Integration and configure the NSG of the integrated subnet to block all traffic except the desired IP

Question 4 — Technical Scenario​

A company wants their App Service to be accessible only by internal organizational resources, without any exposure to the public internet. The App Service endpoint should have a private IP resolvable within the VNet.

The architect proposes the following solution:

  1. Create a Private Endpoint for the App Service in a corporate VNet subnet
  2. Create a Private DNS Zone privatelink.azurewebsites.net linked to the VNet
  3. Enable the "Route All" option in the App Service VNet Integration

What is the error in the above proposal?

A) Private Endpoints in App Services don't support private DNS zones; manual DNS entries are required

B) The "Route All" option in VNet Integration is irrelevant for the inbound private access requirement; Private Endpoint and private DNS already solve the scenario without requiring VNet Integration

C) The Private DNS Zone should be privatelink.azurewebsites.windows.net and not privatelink.azurewebsites.net

D) It's necessary to explicitly disable the App Service public endpoint, as Private Endpoint alone doesn't prevent internet access

Question 5 — True or False​

Statement: When configuring regional VNet Integration on an App Service, the subnet delegated to this integration can be shared with other Azure resources, such as virtual machines, as long as there are available IP addresses in the subnet.

True or False?

Answer Key and Explanations​

Answer Key — Question 1​

Answer: B

VNet Integration is the functionality that allows the App Service to make outbound calls to resources within a private VNet. It connects the App Service to a subnet and routes outbound traffic through that network, allowing it to reach the database without internet exposure.

The main misconception in the distractors lies in confusing traffic direction:

  • Private Endpoint (A) serves for other resources to access the App Service privately, i.e., inbound traffic. It doesn't solve outbound communication from the App Service to the VNet.
  • Service Endpoint (C) restricts access to Azure managed services (like Azure SQL, Storage), but doesn't enable the App Service to route traffic through a private VNet.
  • Hybrid Connections (D) is a valid solution for on-premises scenarios via Service Bus Relay, but it's not the native and appropriate approach for communication with an Azure VNet.

Answer Key — Question 2​

Answer: B

With WEBSITE_VNET_ROUTE_ALL = 0, only traffic destined for addresses not routable over the internet (like RFC 1918 space) is not mandatory routed through the VNet. In practice, with this value, the App Service routes through the VNet only explicitly defined routes. For 10.x.x.x addresses, routing may not occur via VNet Integration without "Route All" being enabled.

Setting WEBSITE_VNET_ROUTE_ALL = 1 (or using the equivalent configuration in the portal) forces all outbound traffic through the VNet, including traffic destined for 10.1.2.5.

  • Distractor A confuses the role of DNS with network routing; private DNS is relevant for name resolution, not for connectivity with already known IPs.
  • Distractor C is imprecise: Standard plans support regional VNet Integration.
  • Distractor D is partially true as a security best practice, but it's not the cause of the described failure.

Answer Key — Question 3​

Answer: A

App Service Access Restrictions work with an implicit default "Deny All" rule with the lowest priority. By adding an "Allow" rule for 203.0.113.45, all traffic not covered by this rule is automatically denied. It's not necessary to create an explicit "Deny" rule for 0.0.0.0/0.

Distractor B describes correct behavior in NSGs, but not in App Service Access Restrictions, where the "implicit deny" logic already exists natively.

Distractors C and D represent an important conceptual misconception: App Services are PaaS services and don't reside in user-managed subnets. NSGs are not directly applicable to App Service inbound traffic in the same way as with VMs.

Answer Key — Question 4​

Answer: B

The described scenario is about inbound private access to the App Service. For this, Private Endpoint exposes the App Service with a private IP in the VNet, and the Private DNS Zone ensures correct hostname resolution to that internal IP.

VNet Integration is an outbound functionality, not inbound. Including it in the proposal isn't an error that would break the solution, but represents an unnecessary and conceptually misguided component for the presented requirement, making the proposal incorrect as described.

  • Distractor C is wrong: the correct private zone suffix for App Services is indeed privatelink.azurewebsites.net.
  • Distractor D points to a legitimate security concern (disabling the public endpoint is recommended), but doesn't represent an error in the proposal that would make the solution inoperable.

Answer Key — Question 5​

Answer: False

The subnet used for regional VNet Integration must be exclusively delegated to the Microsoft.Web/serverFarms service. This delegation prevents other resources, such as virtual machines or other services, from being deployed or connected to the same subnet.

This is a platform limitation, not just a recommendation. Attempting to associate other resources to the delegated subnet results in an error. The only component allowed in the integration subnet is the App Service Plan delegation itself. This behavior differs, for example, from subnets used by Private Endpoints, which can coexist with other resources.