Private Endpoints & DNS Resolution Lab (AZ-500 Study Series)

---

In this blog:

• Verifying Private Endpoint Configuration.

• Private DNS Resolution Test.

• Testing Connectivity From Inside the VM.

• Confirming Public Access Is Blocked.

• Subnet & NSG Behaviour.

• 🎉 End of Networks Lab!

---

This lab is the final part of my Azure Networking mini-series and builds directly on my previous NSG Testing lab. Here, I validate how Azure Private Endpoints restrict public access while allowing secure internal connectivity from a VM inside a VNet.

This test uses the storage account created earlier in my Environment Setup Lab—so if you haven’t read that one yet, start there.

➡️ Click here to see my blog on setting up the Azure environment for this lab.

➡️ Click here to see my blog on NSG testing in Azure.

---

Verifying Private Endpoint Configuration

My storage account was deployed with a private endpoint mapped to the backend subnet.

Here’s the deployment configuration:

Storage Account Deployment.

To start testing, I SSH into my VM from PowerShell:

ssh -i "C:\Users\shone\Documents\vm-frontend_key_1117.pem" shonep@20.162.93.224

Once inside the VM, we can begin testing private DNS and private network routing.

---

Private DNS Resolution Test

The first test is to confirm that the VM resolves the storage account to a private IP, not the public Azure endpoint.

Running:

nslookup <storageaccount>.blob.core.windows.net

Results:

nslookup command.

✔️ SUCCESS — DNS correctly resolves to the privatelink FQDN and a private IP from the backend subnet.

This proves that private DNS zone linking is working as expected.

---

Testing Connectivity From Inside the VM

Azure Storage blob endpoints don’t respond to simple GET requests on the root, so we expect HTTP method errors — but these errors still confirm network reachability.

Using cURL:

curl -I https://<storageaccount>.blob.core.windows.net

cURL command and 400 error.

On the VM, I received:

400 Bad Request and 405 Method Not Allowed

cURL command and 405 error.

These are expected because:

• The blob service root doesn’t accept certain HTTP methods.

• The response proves that the VM successfully reached the storage account via the private endpoint.

No timeout → no public routing → private endpoint is being used correctly.

---

Confirming Public Access Is Blocked

To verify security, I repeated the same request from my laptop, which is outside the VNet.

curl -I https://<storageaccount>.blob.core.windows.net

This time I received:

400 InvalidHeaderValue

400 error when connecting from my laptop.

This confirms:

• The request reached Azure Storage, but

• Azure rejected it because the storage account is configured with Public Network Access = Disabled

This is correct behaviour — even though the VM can reach the storage account privately, the public internet cannot access it.

---

Subnet & NSG Behaviour

Throughout these tests:

• The VM sits in the frontend subnet, with its own NSG

• The private endpoint sits in the backend subnet, isolated and locked down

• All traffic flowed through the private IP and private DNS zone

No public traffic was used at any point.

This validates:

✔️ VNet integration✔️ Private endpoint routing✔️ Private DNS resolution✔️ NSG consistency across subnets

---

🎉 End of Networks Lab!

With this final private endpoint validation, the Networking section of my AZ-500 practice labs is complete.

I now have:

• Environment Setup Lab

• NSG Testing Lab

• Private Endpoint & DNS Lab

Next week, I’ll be moving on to Identity & Access Management—covering Azure AD roles, PIM, role assignments, and identity security.

---