Private Endpoints for Azure App Service

Lock down an Azure App Service using private endpoints and DNS zone groups.

Introduction

30 Second Summary

When you deploy a web app to the cloud, it gets a public URL by default. Anyone on the internet can reach it. For enterprise applications handling sensitive data, that open door is a security risk that needs to be closed.

In this project, you will configure a private endpoint for an Azure App Service, set up private DNS resolution, disable public access entirely, and validate connectivity from a test VM through Azure Bastion.

What You'll Build

A secure Azure App Service deployment with private endpoint connectivity, proving end-to-end private network access within a virtual network.

By the end of this project, you'll have:

  • A virtual network with segmented subnets for workloads and Bastion, hosting a private endpoint that gives your App Service a private IP address.
  • A private DNS zone with DNS zone groups that automatically manage A records for your app and its SCM endpoint.
  • A fully locked-down App Service with public access disabled, validated through nslookup and browser tests from a test VM via Bastion.
  • Secret Mission: Production-grade hardening with NSG network policies on the private endpoint subnet and Network Watcher connection monitoring.

Are there any prerequisites?

You need an active Azure subscription (pay-as-you-go) and the Azure CLI installed and authenticated on your machine. This project assumes you have prior experience navigating the Azure Portal and running CLI commands.

Set Up Networking Foundation

A Private Endpoint gives an Azure PaaS service a private IP address inside your own virtual network. Before you can create one, you need the network itself.

In this step, you will build the VNet, subnets, and supporting infrastructure that every other resource in this project depends on. You will also deploy Azure Bastion and a test VM so you can later verify private connectivity without exposing any public endpoints.

In this step, get ready to:
  • Create a resource group and VNet with properly segmented subnets.
  • Deploy Azure Bastion for secure VM access.
  • Deploy a Windows Server test VM with no public IP.
Create resource group and virtual network

Every Azure deployment starts with a resource group to hold related resources together. The VNet provides the isolated address space where your private endpoint will live.

  • Create the resource group, VNet, and initial workload subnet by running these commands:
az group create --name pe-appservice-rg --location eastus2
az network vnet create \
  --resource-group pe-appservice-rg \
  --location eastus2 \
  --name pe-vnet \
  --address-prefixes 10.0.0.0/16 \
  --subnet-name subnet-1 \
  --subnet-prefixes 10.0.0.0/24

What do these commands do?

The first command creates a resource group called pe-appservice-rg in the eastus2 region. All resources you create in this project will live here.

The second command creates a VNet named pe-vnet with a 10.0.0.0/16 address space (65,536 addresses). It also creates subnet-1 with a /24 prefix (256 addresses) for your workload resources like the VM and the private endpoint.

  • Add the Bastion subnet to the VNet by running this command:
az network vnet subnet create \
  --resource-group pe-appservice-rg \
  --name AzureBastionSubnet \
  --vnet-name pe-vnet \
  --address-prefixes 10.0.1.0/26

Why a separate subnet for Bastion?

Azure Bastion requires a dedicated subnet named exactly AzureBastionSubnet. This naming convention is enforced by Azure. The /26 prefix gives it 64 addresses, which is the minimum size Azure allows for this subnet.

  • Verify your VNet was created successfully by running:
az network vnet show \
  --resource-group pe-appservice-rg \
  --name pe-vnet \
  --output table

You should see pe-vnet listed with a provisioningState of Succeeded.

Command not recognized or subscription error?

  • Make sure your Azure CLI is authenticated. Run az login and follow the prompts if your session expired.
  • Confirm you are on the correct subscription with az account show. If the wrong subscription is active, switch with az account set --subscription followed by your subscription ID.

Help me troubleshoot why my Azure CLI commands are failing

Deploy Azure Bastion

Azure Bastion lets you connect to VMs in your VNet using the Azure Portal, without needing a public IP on the VM itself. This is the secure way to access your test VM later when you validate private endpoint connectivity.

  • Create a Standard SKU public IP for Bastion by running:
az network public-ip create \
  --resource-group pe-appservice-rg \
  --name bastion-pip \
  --sku Standard \
  --zone 1 2 3
  • Deploy the Bastion host by running:
az network bastion create \
  --resource-group pe-appservice-rg \
  --name pe-bastion \
  --public-ip-address bastion-pip \
  --vnet-name pe-vnet \
  --location eastus2 \
  --sku Basic

Bastion takes a few minutes to deploy

This command typically takes 5-10 minutes to complete. Wait for the CLI to return before continuing. Bastion charges approximately $0.19/hr from the moment it deploys, regardless of usage. Complete this project and clean up promptly to minimize cost.

What do these commands do?

The public IP (bastion-pip) is the internet-facing address that Bastion uses to accept your browser-based connections from the Azure Portal.

The Bastion host (pe-bastion) is a managed PaaS service that sits in your AzureBastionSubnet and brokers RDP/SSH connections to VMs in the same VNet. You never need to expose port 3389 on your VM.

  • Verify Bastion is provisioned by running:
az network bastion show \
  --resource-group pe-appservice-rg \
  --name pe-bastion \
  --output table

You should see pe-bastion with a provisioningState of Succeeded.

Bastion deployment failed?

  • Confirm the subnet is named exactly AzureBastionSubnet. Any other name will cause the deployment to fail.
  • Check that the subnet prefix is at least /26. Smaller subnets are rejected.
  • Ensure the public IP uses Standard SKU. Basic SKU public IPs are not compatible with Bastion.

Help me troubleshoot my Azure Bastion deployment failure

Create test virtual machine

The test VM will sit inside subnet-1 alongside your future private endpoint. In the final step, you will connect to this VM through Bastion and use it to prove that DNS resolves the App Service hostname to a private IP.

  • Deploy a Windows Server 2022 VM with no public IP by running:
az vm create \
  --resource-group pe-appservice-rg \
  --name pe-test-vm \
  --image Win2022Datacenter \
  --public-ip-address "" \
  --vnet-name pe-vnet \
  --subnet subnet-1 \
  --size Standard_B2s \
  --admin-username azureuser

What about the admin password?

The CLI will prompt you to enter and confirm a password for the azureuser account. Choose a strong password (at least 12 characters with a mix of uppercase, lowercase, numbers, and special characters). You will need this password later when connecting via Bastion.

What does this command do?

  • Creates a VM named pe-test-vm running Windows Server 2022 Datacenter.
  • Uses Standard_B2s size (2 vCPUs, 4 GB RAM) which is sufficient for connectivity testing.
  • Sets --public-ip-address "" to ensure the VM has no public IP. The only way to reach it is through Bastion.
  • Places the VM in subnet-1 of pe-vnet, the same subnet where the private endpoint will be created.

The VM deployment takes a few minutes. Wait for the CLI to return a JSON response showing the VM details.

VM creation failed?

  • If you see a password complexity error, make sure your password is at least 12 characters and includes uppercase, lowercase, a digit, and a special character.
  • If you see a quota error, your subscription may not have enough vCPU quota in eastus2. Try a different region or request a quota increase in the Azure Portal under Subscription > Usage + quotas.

Help me fix my Azure VM creation error

Your network foundation is in place. Next up, you will deploy an App Service and connect it to this VNet through a private endpoint.

Deploy App Service with Private Endpoint

Your network foundation is in place. Now it is time to deploy the application that you will lock down with a private endpoint.

In this step, you will create an App Service web app and then connect it to your VNet through a Private Endpoint. The private endpoint assigns a private IP from your subnet to the web app, making it reachable only from within the VNet.

In this step, get ready to:
  • Create an App Service Plan and deploy a web app.
  • Create a private endpoint connecting the web app to your VNet.
  • Verify the private endpoint is provisioned and approved.
Create App Service Plan and web app

An App Service Plan defines the compute resources (CPU, memory, pricing tier) for your web apps. You need one before you can deploy the app itself.

  • Create a B1 (Basic) Linux App Service Plan by running this command:
az appservice plan create \
  --name pe-asp \
  --resource-group pe-appservice-rg \
  --sku B1 \
  --is-linux

What does this command do?

  • --name pe-asp names your App Service Plan.
  • --sku B1 selects the Basic Small tier, which supports private endpoints at minimal cost.
  • --is-linux creates a Linux-based plan, which is required for the Node.js runtime.
  • You should see JSON output with "provisioningState": "Succeeded" confirming the plan was created.
  • Deploy a web app on this plan by running:
az webapp create \
  --name pe-webapp-$RANDOM \
  --resource-group pe-appservice-rg \
  --plan pe-asp \
  --runtime "node:20LTS"

What does this command do?

This creates a new web app with the Node 20 LTS runtime on your Linux plan.

  • --name pe-webapp-$RANDOM generates a globally unique name. Web app names must be unique across all of Azure.
  • --runtime "node:20LTS" sets the built-in Node.js 20 LTS runtime stack.

Note your web app name

The command output includes a "defaultHostName" field (e.g. pe-webapp-12345.azurewebsites.net). Note the app name portion before .azurewebsites.net. You will need it for the rest of the project.

Seeing a name conflict error?

If the random name collides with an existing app, re-run the command. The $RANDOM variable generates a new number each time.

help me troubleshoot a name conflict when creating an Azure web app

Create the private endpoint

A private endpoint projects a private IP address from your VNet into the App Service. Traffic to that IP stays entirely within the Azure backbone network.

  • Retrieve the resource ID of your web app by running:
id=$(az webapp list \
  --resource-group pe-appservice-rg \
  --query '[].id' \
  --output tsv)

What does this command do?

This queries all web apps in your resource group and stores the resource ID in a shell variable called id. The private endpoint create command needs this full resource ID to know which service to connect to.

  • Create the private endpoint by running:
az network private-endpoint create \
  --connection-name pe-connection \
  --name pe-endpoint \
  --private-connection-resource-id $id \
  --resource-group pe-appservice-rg \
  --subnet subnet-1 \
  --group-id sites \
  --vnet-name pe-vnet

What does this command do?

  • --name pe-endpoint names your private endpoint resource.
  • --connection-name pe-connection names the service connection between the endpoint and the App Service.
  • --private-connection-resource-id $id points to the web app you just created.
  • --group-id sites specifies the App Service sub-resource type for Private Link connectivity.
  • --subnet subnet-1 and --vnet-name pe-vnet place the endpoint's NIC and private IP in your workload subnet.

This command takes 30-60 seconds. When it completes, you should see JSON output confirming the endpoint was created.

Command timing out or failing?

Ensure the $id variable is not empty. Run echo $id to check. If it is blank, the previous az webapp list command did not find your web app. Confirm the app exists in pe-appservice-rg by re-running it.

help me debug why my private endpoint create command is failing

Verify the private endpoint connection

You need to confirm two things: the endpoint provisioned successfully, and the App Service automatically approved the connection.

  • Check the endpoint status by running:
az network private-endpoint show \
  --name pe-endpoint \
  --resource-group pe-appservice-rg \
  --query '{provisioningState:provisioningState, connectionStatus:privateLinkServiceConnections[0].privateLinkServiceConnectionState.status}' \
  --output table

What should I see?

The output should show:

  • provisioningState as Succeeded (the Azure resource deployed without errors).
  • connectionStatus as Approved (the App Service accepted the private link connection automatically).

Because you own both the private endpoint and the App Service, Azure auto-approves the connection. In cross-tenant scenarios, the service owner would need to approve manually.

Seeing Pending instead of Approved?

If the status shows Pending, wait 30 seconds and re-run the show command. Auto-approval can take a moment to propagate. If it stays Pending, verify the web app and endpoint are in the same subscription.

help me understand why my private endpoint connection is stuck in Pending

Your private endpoint is live with a private IP from subnet-1. Next up, you will configure DNS so that your web app's hostname resolves to this private IP instead of the public one.

Configure Private DNS Integration

Your private endpoint has a private IP, but there is a problem. Right now, nothing inside your VNet knows how to reach your web app using its hostname.

When a machine tries to resolve pe-webapp-<unique>.azurewebsites.net, public DNS still points to the App Service's public IP. In this step, you will create a Private DNS Zone that overrides that resolution inside the VNet, making the hostname resolve to your private endpoint IP instead.

In this step, get ready to:
  • Create a private DNS zone and link it to your VNet.
  • Attach a DNS zone group to your private endpoint for automatic A record management.
  • Verify that DNS records were auto-created for your app and its SCM endpoint.
Create the private DNS zone

A Private DNS Zone is a DNS namespace that only your VNet can see. By creating one named privatelink.azurewebsites.net, you tell Azure to resolve any App Service private link hostname to the IP you control.

  • Create the private DNS zone by running this command:
az network private-dns zone create \
  --resource-group pe-appservice-rg \
  --name "privatelink.azurewebsites.net"

What does this command do?

This creates a DNS zone named privatelink.azurewebsites.net inside your resource group. The zone is private by default, meaning only VNets you explicitly link to it can use it for name resolution.

  • Link the zone to your VNet by running this command:
az network private-dns link vnet create \
  --resource-group pe-appservice-rg \
  --zone-name "privatelink.azurewebsites.net" \
  --name pe-vnet-link \
  --virtual-network pe-vnet \
  --registration-enabled false

What does this command do?

The --registration-enabled false flag means the zone will not auto-register VM hostnames. You only need it to resolve private endpoint addresses, not to register every machine in the VNet.

The link name pe-vnet-link associates your pe-vnet with the zone so any VM inside that VNet can resolve *.privatelink.azurewebsites.net addresses.

  • Confirm both commands succeeded by checking for provisioningState: Succeeded in the output of each command.

Seeing a 'not found' error?

Double check that your resource group name is pe-appservice-rg and your VNet name is pe-vnet. These must match exactly what you created in Step 1.

help me troubleshoot a 'not found' error when creating a private DNS zone link in Azure CLI

Create a DNS zone group

A DNS Zone Group connects your private endpoint to the DNS zone. When attached, Azure automatically creates and maintains A records in the zone. This means you never have to manually add or update DNS entries when the private endpoint IP changes.

  • Attach a DNS zone group to your private endpoint by running this command:
az network private-endpoint dns-zone-group create \
  --resource-group pe-appservice-rg \
  --endpoint-name pe-endpoint \
  --name pe-dns-zone-group \
  --private-dns-zone "privatelink.azurewebsites.net" \
  --zone-name webapp

What does this command do?

The --zone-name webapp parameter is a friendly label for the zone configuration within the group. It does not need to match any existing resource name.

Once the zone group is created, Azure automatically inserts two A records into your privatelink.azurewebsites.net zone: one for your app and one for the SCM (deployment) endpoint. Both point to your private endpoint's IP.

What is the SCM endpoint?

Every App Service has a secondary endpoint at <appname>.scm.azurewebsites.net used for deployment and diagnostic tools (like Kudu). The zone group creates a DNS record for this too, so deployments also route through the private endpoint.

  • Wait for the output to show provisioningState: Succeeded. This confirms the zone group is attached and records are being managed.

Command timing out or failing?

The DNS zone group creation can take 30-60 seconds. If you see a timeout, wait a moment and re-run the command. If you see an error about the private endpoint not being found, verify the endpoint name is pe-endpoint by running az network private-endpoint list --resource-group pe-appservice-rg.

help me fix a DNS zone group creation failure for my Azure private endpoint

Verify DNS records

The zone group should have auto-created A records pointing your app's hostname to the private endpoint IP. Let's confirm.

  • List the A records in your private DNS zone by running this command:
az network private-dns record-set a list \
  --resource-group pe-appservice-rg \
  --zone-name "privatelink.azurewebsites.net" \
  --output table

What should I see?

You should see two A records in the output:

  • One for your web app name (e.g. pe-webapp-<unique>) pointing to a 10.0.0.x IP address.
  • One for the SCM endpoint (e.g. pe-webapp-<unique>.scm) pointing to the same 10.0.0.x IP address.

Both IPs come from your subnet-1 address range (10.0.0.0/24). This proves the zone group is managing DNS records correctly.

Not seeing any A records?

If the list is empty, the DNS zone group may not have attached correctly. Run the following to verify the zone group exists:

az network private-endpoint dns-zone-group list \
  --resource-group pe-appservice-rg \
  --endpoint-name pe-endpoint

If no zone group appears, re-run the az network private-endpoint dns-zone-group create command from the previous substep.

help me debug why my Azure private DNS zone has no A records after creating a zone group

Your private DNS is fully configured. Any machine in pe-vnet will now resolve your App Service hostname to the private endpoint IP instead of the public IP. Next up, you will disable public access entirely and prove the private path works end-to-end from your test VM.

Lock Down Public Access and Validate Connectivity

Your private endpoint is connected and DNS is resolving correctly. But right now, the App Service is still reachable from the public internet.

In this step, you will explicitly disable public access on the App Service and prove that it is only reachable from inside the VNet. This is the difference between having a private endpoint and actually being private.

In this step, get ready to:
  • Disable public network access on the App Service.
  • Validate private connectivity from the test VM via Azure Bastion.
  • Confirm public access returns a 403 Forbidden response.
Disable public network access

Even with a private endpoint attached, Azure App Service allows public traffic by default unless you explicitly disable it. Setting publicNetworkAccess to Disabled ensures that all inbound traffic must flow through the private endpoint.

  • Block all public internet traffic to your App Service by running this command:
az webapp update \
  --resource-group pe-appservice-rg \
  --name [[WEBAPP_NAME="your web app name e.g. pe-webapp-abc123"]] \
  --set publicNetworkAccess=Disabled

What does this command do?

The --set publicNetworkAccess=Disabled flag explicitly blocks all inbound public traffic to your App Service. Without this, the default behaviour is conditional. If a private endpoint exists, public access is implicitly denied, but explicitly setting it to Disabled guarantees consistent behaviour regardless of future configuration changes.

  • Verify the setting took effect by running:
az webapp show \
  --resource-group pe-appservice-rg \
  --name [[WEBAPP_NAME="your web app name e.g. pe-webapp-abc123"]] \
  --query publicNetworkAccess
  • Confirm the output returns "Disabled".

Still seeing null or Enabled?

Make sure you included the --set flag (not --public-network-access) in the update command. Double-check that the --name value matches your web app name exactly.

Help me troubleshoot my publicNetworkAccess setting not updating on my Azure App Service.

Test private connectivity via Bastion

Now you will connect to your test VM inside the VNet and prove that DNS resolves the App Service hostname to the private endpoint IP. This confirms that your private DNS zone is working correctly.

  • Open the Azure portal at https://portal.azure.com.
  • Navigate to your pe-test-vm virtual machine.
  • On the left pane, select Connect, then select Bastion.
  • Enter the admin username and password you configured when creating the VM.
  • Click Connect. The RDP session opens in a new browser tab.

What is Azure Bastion doing here?

Azure Bastion provides a browser-based RDP session over TLS (port 443). Your VM has no public IP, so Bastion is the only way to reach it. This mirrors a real production pattern where jump boxes with public IPs are replaced by Bastion.

Once you are connected to the VM's desktop, you will run a DNS lookup to confirm the private endpoint is resolving correctly.

  • Inside the VM, open PowerShell by clicking the Start menu and typing PowerShell.
  • Run the following DNS lookup command:
nslookup [[WEBAPP_NAME="your web app name e.g. pe-webapp-abc123"]].azurewebsites.net
  • Confirm the output shows a CNAME alias pointing to privatelink.azurewebsites.net and resolves to a private IP address in the 10.0.0.x range (from your subnet-1).

What should the nslookup output look like?

You should see your app's hostname resolve to a CNAME like <yourapp>.privatelink.azurewebsites.net with an IP address from the 10.0.0.0/24 range. This proves that the private DNS zone is intercepting the lookup and returning the private endpoint IP instead of the public Azure IP.

  • Open a browser inside the VM (Edge is pre-installed on Windows Server 2022).
  • Navigate to your app's URL:
https://[[WEBAPP_NAME="your web app name e.g. pe-webapp-abc123"]].azurewebsites.net
  • Confirm the default App Service welcome page loads successfully.

First page load may be slow

Windows Server VMs accessed via Bastion can be sluggish on first use. If the page takes 10-15 seconds to load, that is normal. The key confirmation is that it loads at all, because traffic is flowing through the private endpoint.

Page not loading inside the VM?

Check that your nslookup returned a 10.0.0.x IP. If it returned a public IP, the VNet link to your private DNS zone may not be configured correctly. Verify the zone link exists with az network private-dns link vnet list.

Help me troubleshoot why my App Service page is not loading when accessed from inside the VM via the private endpoint.

Confirm public access is blocked

The final proof that your private endpoint configuration is complete: the App Service must be unreachable from the public internet.

  • Switch back to your local machine's browser (not the Bastion session).
  • Navigate to your App Service URL:
https://[[WEBAPP_NAME="your web app name e.g. pe-webapp-abc123"]].azurewebsites.net
  • Confirm you receive a 403 Forbidden response.

Why 403 and not a timeout?

Azure returns a 403 Forbidden rather than timing out because the App Service front-end still receives the request at the DNS level, but the publicNetworkAccess=Disabled setting rejects it before it reaches your application code. This is a fast, explicit denial rather than a silent drop.

Still seeing the app load publicly?

DNS caching on your local machine may serve a stale result. Try opening the URL in an incognito window or clear your DNS cache. On macOS, run sudo dscacheutil -flushcache. On Windows, run ipconfig /flushdns.

If the page still loads after flushing, verify that az webapp show --query publicNetworkAccess returns "Disabled". Changes can take a minute to propagate.

Help me figure out why my App Service is still publicly accessible after disabling public network access.

Secret mission

Harden with Network Policies and Monitoring

Your private endpoint is working, but in production you need more. Enable NSG-based network policies on the private endpoint subnet, restrict traffic to HTTPS only, and set up Network Watcher connection monitoring with diagnostic logging to prove your security posture.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project uses paid Azure resources that accumulate charges every hour they remain deployed.

Cost warning

Your deployed resources cost approximately $5.50 per day while running. Azure Bastion alone charges ~$0.19/hr from the moment it is deployed, regardless of usage. The App Service Plan, VM, Private Endpoint, and Public IP add further hourly charges.

If you are not actively using these resources, delete them to avoid unexpected charges on your Azure subscription.

Resources you used:

  • Resource group pe-appservice-rg containing all project resources.
  • Azure Bastion host pe-bastion (~$0.19/hr).
  • Virtual Machine pe-test-vm (Standard_B2s, ~$0.02/hr).
  • App Service Plan pe-asp (B1 tier, ~$0.018/hr).
  • Private Endpoint pe-endpoint ($0.01/hr).
  • Public IP bastion-pip (~$0.005/hr).
  • VNet pe-vnet, subnets, Private DNS zone, DNS zone group, NSG, Log Analytics workspace, and connection monitor.

Keep everything running

No action needed. Choose this if you are still actively building or experimenting with private endpoint configurations.

  • All resources remain deployed and accessible in the pe-appservice-rg resource group.
  • Costs will accumulate at approximately $5.50 per day.
  • You can return to the Azure Portal or CLI at any time to continue working with your private endpoint setup.

Pause - I'll come back to this later

Shut down the VM to save compute costs while keeping all other resources intact. Bastion and the App Service Plan will continue charging.

  • Deallocate the VM to stop compute charges by running:
az vm deallocate --resource-group pe-appservice-rg --name pe-test-vm
  • The VM's OS disk still incurs a small storage charge, but compute billing stops.
  • Bastion (~$0.19/hr), the App Service Plan (~$0.018/hr), the Private Endpoint ($0.01/hr), and the Public IP (~$0.005/hr) continue to charge while deployed.
  • When you are ready to resume, start the VM again by running:
az vm start --resource-group pe-appservice-rg --name pe-test-vm

Delete - I don't want to use this again

Remove all project resources permanently. This is the recommended option if you have finished the project.

  • Delete the entire resource group and everything inside it by running:
az group delete --name pe-appservice-rg --yes --no-wait

What does this command do?

This single command deletes the resource group and every resource it contains: the VNet, subnets, Bastion host, Public IP, VM, App Service Plan, Web App, Private Endpoint, Private DNS zone, VNet link, DNS zone group, NSG, Log Analytics workspace, and connection monitor.

The --yes flag skips the confirmation prompt. The --no-wait flag returns control to your terminal immediately while Azure deletes resources in the background.

  • Verify the resource group is being deleted by running:
az group list --query "[?name=='pe-appservice-rg']" --output table
  • If the group still appears, its provisioningState will show Deleting. Once deletion completes, the group will no longer appear in the list.

Nice Work!

Nice Work!

You just locked down an Azure App Service behind a private endpoint, proving that PaaS services can operate with zero public internet exposure.

You've learned how to:

  • Build a segmented virtual network with dedicated subnets and deploy a private endpoint connecting an App Service to a private IP within your VNet.
  • Configure private DNS resolution using DNS zone groups for automatic A record management across both app and SCM endpoints.
  • Disable public network access and validate end-to-end private connectivity from a test VM via Azure Bastion, confirming DNS resolution and HTTP access over the private link.
  • Secret Mission: Hardened the deployment with NSG network policies on the private endpoint subnet and set up Network Watcher connection monitoring with diagnostic logging.

Ready to quiz yourself?