Troubleshooting Lab: Configure networking settings for an App Service
Diagnostic Scenarios
Scenario 1 — Root Cause
A development team reports that an App Service on the Premium P2v3 plan cannot resolve DNS names for internal resources within the integrated VNet. The application returns the following error when trying to connect to the internal server db-interno.corp.local:
System.Net.Sockets.SocketException: No such host is known
at System.Net.Dns.GetHostEntryOrAddressesCore(String hostName, ...)
Host: db-interno.corp.local
When investigating the environment, you collect the following information:
| Configuration | Value |
|---|---|
| VNet Integration | Enabled (regional) |
| WEBSITE_VNET_ROUTE_ALL | 1 |
| App Service Plan | Premium P2v3 |
| Integration subnet | /24, delegated to Microsoft.Web/serverFarms |
| VNet DNS | Configured to 10.0.0.4 (internal DNS server) |
| App Service Private Endpoint | Not configured |
| App Service Region | East US |
| App TLS certificate | Valid, issued 3 days ago |
The integration subnet has 240 available addresses. The DNS server 10.0.0.4 responds correctly when queried from a VM in the same VNet.
What is the root cause of the name resolution failure?
A) The integration subnet doesn't have enough addresses for App Service operation on the Premium plan
B) The App Service is not using the DNS server configured in the VNet because the WEBSITE_DNS_SERVER configuration was not defined at the App Service level
C) Private Endpoint is not enabled, which prevents DNS traffic from reaching internal servers via VNet Integration
D) The value WEBSITE_VNET_ROUTE_ALL = 1 redirects DNS traffic to the internet, ignoring the VNet's internal DNS
Scenario 2 — Action Decision
The problem cause has been identified: the production App Service has misconfigured Access Restrictions. An "Allow" rule was added for the 10.0.0.0/8 block, but the system's default rule remains with priority 2147483647 as "Allow All" instead of "Deny All", because the resource was created by a legacy script that didn't configure the default restriction correctly.
As a result, any internet IP can access the App Service, violating the company's security policy.
The operational context is as follows:
- The App Service is in production with active SLA
- There's a dependency on an external healthcheck service monitoring the
/healthendpoint from IP198.51.100.20 - The security team requires access to be restricted immediately
- You have write permission on the resource
- No maintenance window is open
What is the correct action to take at this time?
A) Delete the App Service and recreate it via ARM template with correct Access Restrictions, ensuring total configuration consistency
B) Add an explicit "Deny" rule for 0.0.0.0/0 with priority 100 immediately, without considering the external healthcheck
C) Add an "Allow" rule for 198.51.100.20 with high priority, then add a "Deny" rule for 0.0.0.0/0, keeping the existing rule for 10.0.0.0/8
D) Wait for the maintenance window to apply restrictions, as any change to Access Restrictions causes App Service restart
Scenario 3 — Root Cause
An architect configured a Private Endpoint for a corporate App Service and created a Private DNS Zone linked to the VNet. After configuration, internal users accessing via corporate VPN report that app access works correctly. However, an external partner accessing the same hostname from the internet receives the following behavior:
curl -v https://meuapp.azurewebsites.net
* Trying 20.45.132.18...
* Connected to meuapp.azurewebsites.net (20.45.132.18) port 443
> GET / HTTP/1.1
< HTTP/1.1 403 Forbidden
< x-ms-error-code: Forbidden
The partner confirms that the TLS certificate is valid and the TCP connection is established. The App Service is on the Premium P3v3 plan. The team reports that the App Service was migrated from another tenant two weeks ago and the Custom Domain was reconfigured during this migration. The App Service public endpoint was never disabled after Private Endpoint creation.
What is the root cause of the 403 error received by the external partner?
A) The TLS certificate was reissued during tenant migration and is not recognized by the external client, causing rejection at the application layer
B) The partner is resolving the hostname to the App Service public IP, and since the public endpoint wasn't disabled but there's no Access Restriction allowing the partner's IP, the request is blocked by the default rule
C) The Private DNS Zone is intercepting external DNS queries and returning the private IP, making the App Service inaccessible outside the VNet
D) The Premium P3v3 plan doesn't support simultaneous access via Private Endpoint and public endpoint, generating routing conflict
Scenario 4 — Diagnostic Sequence
A production App Service stopped communicating with an Azure Service Bus hosted in a private VNet. The failure started after a configuration update performed yesterday afternoon. There was no change in the application code.
You have the following steps available to investigate:
[P1] Check if VNet Integration is still associated with the App Service and if the subnet is correct
[P2] Confirm if Service Bus responds correctly from a VM in the same subnet
[P3] Review App Service Activity Log history for the last 24 hours
[P4] Test App Service outbound connectivity using "Diagnose and Solve Problems > Network checks" feature
[P5] Check if there was a change in the NSG associated with the integration subnet
What is the correct investigation sequence?
A) P3 → P1 → P5 → P2 → P4
B) P2 → P4 → P1 → P3 → P5
C) P3 → P1 → P4 → P5 → P2
D) P1 → P3 → P5 → P2 → P4
Answer Key and Explanations
Answer Key — Scenario 1
Answer: B
The decisive clue in the statement is that the VNet DNS is correctly configured to 10.0.0.4 and this server responds from VMs in the same VNet. This eliminates any problem with the DNS server itself. App Service with regional VNet Integration uses, by default, Azure DNS (168.63.129.16) and does not automatically inherit the DNS configured in the VNet. To force the use of the internal DNS server, it's necessary to define the application setting WEBSITE_DNS_SERVER with the address 10.0.0.4.
The information about the valid TLS certificate is irrelevant for DNS resolution diagnosis and was included purposefully to divert attention.
Distractor C represents the most dangerous error: confusing the roles of Private Endpoint (inbound traffic) and VNet Integration (outbound traffic). Private Endpoint has no relation to the App Service's ability to resolve names via internal DNS.
Distractor D reverses the logic of WEBSITE_VNET_ROUTE_ALL: this value forces outbound traffic through the VNet, which benefits access to internal DNS, it doesn't harm it.
Answer Key — Scenario 2
Answer: C
The scenario presents two critical constraints: the requirement for immediate action and the dependency on external healthcheck at 198.51.100.20. Alternative C is the only one that satisfies both simultaneously, first creating the exception rule for the healthcheck before closing general access.
Distractor B solves the security problem but immediately breaks the external healthcheck, generating an unavailability alert during a window outside maintenance, which violates the active SLA.
Distractor A is technically valid for standardizing configuration, but recreating a production App Service outside a maintenance window represents an operational risk disproportionate to the problem.
Distractor D contains a false premise: Access Restrictions changes do not cause App Service restart. Acting based on this distractor means leaving unauthorized access active for longer than necessary.
Answer Key — Scenario 3
Answer: B
The central clue is in two facts: the TCP connection is established (the public IP responds on port 443) and the error is 403 Forbidden with x-ms-error-code: Forbidden. This is exactly the behavior of App Service Access Restrictions when a request is blocked by the default rule after creating any explicit rule. With Private Endpoint creation, it's likely that an "Allow" rule for the VNet was added, activating rule evaluation mode and making the default "Deny All" rule effective for unauthorized external traffic.
The information about tenant migration and Custom Domain reconfiguration is irrelevant for diagnosis. The error is not at the TLS layer, as the connection was established successfully.
Distractor C represents an important misconception: Private DNS Zones do not affect external DNS queries. They are resolved only by clients within the linked VNet. An external client resolves the hostname via Microsoft's public DNS, which returns the public IP normally.
The most dangerous distractor is A: focusing on the certificate because of the tenant migration mention. The statement explicitly says that TCP and TLS connections were established successfully, which rules out any certificate problem.
Answer Key — Scenario 4
Answer: A
The correct sequence starts with P3 (Activity Log) because the statement confirms that the failure started after a configuration update yesterday. The Activity Log identifies exactly what was changed, directing all subsequent investigation. With this information, P1 checks if VNet Integration was affected, P5 checks if the subnet NSG was changed (most common cause of outbound blocking), P2 validates if Service Bus is reachable through the network, and P4 confirms outbound connectivity from the App Service itself.
Sequence D (P1 → P3 → P5 → P2 → P4) seems logical but errs by checking current state before understanding what changed. Starting with P1 without knowing what was altered can lead to a long investigation of components that are correct.
Sequence B starts with P2, which checks Service Bus in isolation without any evidence that the problem is with it. This is the classic error of diagnosing the destination before validating the path and origin point.
Troubleshooting Tree: Configure networking settings for an App Service
Color Legend:
| Color | Node Type |
|---|---|
| Dark blue | Initial symptom (entry point) |
| Blue | Diagnostic question (decision node) |
| Red | Identified cause |
| Green | Recommended action or resolution |
To use this tree when facing a real problem, start at the root node and answer each question based on what you observe in the environment, without assuming the cause. The first bifurcation separates outbound problems (App Service cannot reach something) from inbound problems (something cannot access the App Service). From there, each answer eliminates entire investigation paths. When you reach a red node, you have the cause identified. When you reach a green node, execute the indicated action and validate that the symptom was resolved before closing the diagnosis.