Part 2: Enforce Azure Guardrails

Apply Azure Policy, tags, and locks to govern a sandbox virtual network.

Introduction

30 Second Summary

Shared online workspaces become risky when nobody can tell who owns an item or why it exists. A single mistaken click can remove work that still matters.

In this project, you will govern a fictional Northstar Analytics sandbox in the Azure portal. You will make missing metadata visible before Azure Policy blocks an unclassified resource.

What You'll Build

Your finished sandbox lets you show Northstar a tagged Azure Virtual Network, a rejected unclassified deployment, and a protected network that survives a deletion attempt.

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

A governed sandbox whose resource group Overview displays Owner=CloudOps, Environment=Sandbox, and DataClassification=Internal. Its network's Tags page exposes the missing tag inheritance.
A policy-enforcement proof where an untagged deployment returns Forbidden. The rejected test leaves no unwanted network behind.
A deletion-protection demo where an inherited resource lock keeps the network visible after a deletion attempt. A decision model maps authorization to Azure RBAC and resource compliance to Azure Policy. It maps metadata scanning to Microsoft Purview Data Map and searchable curation to Microsoft Purview Unified Catalog.
Secret Mission: Add a second policy assignment that prevents removal of the resource owner's tag.

Are there any prerequisites?

You need an active Azure subscription with a disposable test resource group. Your account needs permission to manage policies, resource locks, and virtual networks within that sandbox.

Before We Start

Before any hands-on work, this step locks in the governance outcome Northstar Analytics needs. You are building a tagged, policy-enforced, deletion-protected Azure sandbox that proves ownership, classification, and protection from accidental deletion.

Verify the Governance Sandbox

Northstar needs a safe place to test controls without affecting shared workloads. An Azure Policy assignment or resource lock at the resource group scope can affect every child resource.

A dedicated sandbox creates that boundary before you add Azure tags or deletion protection.

In this step, you'll confirm the intended directory and subscription in the Azure portal. You'll also verify each management surface without creating an Azure Virtual Network.

In this step, get ready to:

Confirm the intended Azure directory and active subscription.
Select a dedicated or disposable resource group for the sandbox.
Verify access to tags, locks, policy assignments, and virtual-network creation.

Select a safe sandbox scope

The sandbox resource group contains every resource affected by this project's controls. Its contents must be disposable so later policy and lock tests cannot disrupt important work.

Sign in to the Azure portal.
Use the account menu in the portal header to confirm that the intended directory is active.
Record the active subscription here: active-subscription.
Select Resource groups in the Azure portal.
Open your existing disposable test resource group.
Review its resource list on the Overview page.
Choose the path that matches what the resource list shows.

✔️ My Existing Group Is Disposable

Your existing group can serve as the sandbox because its contents are safe to govern during this project.

Record the selected resource-group name here: sandbox-resource-group.
Record the region listed on the Overview page here: sandbox-region.
Confirm that vnet-governance-lab is absent from the resource list.
Keep the sandbox resource group's Overview page available.

ⓧ My Existing Group Contains Important Resources

A shared group would expose unrelated resources to the controls you apply later. Create an empty group that belongs only to this project.

Return to Resource groups.
Select Create.
Under Subscription, choose active-subscription.
Enter rg-governance-lab in the Resource group field.
Select an available region under Region.
Select Review + create without adding tags.
Select Create.

Azure creates the empty group within a few seconds. You now have a clean boundary for the governance controls ahead.

Open rg-governance-lab from the resource-group list.
Record the selected resource-group name here: sandbox-resource-group.
Record the selected region here: sandbox-region.
Confirm that the Overview resource list is empty.

Check tags and locks

The tags and locks pages are where you add metadata and deletion protection later. Opening these pages confirms access without changing the sandbox.

Switch back to the Overview page for sandbox-resource-group.
Select Tags.
Confirm that the Tags page opens.
Confirm that Owner=CloudOps, Environment=Sandbox, and DataClassification=Internal are absent.
Return to the sandbox resource group.
Under Settings, select Locks.
Confirm that the Locks page opens.
Confirm that protect-governance-lab is absent.

Can't Open Tags or Locks?

An unavailable page can indicate that the portal is using the wrong directory or that your account cannot manage the selected group.

Recheck the intended directory from the portal header.
Use another disposable resource group that you can manage.
Ask your subscription administrator to confirm your access if both pages remain unavailable.

Need a hand? Help me diagnose my missing Azure portal access..

Verify policy and network access

Resource-group access does not automatically prove that every governance action is available. These checks confirm that you can target the sandbox with policy and start a virtual-network deployment later.

Search for Policy in the Azure portal.
Select Policy from the results.
Select Assignments.
Select Assign Policy.
Under Scope, choose sandbox-resource-group.
Confirm that the Scope field accepts the sandbox resource group.
Leave the assignment form without selecting Create.

The scope selector should accept your sandbox resource group. No new policy assignment should appear on the Assignments page.

Why Check the Assignment Scope?

A policy assignment applies to its selected scope. Child resources inherit an assignment made at resource-group scope.

Confirming the sandbox here proves that later guardrails stay inside your chosen boundary.

Before the last access check, pause and predict whether the virtual-network creation entry point is available.

Search for Virtual networks in the Azure portal.
Select Virtual networks from the results.
Confirm that + Create is available.
Leave the page without selecting + Create.

You should see + Create. This confirms that the virtual-network creation flow is available without adding a network yet.

Sandbox Checkpoint

You selected resource group sandbox-resource-group in subscription active-subscription.

Its recorded region is sandbox-region. The group is dedicated or disposable for this project.

No project-specific governance controls exist yet. No project virtual networks exist yet.

That's your safety boundary confirmed. Next, you'll add Northstar's governance tags and expose the resource-level metadata gap.

Expose the Tagging Gap

Your Azure portal checks proved that the sandbox is safe for governance experiments. You also confirmed the access needed for this deployment.

Now you'll apply three Azure tags to the sandbox resource group. Together, they describe the sandbox's governance context.

You'll create an Azure Virtual Network with one subnet. Its blank Tags page exposes that child resources do not automatically inherit resource-group metadata.

In this step, get ready to:

Apply ownership, environment, and data-classification tags to the sandbox resource group.
Create vnet-governance-lab with the subnet-governance-lab subnet.
Compare the resource-group Overview with the virtual network's Tags page.

Tag the sandbox resource group

Azure treats tag values as case-sensitive. Exact casing keeps your governance evidence consistent.

On the sandbox resource group's Overview, select Add tags.
Enter Owner in the first tag name field.
Enter CloudOps in its value field.
Enter Environment in the second tag name field.
Enter Sandbox in its value field.
Enter DataClassification in the third tag name field.
Enter Internal in its value field.
Select Save.

Your resource-group Overview should now display Owner=CloudOps. It should also display Environment=Sandbox.

You should see DataClassification=Internal beside them. You now have the first governance signal in place.

Create the untagged virtual network

The virtual network becomes a child resource inside your sandbox. Leaving its tags empty creates the comparison that reveals the inheritance gap.

Enter Virtual networks in the Azure portal search bar.
Select Virtual networks from the search results.
Select + Create.

You'll see the Create virtual network wizard. The first screen defines where the network belongs.

On the Basics tab, select the active subscription you confirmed earlier.
Select your recorded sandbox resource group.

The wizard now points to your active subscription. It also points to the sandbox resource group.

Enter vnet-governance-lab as the network name.
Select your recorded sandbox region.

The network name should show vnet-governance-lab. The region should match the sandbox resource group.

Select Next to reach Security.
Leave every option on Security unchanged.

The Security options remain at their defaults. This keeps optional network services out of the deployment.

Select Next to reach IP Addresses.
Set the IPv4 address space to 10.0.0.0/16.

The virtual network address space should now show 10.0.0.0/16.

Under Subnets, select the default subnet.
Enter subnet-governance-lab as the subnet name.

The subnet editor now identifies the network segment as subnet-governance-lab.

Keep the Starting address at 10.0.0.0.
Keep the Subnet size at /24 (256 addresses).

The subnet now uses a /24 range inside the virtual network's address space.

Select Save in the subnet editor.
Select Review + create.

The review should list vnet-governance-lab in your sandbox resource group. It should show the recorded sandbox region.

Select Create after validation passes.
Wait until the deployment reports success.

Your first child resource is live in the sandbox. It contains the planned address space plus the default subnet.

Virtual Network Validation Failed?

Confirm that the virtual network address space is 10.0.0.0/16.
Confirm that subnet-governance-lab uses a /24 range.
Check that the selected resource group matches your recorded sandbox.

Still stuck? Help me troubleshoot my Azure virtual network validation.

Compare the two Tags views

Before you check, predict whether the virtual network contains the three resource-group tags.

Enter Virtual networks in the Azure portal search bar.
Select Virtual networks from the search results.
Select vnet-governance-lab.
Select Tags from the virtual network menu.

The virtual network's Tags page is empty. No resource-group tags appear on this child resource.

Enter Resource groups in the Azure portal search bar.
Select Resource groups from the search results.
Select your recorded sandbox resource group.

The resource-group Overview still displays Owner=CloudOps. It also displays Environment=Sandbox.

That Overview also displays DataClassification=Internal. The two views now provide visible evidence of the tagging gap.

What Does This Comparison Prove?

Azure stores tags on the resource where you save them. Resource-group scope does not copy those key-value pairs to child resources.

The empty virtual network Tags page exposes a metadata gap. A governance convention needs an enforcement control to prevent that gap from recurring.

You've exposed the metadata gap in a live Azure resource hierarchy. Next, you'll use Azure Policy to turn the data-classification convention into an enforced rule.

Enforce Data Classification

Your sandbox already exposes the metadata gap. Its Azure resource group carries three Azure tags while vnet-governance-lab carries none.

Azure Policy turns that convention into an enforceable rule at the sandbox scope. You will test the rule with an untagged network request.

In this step, get ready to:

Assign a built-in policy at the sandbox resource-group scope.
Allow the new assignment to take effect.
Test how the policy handles an untagged virtual-network deployment.

Assign the classification policy

A policy definition describes a governance rule. A policy assignment connects that rule to a specific scope.

Enter Policy in the top search bar of the Azure portal.
Select Policy from the search results.
Select Assignments in the left menu.
Select Assign Policy.
Set Scope to your sandbox resource group.
Choose Require a tag and its value on resources under Policy definition.
Name the assignment Require-DataClassification-Internal.
Keep Policy enforcement set to Enabled.

Why Use Resource-Group Scope?

Assignments apply to child resources beneath their scope. Resource-group scope keeps this guardrail inside your sandbox.

Select Parameters.
Set the required tag name to DataClassification.
Set the required tag value to Internal.
Select Remediation.
Leave managed-identity creation unchecked.
Select Non-compliance messages.
Enter Resources must use DataClassification=Internal. as the message.
Select Review + create.

Why Leave Identity Creation Off?

This policy evaluates resource requests without deploying or modifying resources. It does not need a managed identity.

Confirm the assignment scope is your sandbox resource group.
Confirm the selected definition is Require a tag and its value on resources.
Confirm the required tag is DataClassification=Internal.
Confirm Policy enforcement is Enabled.
Select Create.

Good progress. Your classification policy now exists at the sandbox scope with enforcement enabled.

Can't Create the Assignment?

Confirm your account can assign policies at resource-group scope.
Confirm the scope points to your sandbox resource group.
Confirm you selected the exact built-in definition named Require a tag and its value on resources.

Still blocked? Help me diagnose why I cannot create this Azure Policy assignment.

Wait for the assignment

This pause can feel slow, but about five minutes is normal while Azure Policy applies a new assignment. The assignment can appear before policy evaluation begins.

Wait about five minutes for the assignment to take effect.
Refresh the Assignments page.
Select Require-DataClassification-Internal from the assignment list.
Confirm the scope points to your sandbox resource group.
Confirm Policy enforcement remains Enabled.

You should now see Require-DataClassification-Internal listed at the sandbox scope.

Test the guardrail

A separate Azure Virtual Network request gives the guardrail a real deployment to evaluate. The test uses a new name so your existing network stays untouched.

Enter Virtual networks in the portal search bar.
Select Virtual networks from the search results.
Select + Create.
Set Subscription to your active subscription.
Set Resource group to your sandbox resource group.
Enter vnet-policy-test as the network name.
Select your recorded region.
Keep the security defaults unchanged.

Why Use the Same Scope?

The assignment covers child resources in your sandbox resource group. Placing this request in that group puts it inside the assignment's scope.

Set the IPv4 address space to 10.1.0.0/16.
Set the default subnet size to /24.
Rename the default subnet subnet-policy-test.
Leave the network tags empty.
Select Review + create.

Before you submit the deployment, do you think the untagged request will be accepted or rejected?

Select Create.

You'll see the deployment fail with Forbidden. This intended result shows that Azure Policy rejected the untagged request before the resource provider created the network.

Inspect the failed deployment's error details.
Locate Require-DataClassification-Internal in the error details.
Return to your sandbox resource group.
Review the resource list for vnet-policy-test.

You should not see vnet-policy-test in the resource list. The missing network plus the named assignment prove that the classification guardrail worked.

Did the Test Network Deploy?

Return to the Azure Policy assignments list.
Confirm the assignment uses your sandbox resource-group scope.
Confirm Policy enforcement is Enabled.
Open vnet-policy-test if it exists.
Select Delete.
Select Yes to confirm deletion.
Wait another five minutes for the assignment to apply.
Repeat the untagged deployment test.

If the result still differs, help me work out why the untagged virtual network was created.

Your sandbox now rejects unclassified resources before creation. Next, you'll bring vnet-governance-lab into compliance with the same metadata rule.

Bring the Resource into Compliance

Your deny test in the Azure portal proved that Azure Policy blocks a new resource when its required metadata is missing. The untagged Azure Virtual Network still carries the governance gap you exposed earlier.

A deny policy can report an existing bad state. It does not repair that resource.

You will add the required metadata to the original virtual network. You will then inspect the policy's compliance evidence.

In this step, get ready to:

Apply the required Azure tags to vnet-governance-lab.
Inspect the assignment's resource compliance evidence.
Compare the successful update with the earlier denied deployment.

Add the required tags

Tag values are case-sensitive. The exact values make the virtual network match the policy rule.

From the sandbox resource group that is already open, select vnet-governance-lab in the resource list.
Select Tags from the virtual network menu.
Add DataClassification with the value Internal.
Add Owner with the value CloudOps.
Add Environment with the value Sandbox.
Select Save.

That closes the metadata gap you exposed earlier: vnet-governance-lab now carries the metadata the policy expects. The Tags page shows DataClassification=Internal, Owner=CloudOps, and Environment=Sandbox.

Why does this update succeed?

The enabled deny effect evaluates the resource state during the update. DataClassification=Internal satisfies the required tag value.

The deny effect identifies the original non-compliant state. It cannot add the missing metadata for you.

🙋‍♀️ Tags not saving?

Check that the tag name is exactly DataClassification.
Confirm that its value is exactly Internal.
Check each value for unexpected spaces.

Still blocked? Help me troubleshoot why Azure Policy is denying this tag update.

Inspect policy compliance

Azure Policy updates its compliance state asynchronously. The saved Tags page gives you immediate evidence while policy evaluation catches up.

Return to Policy from earlier.
Select Compliance in the left menu.
Select Require-DataClassification-Internal in the assignment list.
Select Resource compliance.
Inspect the row for vnet-governance-lab when evaluation data is available.

If evaluation has completed, you'll see vnet-governance-lab listed as compliant. If the row is missing or shows older information, the evaluation is still catching up.

Why can compliance lag?

A tag update and the policy dashboard follow different update schedules. The saved Tags page proves the current resource state while the compliance view catches up.

Compare the policy evidence

Before you check the resource list, which virtual network do you expect to find?

Return to the sandbox resource group's Overview page.
Review the resource list for vnet-governance-lab.
Check the same resource list for vnet-policy-test.

You'll see vnet-governance-lab in the resource list. You will not see vnet-policy-test because its untagged deployment was denied.

Select vnet-governance-lab from the resource list.
Select Tags from the virtual network menu.
Review the three saved tag values.

You'll see DataClassification=Internal, Owner=CloudOps, and Environment=Sandbox on the virtual network.

What does the evidence prove?

The update to vnet-governance-lab succeeds because its final state matches the required tag value. vnet-policy-test remains absent because its untagged create request was denied with Forbidden.

Your virtual network now satisfies the classification rule while preserving evidence of the denied deployment. Next, you'll add deletion protection as a separate governance layer.

Protect the Resource and Choose Controls

Your Azure Virtual Network now carries Northstar's three required tags. Azure Policy accepted that compliant update.

The earlier untagged deployment stayed blocked. The current compliant state still leaves one risk.

Azure RBAC can authorize deletion. A resource lock adds separate protection against accidental control-plane deletion.

In this step, get ready to:

Create a Delete lock at the sandbox resource-group scope.
Test the inherited lock with a virtual-network deletion request.
Choose the correct governance control for each Northstar requirement.

Create a deletion lock

Resource-group locks flow down to child resources. A Delete lock keeps authorized users from deleting those children through control-plane operations.

Switch back to the sandbox resource group from earlier.
Select Locks under Settings.
Select Add.

You'll see the form for a new resource-group lock.

Enter protect-governance-lab as the lock name.
Select Delete as the lock type.

The form now identifies the lock as deletion protection for the sandbox resource group.

Enter Northstar sandbox deletion protection as the note.
Create the lock by submitting the completed form.

You'll see protect-governance-lab listed with the Delete type. The guardrail now covers vnet-governance-lab through inheritance.

How Does Lock Inheritance Work?

A lock at a parent scope is inherited by child resources. Resources added later inherit it too.

A Delete lock permits reads and modifications. It prevents deletion through Azure control-plane operations.

Test inherited deletion protection

The lock becomes meaningful when a real deletion request reaches the protected resource. This test shows how the parent control changes the outcome for a child resource.

Return to the sandbox resource group's Overview page.
Select vnet-governance-lab from the resource list.
Select Delete from the virtual network's Overview page.

A deletion confirmation can feel high stakes. The existing lock lets you test the guardrail using only the lab resource.

Before you confirm, which control do you think wins when Azure RBAC permits deletion but a parent lock restricts it?

Select Yes to confirm the deletion request.

Azure blocks the deletion operation. The virtual network remains available.

That is the proof your guardrail works. The inherited lock overrides your normal deletion permissions.

Return to the sandbox resource group.
Review the resource list.

You'll still see vnet-governance-lab in the resource group.

Select Locks under Settings.

You'll see protect-governance-lab listed at the resource-group scope.

Deletion Wasn't Blocked?

Confirm the sandbox resource group's lock list contains protect-governance-lab.
Check that the lock uses the Delete type.

Still unable to prove the lock works? Help me troubleshoot the inherited resource lock.

Choose the right governance layer

Northstar has several governance problems. Each problem belongs to a different layer.

Data governance adds a separate decision about discovery and curation. Choosing by problem keeps the controls focused.

Before you check the mapping, which control would you choose for each Northstar problem?

Match the question of who can act to the authorization control.
Match required resource state to the compliance control.
Match accidental control-plane deletion to the protection control.
Match source scanning and metadata capture to the discovery solution.
Match searchable curation of governed data to the catalog solution.
Decide whether a resource label can inspect or catalog the data inside it.

Check Your Governance Decisions

Azure RBAC controls who can act on Azure resources.
Azure Policy enforces required resource state.
Resource locks protect against accidental control-plane deletion.
Microsoft Purview Data Map scans sources and captures metadata.
Microsoft Purview Unified Catalog supports searching and curation of governed data.
Azure tags label a resource. They do not inspect or catalog the data inside it.

Compare each of your choices with the governance mapping above.

You've separated controls that are easy to blur together. You can now defend each choice through the problem it solves.

Secret mission

Add an Ownership Guardrail

Layer a second Azure Policy assignment onto your governed sandbox. Then prove that removing the ownership tag triggers the new guardrail while the classification rule remains satisfied.

Clean Up Your Resources

Your project resources are expected to cost $0 because the base virtual network has no add-on networking services. Existing unrelated Azure resources can still generate charges, so decide whether to keep, pause, or delete only this sandbox.

Resources you used:

One Azure Virtual Network named vnet-governance-lab with subnet subnet-governance-lab and the three project tags.
Two enabled Azure Policy assignments named Require-DataClassification-Internal and Require-Owner-Tag.
One inherited resource lock named protect-governance-lab with lock type Delete.
One dedicated Azure resource group named rg-governance-lab if you created it specifically for this project.

Keep everything running

Keeping the sandbox preserves the full governance demonstration. This option fits continued practice in a dedicated resource group.

Leave Require-DataClassification-Internal enabled to enforce DataClassification=Internal on child resources.
Leave Require-Owner-Tag enabled to protect the Owner tag.
Keep protect-governance-lab in place to block control-plane deletion of vnet-governance-lab.
Retain vnet-governance-lab as a reusable governance demonstration.
Use the Pause or Delete option if the sandbox resource group contains shared resources. The assignments and lock apply across its child resources.

Pause - I'll come back to this later

Pausing preserves the tagged virtual network for later practice. It removes the resource-group controls that could affect other child resources.

In the sandbox resource group from earlier, select Locks under Settings.
Use Delete to remove protect-governance-lab.

That safely removes the inherited deletion barrier. The next actions stop both tag guardrails while preserving the tagged network.

Return to Policy in the Azure portal.
Select Assignments.
Select the ellipsis for Require-DataClassification-Internal.
Select Delete assignment.
Select the ellipsis for Require-Owner-Tag.
Select Delete assignment.

The shared-scope guardrails are now removed. The tagged virtual network remains available for your next practice session.

Confirm both project assignments are absent from the Assignments list.
Return to the resource group's Locks page.
Confirm protect-governance-lab is absent.
Return to the sandbox resource group's Overview page.
Confirm vnet-governance-lab remains visible.

Delete - I don't want to use this again

Deleting the sandbox resources is permanent. You can rebuild the demonstration from the project steps, so cleanup begins with the inherited controls.

In the sandbox resource group from earlier, select Locks under Settings.
Use Delete to remove protect-governance-lab.

That clears the inherited deletion barrier safely. The two policy assignments can now be removed from the same sandbox scope.

Return to Policy.
Select Assignments.
Select the ellipsis for Require-DataClassification-Internal.
Select Delete assignment.
Select the ellipsis for Require-Owner-Tag.
Select Delete assignment.
Confirm both project assignments are absent from the Assignments list.

The sandbox no longer enforces either project tag rule. The virtual network is now ready for deletion.

Return to vnet-governance-lab from the sandbox resource group's Overview page.
Select Delete from the virtual network's Overview page.
Select Yes to confirm the deletion.
Return to the sandbox resource group's Overview page.
Confirm vnet-governance-lab is absent from the resource list.

You have cleared the project network without touching unrelated resources. One optional container cleanup remains if you created the dedicated lab group.

Confirm the resource list is empty if you created rg-governance-lab specifically for this project.
Use the resource group's Overview deletion control to delete rg-governance-lab only after the empty-state check.
Complete the portal confirmation for deleting rg-governance-lab.
Leave the pre-existing test resource group untouched if you used it as the sandbox.
Leave every unrelated subscription resource untouched.

Nice Work!

Strong finish. You've completed a governed Northstar Analytics sandbox in the Azure portal.

You've learned how to:

Expose the tag inheritance gap by comparing resource-group Azure tags with an untagged child resource. You applied ownership, environment, and classification metadata directly to vnet-governance-lab.
Create an Azure Policy deny guardrail for DataClassification=Internal. The rejected vnet-policy-test deployment proved that the rule blocks non-compliant resources.
Add inherited deletion protection with a resource lock at sandbox scope. The blocked deletion proved that Azure RBAC permission does not bypass the lock. Your decision model now places source scanning in Microsoft Purview Data Map. It places governed-data search in Microsoft Purview Unified Catalog.
Secret Mission: Create a second ownership guardrail with Require-Owner-Tag. The denied update proved that the assignment keeps Owner=CloudOps on vnet-governance-lab.

Ready to quiz yourself?