Part 5: Azure Public vs Private Access

Test Azure Storage access through public and private endpoints.

Introduction

30 Second Summary

A valid key can unlock a door only when there is an open route to reach it. Cloud access works the same way.

In this project, you will build a connectivity lab around one private blob in Azure Storage. You will test the same data through a public endpoint before moving access to a private endpoint.

What You'll Build

You will watch one blob load in your browser before seeing it blocked with a 403. You will then read it from a virtual machine inside an Azure Virtual Network.

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

A repeatable public access test where a short-lived read-only SAS URL loads your private blob before the same request is denied by storage network rules.
A working private access path where the storage hostname resolves to a private IP before a VM retrieves the blob with public access disabled.
A four-scenario connectivity decision card that helps you choose between public endpoints, private endpoints, Azure VPN Gateway, and ExpressRoute.
Secret Mission: Temporarily enable both network paths to prove that public and private access can coexist before restoring private-only access.

Are there any prerequisites?

You need a Windows computer plus an Azure subscription with Owner access. You also need permission to create and delete resources in East US 2 through the Azure portal.

Before We Start

This checkpoint gives your access experiment a clear purpose before you create any resources. You will carry that purpose through each connectivity test.

Set Up the Connectivity Lab

The access experiment needs one cleanup boundary before any Azure resources appear. A resource group keeps each test tied to the same lab.

That boundary makes the lab easier to price. It also turns cleanup into one resource-group deletion.

In this step, you will confirm your Owner-access subscription in the Azure portal. You will create a harmless proof file with Windows PowerShell.

In this step, get ready to:

Confirm the Owner-access Azure subscription for the lab.
Create rg-az900-connectivity-lab in East US 2.
Create $env:TEMP\connectivity-proof.txt with the exact proof text.

Verify the Azure workspace

Every Azure resource belongs to a subscription. Checking your Owner role now prevents permission failures when the lab starts creating services.

Press the Windows key to open Windows search.
Type Microsoft Edge and press Enter.
Go to the Azure portal.

Your Account May Verify Your Identity

Account verification can feel like a pause, but it is part of your normal Azure sign-in. Your account may request an additional identity check.

Sign in with the Azure account linked to your subscription.
Complete any identity check requested for your account.

You should see the Azure portal home page for your account.

Enter Subscriptions in the portal search box.
Select Subscriptions from the results.
Select the subscription you plan to use for this lab.
Select Access control (IAM) in the subscription menu.
Select the Check access tab.
Select View my access.

The assignments pane should list Owner at the subscription scope. That access check clears the way for the rest of the lab.

Owner Access Missing?

Check that you selected the subscription linked to the Azure account you used to sign in.
Ask an existing subscription Owner to grant your account the Owner role if it is missing.
Use the correct Azure directory if your account belongs to more than one directory.
Help me verify my Owner role in the Azure portal.

Create the cleanup boundary

Every cloud resource in this project belongs inside rg-az900-connectivity-lab. Deleting that group later removes the contained lab resources as one cleanup operation.

Why Use One Resource Group?

The resource group gives the lab a clear ownership boundary. It also makes the final cleanup easy to verify.

Every regional resource in this lab uses East US 2. Using one region keeps the network path consistent.

Enter Resource groups in the portal search box.
Select Resource groups from the results.
Select + Create.
Choose your confirmed subscription in the Subscription field.
Enter rg-az900-connectivity-lab in the Resource group field.

The Basics page should now show your confirmed subscription with the lab resource-group name.

Select East US 2 in the Region field.
Select Review + create.

The review page should show rg-az900-connectivity-lab in East US 2 under your confirmed subscription.

Select Create.

You should see a confirmation that Azure created the resource group.

Enter rg-az900-connectivity-lab in the portal search box.
Select rg-az900-connectivity-lab from the results.
Confirm that the resource group region is East US 2.
Confirm that the resource group contains no resources yet.

Your cleanup boundary is ready for every Azure resource in this lab.

Can't Find the Resource Group?

Check that the portal is showing the same subscription you selected during creation.
Search for the exact name rg-az900-connectivity-lab.
Create the group again if the earlier creation screen did not show a successful confirmation.
Help me find my Azure resource group.

Create the proof file on Windows

The later blob tests need content whose result is obvious. One short line makes a successful request easy to distinguish from a blocked request.

Press the Windows key to open Windows search.
Type Windows PowerShell and press Enter.

Before you run the commands, what exact line do you expect the second command to print?

Create the proof file and print its contents by running these commands:

Set-Content -Path "$env:TEMP\connectivity-proof.txt" -Value "AZ-900 connectivity proof"
Get-Content -Path "$env:TEMP\connectivity-proof.txt"

What Do These Commands Do?

The Set-Content command writes the exact proof text into $env:TEMP\connectivity-proof.txt.
The $env:TEMP value points to your Windows temporary-file folder.
The Get-Content command reads the file back so you can verify its contents.

Confirm that Windows PowerShell prints AZ-900 connectivity proof.
Keep the Windows PowerShell window open for the next step.

Proof Text Missing?

Check that both commands use the path $env:TEMP\connectivity-proof.txt.
Check that the first command contains the value AZ-900 connectivity proof.
Run both commands again if only the first command was entered.
Help me create the proof file in Windows PowerShell.

✔️ Awesome, I've got everything!

Great. Your proof file contains the exact line that the connectivity lab will upload.

ⓧ I'd like to double check the full code

The complete contents of your proof file should match this one-line reference.

AZ-900 connectivity proof

That is the lab foundation complete. Your Azure cleanup boundary is ready. Your local proof file is ready too.

Your cleanup boundary and proof file are ready. Next, you will upload the file to Azure Storage and prove that its public endpoint works.

Prove the Public Endpoint Works

Your resource group and proof file are ready. The connectivity experiment now needs a successful request from outside Azure as its baseline.

You will place the proof file in Azure Storage as a private blob.

A short-lived read-only shared access signature (SAS) authorizes the browser. The public endpoint provides the network route.

In this step, get ready to:

Create a Standard General Purpose v2 storage account for public access.
Upload the proof file to a private container.
Use a short-lived read-only SAS URL to load the proof text through the public endpoint.

Create a minimal storage account

A storage account gives your proof blob a stable Azure address. Enabling public network access lets your Windows browser reach that address.

Creating the account begins a small billable Azure resource. The cleanup section removes the entire lab resource group when testing is complete.

In the Azure portal tab from earlier, search for Storage accounts.
Select Storage accounts from the search results.
Select Create.
Choose the confirmed Owner-access subscription.
Select rg-az900-connectivity-lab for the resource group.

The creation form now ties the storage account to the cleanup boundary from the previous step.

Select East US 2 for the region.

Storage account names must be globally unique, so finding an available one can take a couple of tries.

Enter <storage-account-name> as a globally unique lowercase name.
Choose Standard performance.
Choose Locally-redundant storage (LRS) redundancy.

Standard performance keeps the account on the standard storage tier. Locally-redundant storage keeps its copies in one region.

Select Review + create.
Select Create after validation completes.
Wait for the deployment to complete.
Return to rg-az900-connectivity-lab from earlier.
Select <storage-account-name> from the resource list.

You now have a Standard General Purpose v2 storage account in East US 2.

Select Security + networking in the storage account menu.
Select Networking.
Select Manage.
Choose Enable.
Choose Enabled from all networks.

The page now shows the public network path you need for the baseline test.

Select Save.

The storage account now accepts connections through its public endpoint from all networks. Authorization still controls access to private data.

What Does Public Network Access Allow?

Enabled from all networks makes the storage account's public endpoint reachable from your browser. It does not make a private blob anonymous.

🙋‍♀️ Can't Create or Update the Account?

Choose a different globally unique lowercase name if Azure rejects the first account name.
Confirm that rg-az900-connectivity-lab is selected as the resource group.
Confirm that East US 2 is selected as the region.
Help me troubleshoot my Azure Storage account setup.

Upload the private blob

A private container rejects anonymous access to its blobs. The SAS you create next grants narrow access to this single proof file.

Select Data storage in the storage account menu.
Select Containers.
Select + Container.
Enter proof as the container name.
Keep Private (no anonymous access) as the access level.
Select Create.

You'll see proof in the container list. That private container is ready for the lab file.

Select the proof container.
Select Upload.
Browse to %TEMP%\connectivity-proof.txt in the Windows file picker.
Select connectivity-proof.txt.
Select Upload.

You'll see connectivity-proof.txt listed inside proof. Your private proof blob is now ready for controlled access.

Blob Missing From the Container?

Confirm that the selected local file is %TEMP%\connectivity-proof.txt.
Confirm that the upload destination is the proof container.
Retry the upload after confirming that connectivity-proof.txt still exists in the Windows file picker.
Help me troubleshoot my Azure blob upload.

Generate and test a short-lived SAS URL

A SAS URL acts as a temporary credential. Anyone with the URL can use its granted permission until it expires.

This is the sensitive part of the lab, so handle the URL carefully. Its short expiry keeps the risk window small.

Right-click connectivity-proof.txt in the container.
Select Generate SAS.
Choose Account key for Signing method.
Grant only Read under Permissions.
Choose HTTPS under Allowed protocols.

The SAS is now scoped to reading this blob over an encrypted connection.

Set Expiry to about two hours ahead.
Set Start to 15 minutes in the past only if the form requires a start time.
Select Generate SAS token and URL.
Copy Blob SAS URL to a temporary secure note.

What Do These SAS Settings Do?

Account key signs the SAS so Azure Storage can verify it.
Read limits the SAS to retrieving the blob.
HTTPS protects the request while it travels across the network.
The short expiry limits how long the URL remains usable.

Before you load the URL, make a mental prediction about what the browser will display.

Open a fresh Microsoft Edge InPrivate window.
Paste the Blob SAS URL into the address bar.
Press Enter.

You'll see AZ-900 connectivity proof displayed on the page. That's your baseline working through the public blob endpoint.

What Did This Request Prove?

The SAS supplied valid read authorization for the private blob. The enabled public endpoint supplied a reachable network path from your Windows computer.

🙋‍♀️ Proof Text Not Loading?

Confirm that public network access remains set to Enabled from all networks.
Generate a new SAS if the copied URL is incomplete or expired.
Confirm that the new SAS grants only Read access over HTTPS.
Help me troubleshoot my public Blob SAS URL test.

✔️ My public test works

Your fresh InPrivate window displays AZ-900 connectivity proof through the public endpoint.

ⓧ I'd like to double check the setup

The local file at $env:TEMP\connectivity-proof.txt still contains AZ-900 connectivity proof.
The storage account <storage-account-name> is in rg-az900-connectivity-lab in East US 2.
The account uses Standard General Purpose v2 with Locally-redundant storage (LRS).
Public network access is set to Enabled from all networks.
The private proof container contains connectivity-proof.txt.
The uploaded blob contains AZ-900 connectivity proof.
The temporary secure note contains a short-lived read-only HTTPS Blob SAS URL signed with the account key.
The fresh InPrivate test displays the proof text through the public endpoint.

Your public-access baseline is working. Next, you'll keep the same SAS while changing only the public network path.

Block the Public Path

Your read-only SAS URL already proves that the private blob can be authorized through the public endpoint from your Windows computer. That success gives you a clean baseline.

This step changes only the network rule in Azure Storage. Keeping the valid SAS unchanged holds authorization constant while the network path changes.

In this step, get ready to:

Disable public network access for the existing storage account.
Retest the unchanged Blob SAS URL from a fresh InPrivate window.

Disable public network access

Azure Storage network rules control whether requests can use the storage account's public endpoint. Disabling public network access gives the same blob a different network boundary.

Switch back to the storage account page in the Azure portal tab from earlier.
Select Security + networking in the storage account menu.
Select Networking.
Select Manage.
Choose Disable.
Select Save.

Good work. Your storage account now shows public network access as Disabled.

Why keep the SAS unchanged?

The SAS still carries the same read permission. Its expiry is unchanged.

Changing one network setting creates a controlled comparison. Any difference in the next request comes from network reachability.

Reproduce the blocked request

A fresh browser session prevents an earlier page from being mistaken for a new successful request. The unchanged URL keeps the authorization side of the experiment consistent.

Protect the Live SAS URL

This test uses the same live credential from earlier. Its value stays inside your secure note or the private browser window.

Close the earlier InPrivate window.
Create a fresh Microsoft Edge InPrivate window using the same method as earlier.
Copy the unchanged Blob SAS URL from your secure temporary note.
Paste the unchanged Blob SAS URL into the address bar.

Before the request runs, consider whether valid blob permission can overcome the blocked public path.

Load the page by pressing Enter.

You'll see an HTTP 403 response with an authorization or network access failure. The proof text no longer appears.

That failure is the evidence you needed. The unchanged authorized request can no longer cross the public network boundary.

What Does This 403 Prove?

The SAS still authorizes read access to the private blob. Azure Storage network rules independently decide whether the request can reach that blob through the public endpoint.

A successful request needs valid authorization plus permitted network reachability.

Keep the lab in this blocked state without adding an IP allow rule, service endpoint, or private endpoint.

Still Seeing the Proof Text?

Check that the storage account's Networking page shows Disable.
Select Disable if Enable is still selected.
Select Save before repeating the test in a fresh InPrivate window.

Help me diagnose why the blob still loads after public network access was disabled.

Your controlled comparison is complete. Next, you'll create a private path that gives an internal client a permitted route to the same blob.

Build the Private Path

The unchanged SAS URL proved that authorization alone cannot cross a blocked public network path. Your external request now returns 403 because the storage service has no permitted route from your Windows computer.

You will use Azure Private Link to create a private endpoint with a private IP inside an Azure Virtual Network. Azure Private DNS will map the storage hostname to that private address for clients inside the VNet.

In this step, get ready to:

Create vnet-private-access with its client subnet.
Connect the storage blob service through pe-storage-blob.
Verify private DNS integration for the endpoint.

Create the client virtual network

A virtual network provides the private address space for your internal client. A subnet reserves part of that space for the private endpoint plus the VM you create later.

Switch back to the Azure portal tab from earlier.
Enter Virtual networks in the search bar at the top of the portal.
Select Virtual networks under the search results.
Select + Create.
Select your confirmed Owner-access subscription.
Select rg-az900-connectivity-lab as the resource group.
Enter vnet-private-access as the virtual network name.
Select East US 2 as the region.

Keep the Network Together

Using rg-az900-connectivity-lab keeps every lab resource inside the same cleanup boundary. Using East US 2 keeps the network path within one region.

Select IP Addresses.
Select the default subnet row.
Enter snet-clients as the subnet name.
Set the starting address to 10.0.0.0.
Set the subnet size to /24 (256 addresses).
Select Review + create.
Select Create after validation passes.
Wait for the virtual network deployment to finish.

Good progress. vnet-private-access now provides the address space for the private side of your comparison.

The next step uses the VM agent to return Run Command results over port 443. Enabling default outbound access on this temporary lab subnet gives that agent the required outbound path.

Open vnet-private-access from the completed deployment.
Select Subnets.
Select snet-clients.
Set Default outbound access to Enabled.
Select Save.

The subnet now shows 10.0.0.0/24 with default outbound access enabled.

VNet Settings Not Saving?

Confirm that vnet-private-access belongs to rg-az900-connectivity-lab in East US 2.
Check that snet-clients uses the exact address range 10.0.0.0/24.
Ask for help if the subnet settings still fail to save: Help me troubleshoot my Azure VNet subnet configuration.

Create the blob private endpoint

A private endpoint is a network interface that connects one Azure service to your VNet through a private address. This endpoint targets the existing blob service without changing its disabled public network setting.

Enter Private endpoints in the search bar at the top of the portal.
Select Private endpoints under the search results.
Select + Create.
Select your confirmed Owner-access subscription.
Select rg-az900-connectivity-lab as the resource group.
Enter pe-storage-blob as the private endpoint name.
Select East US 2 as the region.

What This Endpoint Changes

The endpoint adds a private network interface to snet-clients. Public network access remains disabled on the storage account.

Select Resource.
Keep Connect to an Azure resource in my directory selected.
Select Microsoft.Storage/storageAccounts as the resource type.
Choose your storage account from earlier.
Set Target subresource to blob.

Why Target the Blob Service?

The private endpoint applies to the selected storage subresource. Choosing blob gives the proof blob its private network path.

Select Virtual Network.
Select vnet-private-access as the virtual network.
Select snet-clients as the subnet.
Keep dynamic private IP allocation selected.
Select DNS.
Keep Integrate with private DNS zone set to Yes.
Select Review + create.
Select Create after validation passes.

Private endpoint provisioning can take a few minutes, so a short wait on the deployment screen is expected.

Wait for the private endpoint deployment to finish.
Open pe-storage-blob from the completed deployment.
Confirm that the private endpoint connection is approved.

That connection is approved. The blob service now has a private entry point inside snet-clients.

Endpoint Not Approved?

Confirm that the selected resource is your storage account from earlier.
Check that Target subresource is set to blob.
Check that the endpoint uses vnet-private-access with snet-clients.
Ask for help if the endpoint remains unapproved: Help me troubleshoot my Azure Storage private endpoint.

Inspect the endpoint and DNS records

The private DNS zone supplies an A record that maps the storage account name to the endpoint address. Its VNet link makes that mapping available to clients inside vnet-private-access.

Locate the private IP address in the pe-storage-blob overview.
Confirm that the address belongs to 10.0.0.0/24.
Record the private endpoint IP here: <private-endpoint-ip>.

Before you inspect the DNS recordsets, do you expect the storage account record to point to the same private address as the endpoint?

Enter Private DNS zones in the search bar at the top of the portal.
Select Private DNS zones under the search results.
Open privatelink.blob.core.windows.net.
Select Recordsets.
Find the A record named after your storage account.

You should see the storage account record point to <private-endpoint-ip>. This matching address shows that private DNS targets the endpoint network interface.

Compare the record value with the private endpoint address you recorded.
Select Virtual network links.
Confirm that vnet-private-access appears as a linked virtual network.

You should now see an A record for your storage account with an address from 10.0.0.0/24. The zone also shows its link to vnet-private-access.

What Does the Matching Address Prove?

The endpoint provides the private IP. The DNS record directs the normal storage hostname to that address inside the linked VNet.

This DNS mapping prepares an internal client to use the private path while the public path stays blocked.

🙋‍♀️ Missing the DNS Record?

Confirm that private DNS integration was set to Yes during endpoint creation.
Check that you opened privatelink.blob.core.windows.net.
Confirm that the record name matches your storage account.
Ask for help if the record or VNet link is missing: Help me troubleshoot my private endpoint DNS integration.

Your private endpoint now has an approved connection plus a matching DNS record. Next up, you will place a VM inside the VNet to prove that the blob remains reachable while public access stays disabled.

Prove Private Access and Choose the Hybrid Path

Your private endpoint now supplies the network route that the external browser was missing. Its DNS record connects the normal storage hostname to a private address inside the VNet.

Configuration becomes proof when a client inside the network resolves that hostname privately. The client must also read the blob while public network access stays blocked.

In this step, you will place a Windows Server VM inside your Azure Virtual Network. Run Command then tests the storage hostname from inside the network.

In this step, get ready to:

Create a private Windows Server VM inside the existing client subnet.
Run a PowerShell proof from inside the VNet.
Choose the correct path for four Azure connectivity scenarios.

Create a private test VM

Azure Virtual Machines supplies the internal client for this test. The VM agent executes the proof through the portal without exposing an inbound management port.

This VM begins accruing compute charges while it runs. The cleanup section gives you one resource-group deletion after the test.

Return to the Azure portal tab from earlier.
Search for Virtual machines.
Select + Create.
Select Azure virtual machine.

The VM creation form opens with the basic resource settings ready for your choices.

Select your confirmed subscription.
Select rg-az900-connectivity-lab as the resource group.

These choices place the VM inside the same cleanup boundary as the rest of the lab.

Enter vm-private-client as the virtual machine name.
Select East US 2 as the region.

The VM now has a fixed identity and region for the private-path test.

Choose Windows Server 2022 Datacenter - x64 Gen2 as the image.
Choose Standard_B1s as the size.

The selected image supports the PowerShell test through the Windows VM agent.

Choose Standard as the security type.
Choose password authentication.

These settings match the small test client required for this lab.

Provide temporary administrator credentials that satisfy the portal password rules.
Set Public inbound ports to None.

Public inbound access is now closed for the VM.

Select the Disks tab.
Choose Standard HDD (locally-redundant storage) for the OS disk.

The VM now uses the lower-cost disk type selected for this short test.

Select the Networking tab.
Select vnet-private-access as the virtual network.

The VM is now attached to the VNet that contains the storage private endpoint.

Select snet-clients as the subnet.
Set Public IP to None.

The VM now has an internal network path with no public IP.

Select Review + create.
Select Create after validation passes.

Provisioning can take a few minutes while Azure builds the VM. A short wait here is normal.

Return to Virtual machines after the deployment completes.
Select vm-private-client.
Wait until the provisioning state shows Succeeded.
Confirm that the VM agent status shows Ready.

That is the private client ready. It can now run the storage test without a public IP.

VM Agent Not Ready?

Refresh the VM overview after provisioning reaches Succeeded.
Confirm that vm-private-client is connected to snet-clients.
Confirm that default outbound access remains enabled for snet-clients.
Help me troubleshoot the VM agent status.

Run the proof from inside the VNet

Azure Private DNS participates in name resolution for the normal storage hostname inside the linked VNet. This location-aware behavior is called split-horizon DNS.

Run Command sends the test through the VM agent. The request therefore starts inside snet-clients.

Return to the vm-private-client page from earlier.
Select Operations in the left menu.
Select Run command.
Choose RunPowerShellScript.

The script editor now gives you a way to run PowerShell from inside the private VM.

Paste the following script into the script editor:

$storageName = '<your-storage-account-name>'
$sasUrl = '<paste-your-Blob-SAS-URL>'

Clear-DnsClientCache
Resolve-DnsName -Name "$storageName.blob.core.windows.net" -Type A
$response = Invoke-WebRequest -UseBasicParsing -Uri $sasUrl
$response.StatusCode
$response.Content

What Does This Script Do?

The $storageName variable holds the storage account name used to build the normal blob hostname.
The $sasUrl variable keeps authorization identical to the external browser test.
Clear-DnsClientCache removes cached DNS results before the lookup.
Resolve-DnsName requests the current A record for the storage hostname.
Invoke-WebRequest sends the authorized blob request from inside the VM.
$response.StatusCode prints the HTTP result.
$response.Content prints the blob contents.

Replace <your-storage-account-name> with your storage account name.
Replace <paste-your-Blob-SAS-URL> with the unchanged Blob SAS URL from your secure temporary note.

The two variables now point to the same storage account and authorized blob used in the external test.

The VM agent may take a moment to return the result, so a short pause is expected.

Before you run it, do you expect the normal storage hostname to resolve publicly or privately from this VM?

Select Run.

The DNS output includes an address from 10.0.0.0/24 that matches the private endpoint address.

The next output value is 200. The final output is AZ-900 connectivity proof.

That is the decisive proof. The same valid SAS request succeeds from inside the VNet while public network access stays disabled.

Private Proof Not Returning?

Confirm that vm-private-client is connected to snet-clients.
Confirm that privatelink.blob.core.windows.net remains linked to vnet-private-access.
Confirm that the short-lived Blob SAS URL has not expired.
Help me troubleshoot the private blob test.

Complete the AZ-900 connectivity decision card

A public endpoint serves clients that reach an Azure service through its public interface. A private endpoint gives one PaaS resource a private IP inside a VNet.

Azure VPN Gateway extends a VNet through an encrypted tunnel over the public internet. ExpressRoute extends a network through a private provider connection.

Match the Scenario to the Path

An internet client must reach an Azure service.
A workload inside a VNet must privately reach one Azure PaaS resource.
A branch office needs an encrypted tunnel to an Azure VNet over the internet.
A datacenter needs provider-facilitated private connectivity with predictable latency.

Before you reveal the answers, which connectivity choices do you expect to rely on the public internet?

✔️ I'll match them first

Match each scenario to one of the four connectivity choices.
Switch to the answer tab after you have four matches.

ⓧ Show me the decision card

Internet client to an Azure service: Public endpoint. The service remains reachable through its public interface when authorization and network rules allow the request.
VNet workload to one Azure PaaS resource: Private endpoint. Azure Private Link gives the target resource a private IP inside the VNet.
Branch office to an Azure VNet over the internet: Azure VPN Gateway. The service uses an encrypted IPsec/IKE tunnel across the public internet.
Datacenter to Azure through provider-facilitated private connectivity: ExpressRoute. The connection avoids the public internet and supports predictable latency.

Keep This at Selection Depth

The decision card is the deliverable. No Azure VPN Gateway or ExpressRoute resources belong in this lab.

Azure VPN Gateway can take 45 minutes or more to provision. It also incurs gateway-hour charges.

ExpressRoute requires a circuit. It also requires a gateway and a connectivity-provider relationship.

You have now proved that the authorized blob succeeds through the private path while its public path remains blocked. You can also choose the correct Azure connectivity option from the client's location and network requirements.

Secret mission

Prove Dual Reachability

Can a storage account support public and private paths at the same time? Temporarily enable public access to prove it. Finish by restoring private-only access.

Clean Up Your Resources

The Azure resources in this lab can keep generating charges. Choose whether to keep them briefly, pause the VM, or delete the entire lab.

Cost warning

Immediate cleanup keeps this lab near the estimated cost of $0.05 to $0.15. Prompt deletion is the safest route for keeping the total below $1.

The running VM incurs compute charges. The managed OS disk can continue to incur charges after compute is deallocated.

The private endpoint, Private DNS zone, and storage account can also incur charges. A VM stopped only inside Windows remains allocated.

Resources you used:

Resource group rg-az900-connectivity-lab in East US 2.
An Azure Storage account containing the private proof container and connectivity-proof.txt blob.
An Azure Virtual Network named vnet-private-access with subnet snet-clients.
A private endpoint named pe-storage-blob with its network interface.
An Azure Private DNS zone named privatelink.blob.core.windows.net with its A record and VNet link.
Windows VM vm-private-client with its network interface, network security group, and managed OS disk.
Local proof file $env:TEMP\connectivity-proof.txt on your Windows computer.

Keep everything running

No cleanup action is needed. Choose this only if you plan to repeat the connectivity tests immediately.

Leave public network access set to Disabled on the storage account.
Keep every Azure resource inside rg-az900-connectivity-lab.
Keep the Blob SAS URL in your secure temporary note only until its short expiry.
Remove the expired Blob SAS URL from your secure temporary note.

The lab remains ready for another test. Azure charges continue while these resources exist.

Pause - I'll come back to this later

Shut down VM compute while keeping the lab configuration for later. Storage and networking resources remain available.

Return to the Overview page for vm-private-client in the Azure portal.
Select Stop.
Refresh Overview until the status shows Stopped (deallocated).
Leave public network access set to Disabled on the storage account.
Keep rg-az900-connectivity-lab so its storage and private networking configuration remain available.
Remove the Blob SAS URL from your secure temporary note after it expires.

Your pause worked: VM compute billing has stopped. The managed disk and networking resources can still incur charges.

Delete - I don't want to use this again

Remove all project resources and start fresh.

Deleting the lab removes every Azure resource inside the group. That is the intended reset, while your completed connectivity decision card remains yours to keep.

Return to Resource groups in the Azure portal.
Select rg-az900-connectivity-lab.
Select Delete resource group.
Type rg-az900-connectivity-lab to confirm the target.
Complete the deletion confirmation.
Refresh Resource groups.

You should no longer see rg-az900-connectivity-lab. Its storage account, VM, managed disk, private endpoint, Private DNS zone, VNet, and dependent resources are removed with it.

Delete the local proof file from the Windows PowerShell window you kept open by running this command:

Remove-Item -Path "$env:TEMP\connectivity-proof.txt"

What does this command do?

The Remove-Item command deletes connectivity-proof.txt from your Windows temporary folder. Deleting the Azure resource group does not remove files from your computer.

Confirm that PowerShell returns to its prompt without output.
Delete the Blob SAS URL from your secure temporary note.

Local file already missing?

If PowerShell reports that the path cannot be found, the temporary proof file is already absent.

Help me check why the temporary proof file was not removed.

That completes the cleanup. The billable Azure lab, local proof file, and temporary SAS note are cleared.

Nice Work!

You made it! Your Azure connectivity lab now proves the behavior of one blob across public access versus private access.

What you learned:

Built a public endpoint baseline using a private Azure Storage blob with a short-lived read-only SAS URL. After public network access was disabled, the same authorized browser request returned HTTP 403.
Created a private endpoint through Azure Private Link. Azure Private DNS mapped the storage hostname to a private address inside the Azure Virtual Network. The VM retrieved the blob with HTTP 200 while public access stayed disabled.
Matched internet clients to public endpoints. Matched VNet workloads to private endpoints. Chose Azure VPN Gateway for encrypted branch connectivity over the public internet. Chose ExpressRoute for provider-facilitated private datacenter connectivity.
Completed the optional Secret Mission by temporarily enabling public reachability while the private endpoint stayed active. Restored private-only access after comparing both paths.

Ready to quiz yourself?