Azure Governance, Storage and Networking

Configure Azure storage, networking, and governance controls for a healthcare scenario.

Introduction

30 Second Summary

When a hospital stores your medical records digitally, strict rules govern where that data lives, who can access it, and what happens if a server goes down. Cloud engineers are the people who configure these protections.

In this project, you will build Azure infrastructure for a fictional healthcare company called "Contoso Health Records." You'll configure storage, networking, security, and governance services to understand how they work together and prepare for AZ-900 scenario-based exam questions.

What You'll Build

You will set up a complete Azure environment demonstrating how storage redundancy, virtual network segmentation, network security rules, and governance controls protect sensitive data.

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

A Storage Account configured with geo-redundant storage (GRS) and a Cool access tier, with a private blob container for patient records.
A Virtual Network with two subnets and a Network Security Group enforcing traffic rules on the data subnet.
Three governance controls working together: Azure Policy enforcing tagging compliance, a resource lock preventing accidental deletion, and an Azure RBAC role assignment controlling access.
Secret Mission: Restrict your storage account to only accept traffic from within your virtual network using a service endpoint.

Are there any prerequisites?

You need an existing Azure account (free tier, pay-as-you-go, or student) and a web browser. You should have basic familiarity with navigating the Azure Portal, such as creating resource groups and clicking through menus.

Set Up Your Resource Group and Storage Account

Contoso Health Records needs to store sensitive patient documents in the cloud. Before you can configure networking, security, or governance, you need a place to put your data.

In this step, you will create a resource group to organize your project resources, then set up a storage account configured specifically for a healthcare compliance scenario.

In this step, get ready to:

Create a resource group to organize all your project resources.
Configure a storage account with healthcare-appropriate redundancy and access tier settings.
Set up a private blob container and upload a test file.

Create a resource group

A resource group is a logical container that holds related Azure resources. Everything you build in this project will live inside a single resource group so you can manage and clean up resources easily.

In the Azure Portal search box at the top, type Resource groups and select it from the results.
Click + Create.
Select your subscription from the Subscription dropdown.
In the Resource group field, enter rg-contoso-health.
For Region, select East US (or the region nearest to you).
Click Review + create, then click Create.

What is a resource group?

Think of a resource group like a folder on your computer. It groups related Azure resources together so you can manage permissions, monitor costs, and delete everything at once when you are done.

In this project, rg-contoso-health will contain your storage account, virtual network, and network security group.

Create a storage account with scenario-based settings

A storage account provides a unique namespace for your data in Azure. The settings you choose here directly map to AZ-900 scenario questions about redundancy and access tiers.

In the search box at the top of the portal, type Storage accounts and select it.
Click + Create.

On the Basics tab, fill in the following:

Set Resource group to rg-contoso-health.
Enter a globally unique Storage account name. Use the format contosohealthXXXX where XXXX is a set of random numbers (for example, contosohealth2847). The name must be 3-24 characters, lowercase letters and numbers only.
Set Region to the same region as your resource group (East US or your chosen region).
Set Performance to Standard.
Set Redundancy to Geo-redundant storage (GRS).

Why GRS instead of LRS?

Healthcare data needs geographic disaster recovery. If the entire region goes down, GRS ensures a copy exists in a paired region hundreds of miles away. LRS (Locally-redundant storage) only protects against hardware failures within a single datacenter.

AZ-900 scenario questions frequently test this distinction. When a business requirement mentions compliance, disaster recovery, or geographic redundancy, GRS is the correct choice.

Now click Next until you reach the Advanced tab. Configure the following:

Under the Security section, confirm that Require secure transfer for REST API operations is checked. This enforces HTTPS for all connections.
Set Minimum TLS version to Version 1.2 from the dropdown.
Under the Blob storage section, set Access tier to Cool.

Why Cool instead of Hot or Archive?

Patient records are retained long-term but accessed infrequently. The Cool tier has lower storage costs than Hot, making it ideal for data that sits for 30+ days between accesses.

Hot would be too expensive for archival storage. Archive would be wrong because retrieval takes hours, making it unsuitable for on-demand access. Cool is the correct middle ground that the AZ-900 exam tests in healthcare scenarios.

Click Review + create, then click Create.
Wait for the deployment to complete. You should see a Your deployment is complete message.

Storage account name already taken?

Storage account names must be globally unique across all of Azure. If you see a validation error about the name, try adding different numbers to the end (for example, contosohealth9021).

Help me fix my storage account name error.

Create a blob container and upload a test file

Your storage account is ready. Now you need a container inside it to hold the actual files. A blob container is like a folder within your storage account.

Click Go to resource to open your new storage account.
In the left menu under Data storage, click Containers.
Click + Container.
In the Name field, enter patient-records.
Set Anonymous access level to Private (no anonymous access).
Click Create.

Why Private access?

Patient health data must never be publicly accessible. The Private setting ensures that only authenticated and authorized users can read or write blobs in this container. This is a non-negotiable requirement for healthcare compliance.

Click on the patient-records container to open it.
Click Upload in the toolbar.
Click Browse for files and select any small file from your computer (a simple .txt file works perfectly).
Click Upload.

You should see your file appear in the container's file list.

Don't see the Upload button?

Make sure you clicked into the patient-records container (not just the Containers list). The Upload button appears in the toolbar when you are inside a specific container.

Help me upload a file to my blob container.

Your storage foundation is in place. Next up, you will create a virtual network with segmented subnets to control how traffic flows to and from your data.

Create a Virtual Network with Subnets

Your storage account is set up with the right redundancy and access tier for healthcare compliance. Now it's time to control how resources communicate with each other and the outside world.

In this step, you'll create a Virtual Network with two subnets. This simulates a tiered architecture where frontend web servers and backend data services live in separate network segments.

In this step, get ready to:

Create a virtual network in your resource group with a frontend and data subnet.
Review the network layout and understand how subnet segmentation supports defense-in-depth.

Create the virtual network

A virtual network is the foundation of private networking in Azure. It gives your resources a private address space where they can talk to each other without going over the public internet.

In the Azure Portal search box at the top of the page, type Virtual networks and select it from the results.
Click + Create.

On the Basics tab, fill in the following details:

For Subscription, select your subscription.
For Resource group, select rg-contoso-health.
For Virtual network name, enter vnet-contoso.
For Region, select the same region as your storage account (East US, or whatever region you chose earlier).

Click Next to move past the Security tab.
Click Next again to reach the IP Addresses tab.

The default address space is 10.0.0.0/16. Keep this value. Now you'll configure two subnets inside it.

Select the default subnet that's already listed and click the pencil (edit) icon.
Change the Name to subnet-frontend.
Set Starting address to 10.0.0.0.
Set Subnet size to /24 (256 addresses).
Click Save.

Now add the second subnet for your data tier.

Click + Subnet.
For Name, enter subnet-data.
Set Starting address to 10.0.1.0.
Set Subnet size to /24 (256 addresses).
Click Save.

Click Review + create.
Click Create.

What is the /16 and /24 notation?

This is CIDR notation, which defines how large an address range is. A /16 address space gives you 65,536 addresses for the entire virtual network. Each /24 subnet carves out 256 of those addresses for a specific group of resources.

Think of the VNet as an office building, and each subnet as a separate floor with its own access controls.

Seeing a validation error on the subnet?

Make sure the starting addresses don't overlap. subnet-frontend starts at 10.0.0.0 and subnet-data starts at 10.0.1.0. If the portal shows an overlap error, double check the starting address of each subnet.

Help me fix a subnet address overlap error in my Azure virtual network.

Understand the network layout

Your virtual network is deployed. Let's review what you built and why the two-subnet design matters for security.

Once the deployment finishes, click Go to resource to open vnet-contoso.
In the left menu, click Subnets.

You should see both subnet-frontend (10.0.0.0/24) and subnet-data (10.0.1.0/24) listed in the Subnets blade.

Why two subnets instead of one?

This layout follows the defense-in-depth model that AZ-900 tests heavily. subnet-frontend represents where web servers would live. subnet-data represents where backend data services connect.

Even if the frontend subnet is compromised, the data subnet has its own separate security controls. You'll add those controls in the next step using a Network Security Group.

How does this map to the AZ-900 exam?

The AZ-900 measures your ability to describe virtual networking, including the purpose of Azure virtual networks and subnets. Scenario questions often ask you to choose where to place resources based on security requirements. This two-subnet layout is the exact pattern those questions reference.

Your network foundation is in place. Next up, you'll lock down the data subnet with a Network Security Group that controls exactly which traffic can reach your backend resources.

Secure the Network with an NSG

Your virtual network now has two subnets separating frontend and backend traffic. But without any rules controlling what traffic can flow between them, an attacker who compromises the frontend could freely access the data tier.

In this step, you'll create a Network Security Group (NSG) with custom rules that lock down your data subnet. Only HTTPS traffic from within the virtual network will be allowed through.

In this step, get ready to:

Create a Network Security Group for the data subnet.
Add custom inbound rules to allow only HTTPS traffic from the VNet and deny everything else.
Associate the NSG with your data subnet to enforce the rules.

Create a Network Security Group

An NSG acts as a virtual firewall for your subnet, filtering inbound and outbound traffic based on rules you define. Each rule specifies a source, destination, port, and whether to allow or deny the traffic.

In the Azure Portal search box at the top, type Network security groups and select it from the results.
Click + Create.
Select your subscription from the Subscription dropdown.
Set Resource group to rg-contoso-health.
Enter nsg-data-subnet in the Name field.
Set Region to the same region as your virtual network.
Click Review + create, then click Create.

Wait for the deployment to complete. You should see a "Your deployment is complete" confirmation message.

What is a Network Security Group?

An NSG filters network traffic at the subnet or network interface level. Think of it as a bouncer at the door of your subnet, checking every packet against a list of rules before letting it in or turning it away.

NSGs are free to create and use. They are the standard way to implement network-level security in Azure without deploying a full Azure Firewall (which is a paid service).

Don't see Network security groups in search?

Make sure you are typing the full phrase Network security groups (plural). If it still does not appear, check that you are signed into the correct Azure subscription.

Help me find Network security groups in the Azure Portal

Add custom security rules

Every NSG comes with default rules that allow traffic within the VNet and deny unsolicited inbound traffic from the internet. You'll add two custom rules that are more restrictive: one to explicitly allow HTTPS from the VNet, and one to deny everything else.

Click Go to resource to open nsg-data-subnet.
In the left menu, click Inbound security rules.
Click + Add to create the first rule.

Configure the first rule with these settings:

Set Source to Service Tag.
Set Source service tag to VirtualNetwork.
Set Source port ranges to *.
Set Destination to Any.
Set Destination port ranges to 443.
Set Protocol to TCP.
Set Action to Allow.
Set Priority to 100.
Set Name to Allow-HTTPS-From-VNet.
Click Add.

Why priority 100?

NSG rules are evaluated in priority order, from lowest number to highest. A rule with priority 100 is checked before a rule with priority 200. Once a match is found, processing stops.

By giving the Allow rule a lower number (100) than the Deny rule (200), you ensure HTTPS traffic is permitted before the catch-all deny kicks in.

Now add the second rule to deny all other inbound traffic.

Click + Add again to create the second rule.

Configure the second rule with these settings:

Set Source to Any.
Set Source port ranges to *.
Set Destination to Any.
Set Destination port ranges to *.
Set Protocol to Any.
Set Action to Deny.
Set Priority to 200.
Set Name to Deny-All-Other-Inbound.
Click Add.

You should now see both custom rules listed in the inbound security rules table, alongside the default rules.

What do these two rules accomplish together?

The first rule (priority 100) allows encrypted HTTPS traffic on port 443, but only from resources inside your virtual network. The VirtualNetwork service tag automatically covers all addresses in your VNet's address space.

The second rule (priority 200) denies everything else. Together, they mean only secure internal traffic reaches your data subnet. This is the defense-in-depth principle in action: multiple layers of security so a single failure does not expose sensitive data.

Rule not appearing in the list?

Double-check that you clicked Add at the bottom of the rule panel. If the panel closed without saving, click + Add again and re-enter the values.

Also confirm the priority numbers are different. Two rules cannot share the same priority value.

Help me troubleshoot my NSG inbound rules

Associate the NSG with the data subnet

An NSG does not enforce anything until it is associated with a subnet or network interface. You need to attach it to subnet-data so that your rules control traffic entering that subnet.

In the left menu of nsg-data-subnet, click Subnets.
Click + Associate.
Set Virtual network to vnet-contoso.
Set Subnet to subnet-data.
Click OK.

After a moment, you should see subnet-data listed under the Subnets section of your NSG. This confirms the association is active.

NSG vs Azure Firewall: what's the difference?

NSGs filter traffic at the subnet or network interface level using simple allow/deny rules. They are free and ideal for basic network segmentation.

Azure Firewall is a fully managed, paid service that provides advanced features like application-level filtering and threat intelligence. For AZ-900, the key distinction is scope: NSGs work at the network layer, while Azure Firewall works at both network and application layers.

Don't see subnet-data in the dropdown?

Make sure you select vnet-contoso first in the Virtual network field. The Subnet dropdown only populates after a VNet is selected. Also confirm your NSG is in the same region as your virtual network.

Help me associate my NSG with a subnet

Your data subnet is now locked down to only accept HTTPS traffic from within the virtual network. Next up, you'll layer governance controls on top of this infrastructure to prevent accidental misconfiguration.

Apply Governance Controls

Your network is locked down. The NSG on your data subnet only allows HTTPS traffic from within the virtual network, creating a clear security boundary around sensitive resources.

Network controls are just one layer of protection. To truly secure Contoso Health Records, you need governance controls that prevent accidental misconfiguration regardless of who has access. In this step, you will apply three distinct governance mechanisms that the AZ-900 exam tests heavily.

In this step, get ready to:

Assign an Azure Policy to enforce tagging on your resource group.
Create a resource lock to prevent accidental deletion of the storage account.
Assign an RBAC Reader role to control who can view resources.

Assign an Azure Policy to enforce tagging

Organizations need a way to enforce standards across all their resources at scale. Azure Policy lets you define rules about what resources can look like, and automatically flags or denies anything that does not comply.

In the Azure Portal search box, type Policy and select it from the results.
Click Assignments in the left menu.
Click Assign policy at the top of the page.
Next to Scope, click the ... button.
Select your subscription, then specifically select rg-contoso-health as the resource group.
Click Select.
Next to Policy definition, click the ... button to open the list of available definitions.
In the search box, type Require a tag on resource groups and select it from the results.
Click Add (or Select) at the bottom.
Leave the Assignment name as the default.
Click the Parameters tab.
In the Tag Name field, enter Environment.
Click Review + create, then click Create.

What does this policy do?

The "Require a tag on resource groups" policy uses a deny effect. Any resource group that is created or updated without the required tag will be blocked.

By scoping the assignment to rg-contoso-health, you are telling Azure to evaluate this specific resource group for compliance. Since the resource group does not yet have an Environment tag, it will show as non-compliant. You will fix this in the next step.

Can't find the policy definition?

Make sure you are searching in the Available Definitions pane, not the Assignments list. Type the full name Require a tag on resource groups and press Enter. If the scope picker does not let you drill down to the resource group, try a different browser or clear your cache.

You also need at least Owner or Policy Contributor permissions on the subscription to assign policies.

Why can't I select my resource group in the scope picker?

Create a resource lock on the storage account

A resource lock prevents anyone from deleting or modifying a resource, regardless of their RBAC permissions. This is a brute-force safeguard for critical resources that must never be accidentally removed.

Navigate back to your storage account by typing its name in the portal search box.
In the left menu under Settings, click Locks.
Click + Add.
In the Lock name field, enter ProtectPatientData.
For Lock type, select Delete (this corresponds to CanNotDelete in the CLI).
In the Notes field, enter Prevents accidental deletion of patient health records.
Click OK.

You should see your new lock listed on the Locks page with the name ProtectPatientData and type Delete.

Why CanNotDelete instead of ReadOnly?

Azure offers two lock types. A CanNotDelete lock prevents deletion but still allows you to read and modify the storage account configuration. A ReadOnly lock blocks both deletion and modification, which would be too restrictive for normal day-to-day operations like uploading blobs or changing access tiers.

For Contoso Health Records, you want to protect the account from accidental deletion while still allowing the team to manage the data inside it.

Don't see the Locks option?

Make sure you navigated to the storage account itself, not a container inside it. The Locks option appears under Settings in the storage account's left menu.

Help me find the Locks setting on my storage account.

Assign an RBAC role to the resource group

Azure RBAC (Role-Based Access Control) determines who can do what on your resources. Unlike Policy (which governs what resources can look like) or Locks (which block specific actions), RBAC controls identity-based access.

Navigate to rg-contoso-health by typing it in the portal search box and selecting it.
In the left menu, click Access control (IAM).
Click Add, then click Add role assignment.
On the Role tab, search for Reader and select it from the results.
Click Next.
On the Members tab, select User, group, or service principal.
Click Select members.
Search for your own account name or email address.
Select your account from the results, then click Select.
Click Review + assign.

What is the Reader role?

The Reader role grants view-only access to all resources within the scope. The person assigned this role can see everything in rg-contoso-health but cannot create, modify, or delete anything.

In a real organization, you would assign different roles to different people. An admin might get Owner, a developer might get Contributor, and an auditor would get Reader.

How are Policy, Locks, and RBAC different?

This is the most commonly tested distinction on the AZ-900 exam. Policy controls what resources CAN look like (enforces organizational standards). Locks control what CANNOT be deleted or changed (brute-force protection regardless of permissions). RBAC controls WHO can act on resources (identity-based access control).

A user with Owner permissions could still be blocked by a Lock. A Lock does not care about your role. Similarly, Policy operates independently of who is making the request. All three layers work together as part of a defense-in-depth strategy.

Don't see the Add role assignment option?

You need Owner or User Access Administrator permissions on the resource group to assign roles. If Add is greyed out, check that you are on the Access control (IAM) page for rg-contoso-health, not a child resource.

I can't assign an RBAC role. Help me troubleshoot.

Your governance layers are in place. Next, you will put them to the test by trying to delete the locked storage account and checking policy compliance.

Test and Validate Your Governance Controls

In the previous step, you layered three governance controls onto your Contoso Health Records environment. Azure Policy, a resource lock, and an RBAC role assignment are all in place.

Now it's time to prove they actually work. Governance controls that haven't been tested are just configuration. In this step, you'll deliberately try to break your own rules and confirm that Azure stops you.

In this step, get ready to:

Test the CanNotDelete resource lock by attempting to delete the storage account.
Fix Azure Policy compliance by adding the required tag to your resource group.
Review the complete environment and connect each resource to its AZ-900 exam domain.

Test the resource lock

The CanNotDelete lock you applied in the previous step should prevent anyone from deleting the storage account, regardless of their permissions. Let's prove it works.

In the Azure Portal search box, type Storage accounts and select it.
Click on your storage account (contosohealthXXXX).
Click Delete in the top menu bar.
If prompted, type the storage account name to confirm deletion and click Delete.

You should see an error indicating the resource cannot be deleted because it has a lock. This confirms the CanNotDelete lock is working as intended.

Why does this matter for AZ-900?

Resource locks apply regardless of RBAC permissions. Even an Owner-level user cannot delete a resource with a CanNotDelete lock until the lock itself is removed. This is a key exam distinction: locks override identity-based access controls.

Not seeing a lock error?

If the deletion goes through without an error, the lock was not applied correctly in the previous step. Navigate to your storage account, select Locks under Settings in the left menu, and verify that ProtectPatientData appears with lock type Delete. If it's missing, re-add it.

help me figure out why my resource lock isn't blocking deletion

Test Azure Policy compliance

Your Azure Policy assignment requires an Environment tag on the resource group. Right now, rg-contoso-health doesn't have that tag, so it should show as non-compliant.

In the Azure Portal search box, type Policy and select it.
Click Compliance in the left menu.
Find your policy assignment. It should show as Non-compliant because rg-contoso-health does not yet have the Environment tag.

What does non-compliant mean?

Azure Policy continuously evaluates resources against your rules. A non-compliant status means the resource exists but doesn't meet the policy's requirements. The policy doesn't automatically fix the problem. It flags it so an administrator can take action.

Now let's fix the compliance issue by adding the required tag.

In the Azure Portal search box, type Resource groups and select it.
Click on rg-contoso-health.
Click Tags in the left menu.
In the Name field, enter Environment.
In the Value field, enter Production.
Click Apply.

Now return to Policy to verify compliance has updated.

In the Azure Portal search box, type Policy and select it.
Click Compliance in the left menu.
Find your policy assignment. The status should now show as Compliant.

Compliance updates can take a few minutes

Azure Policy evaluates compliance on a cycle. If you still see non-compliant, wait a few minutes and refresh the page. It can take up to 15 minutes for the compliance state to update.

What's the AZ-900 takeaway?

Azure Policy is about what CAN exist. It audits resource configurations at scale and flags (or blocks) resources that don't meet organizational rules. This is different from RBAC (which controls WHO can act) and resource locks (which prevent WHAT can be deleted or changed).

Policy still showing non-compliant after 15 minutes?

Double-check that the tag name is exactly Environment (capital E) and the tag is applied to the resource group itself, not to a resource inside it. Tag names are case-sensitive in policy evaluations.

help me troubleshoot why my Azure Policy is still showing non-compliant after I added the Environment tag

Review your complete setup

All your governance controls are verified. Let's take a final look at everything you built and connect each resource to the AZ-900 exam domains it covers.

In the Azure Portal search box, type Resource groups and select it.
Click on rg-contoso-health.
Review the Resources list. You should see your storage account, virtual network, and network security group.

How does each resource map to AZ-900?

Each resource you created demonstrates a different exam domain:

Storage account: covers redundancy options (GRS vs LRS vs ZRS) and access tiers (Hot, Cool, Cold, Archive).
Virtual network and subnets: covers network segmentation and defense-in-depth.
NSG: covers network-level security (filtering traffic at the subnet or NIC level).
Azure Policy, resource lock, and RBAC: covers governance and management tools and how they differ in purpose.

The governance trio for the exam

Remember the key distinction the AZ-900 tests heavily:

Policy = what CAN exist (enforces rules about resource configurations).
Lock = what CANNOT be deleted or changed (brute-force prevention regardless of identity).
RBAC = who CAN act (controls identity-based access to resources).

Secret mission

Restrict Storage to VNet-Only Access (Service Endpoint)

Right now, your storage account accepts traffic from anywhere on the internet. In a real healthcare environment, that is a compliance risk. Can you lock it down so only resources inside your virtual network can reach the patient records?

Clean Up Your Resources

Decide whether to keep your resources running or delete them entirely. All resources created in this project are free or cost fractions of a cent, so there is no urgency to clean up.

Resources you used:

Resource group: rg-contoso-health (free).
Storage account: contosohealthXXXX (negligible cost for a single test file).
Virtual network: vnet-contoso (free).
Network security group: nsg-data-subnet (free).
Azure Policy assignment scoped to rg-contoso-health (free).
Resource lock: ProtectPatientData on the storage account (free).
RBAC Reader role assignment scoped to rg-contoso-health (free).

Keep everything running

No action needed. Choose this if you want to continue studying or revisiting the resources.

All resources in this project are free or cost fractions of a cent. There is no billing risk from leaving them in place.
Your storage account holds a single test file. Storage costs for this are negligible.
Virtual networks, NSGs, Azure Policy assignments, resource locks, and RBAC assignments are all free.

Pause - I'll come back to this later

These resources have no running compute cost, so there is nothing to pause. Leaving them in place is functionally identical to keeping everything running.

There are no virtual machines, app services, or other compute resources that incur ongoing charges.
If you want to reduce clutter in your Azure Portal without permanently deleting, you can leave the resources as-is and return whenever you are ready.

Delete - I don't want to use this again

Remove all project resources and start fresh. Because of the resource lock, you must remove the lock before you can delete anything.

Navigate to your storage account (contosohealthXXXX) in the Azure Portal.
In the left menu under Settings, select Locks.
Click the delete icon next to the ProtectPatientData lock to remove it.
Navigate back to Resource groups in the Azure Portal.
Select rg-contoso-health.
Click Delete resource group at the top of the page.
Type rg-contoso-health in the confirmation field and click Delete.
This removes all resources inside the group: the storage account, virtual network, NSG, policy assignment, and RBAC assignment.

Nice Work!

You just built a fully governed Azure environment for a fictional healthcare company. Your infrastructure demonstrates how storage, networking, security, and governance services work together to protect sensitive data.

You've learned how to:

Configured a Storage Account with GRS redundancy and a Cool access tier, making scenario-based decisions about when to use each redundancy and tier option.
Created a Virtual Network with segmented subnets and a Network Security Group with custom inbound rules, demonstrating defense-in-depth at the network level.
Applied three governance layers: Azure Policy to enforce tagging compliance, a Resource Lock to prevent accidental deletion, and an RBAC role assignment to control who can access resources.
Secret Mission: Configured a service endpoint to restrict storage account access to only your virtual network, demonstrating the difference between public and private endpoints.

Ready to quiz yourself?