Lab: App Service plan, TLS, and network boundaries

Outcome

Create a disposable paid-tier App Service plan and app, deploy a small response, validate a custom domain and HTTPS binding, then separately prove outbound VNet integration and inbound private-endpoint behavior.

Do

1. Check selected SKU availability in the training region. Create a Linux plan and app in a tier that supports the planned features, deploy a small ZIP/container response, set an app setting, and inspect deployment logs and the default hostname. Delete no shared plan: every app in a plan shares its compute and pricing boundary.
2. In a public DNS zone you control, add the required ownership-validation and hostname record for a training subdomain. Add the custom domain, bind a valid managed or private certificate, enforce HTTPS, and test the hostname. App Service custom domains use public DNS zones; do not use a private zone for validation.
3. Create separate integration and private-endpoint subnets. Enable VNet integration on the app and verify an outbound request from the app to a private test endpoint. Then create an App Service private endpoint, configure its private DNS mapping, disable public access only after private access succeeds, and test from a linked-VNet client.

Verify

Capture plan OS/region/SKU, app settings and deployment log, custom-domain validation and HTTPS binding, outbound private-resource reachability through VNet integration, and inbound private-endpoint DNS/client result. You should now understand: a plan provides app compute; custom domains prove public DNS ownership; VNet integration is outbound; a private endpoint is inbound and uses a different subnet.

Break and fix

1. Use a wrong DNS validation record or certificate binding. Diagnose DNS propagation/ownership, hostname, certificate, and HTTPS-only configuration; correct it before deleting records.
2. Remove VNet integration or its route/DNS path. Diagnose outbound resolution, integration subnet, NSG/UDR, and target firewall; restore the minimal path.
3. Try to use the integration subnet for the private endpoint or expect VNet integration to make the app private inbound. Correct the topology, link private DNS, and re-test from the private client.

Scenario practice

1. Configure: Pick plan SKU/region/OS, app settings, custom-DNS/TLS steps, and inbound/outbound network controls for an internal API.
2. Diagnose: The app can load publicly but cannot reach a private database. Inspect VNet integration, subnet routing, DNS, target firewall, and app logs.
3. Distinguish: Contrast App Service plan with app, private endpoint with VNet integration, custom-domain validation with private DNS, and TLS binding with HTTPS-only enforcement.

Clean up

Restore public access only if required to remove the training resources, remove the private endpoint/DNS records, integration, custom domain and certificate binding, app, plan, VNet, and disposable resource group.

Sources and re-audit

• Manage an App Service plan, checked 2026-08-22.
• Map a custom domain, checked 2026-08-22.
• App Service networking features, checked 2026-08-22.
• VNet integration, checked 2026-08-22.

Re-audit when App Service SKU, domain, TLS, or networking support changes.

Related

app-service · app-service-plan · app-service-tls-custom-dns · app-service-networking · private-endpoint · All labs