Build Azure Governance Guardrails

Enforce tags and deletion protection with Azure Policy and management locks.

Introduction

30 Second Summary

Cloud resources often start tidy. Small inconsistencies appear as more people create them.

In this project, you will build a governance baseline for a nonproduction Microsoft Azure subscription in the Azure portal. Your baseline uses tags, Azure Policy, and a management lock to enforce standards across your sandbox.

What You'll Build

Picture opening the Azure portal to demo a labelled sandbox where an untagged resource group is rejected and an accidental deletion attempt is blocked.

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

A tagged governance sandbox where you can immediately identify its environment as Lab and its owner as AZ104Learner.
An enforced subscription-scope policy that rejects new resource groups when the required Environment tag is missing.
A protected sandbox where a Delete lock visibly stops an authorized deletion request.
Secret Mission: A second policy assignment that requires the Owner tag before a new resource group can satisfy both governance rules.

Are there any prerequisites?

You need a personal or nonproduction Azure subscription where your access includes the Owner role. Step 1 covers access verification plus the Azure free account path for eligible new customers.

Before We Start

Before you change your subscription, this checkpoint helps you commit to the governance baseline you are about to build. You will use tags to organize resource groups, subscription-scope Azure Policy assignments to enforce required metadata, and a Delete lock to prevent accidental deletion in a nonproduction environment.

Verify Your Azure Sandbox Access

Your later Azure Policy assignment operates across a nonproduction Azure subscription. A management lock also depends on permission at its target scope.

This step confirms that your account has Owner access before you create anything. It also proves that the administration panes needed later are available.

In this step, get ready to:

Sign in to the Azure portal with an active nonproduction subscription.
Confirm an Owner role assignment at the subscription scope or an inherited parent scope.
Confirm access to the Resource groups and Policy administration panes.

Sign in to your Azure subscription

The Azure portal keeps your subscription scope visible while you work. You will access it in Google Chrome.

Press Cmd+Space on macOS or the Windows key on Windows to open your system search.
Type Google Chrome and press Enter to open it.
Go to the Azure portal.
Sign in with the account connected to your nonproduction subscription.
Enter Subscriptions in the portal search bar.
Select Subscriptions from the search results.

Why use the portal for this lab?

The portal shows subscription scope alongside access details. This visibility makes each governance decision easier to inspect.

Automation tools offer repeatability in larger environments. The portal keeps this first lab focused on the governance model.

✔️ I see an active subscription

Select the active nonproduction subscription you will use for this lab.

Good, your nonproduction subscription is now the safety boundary for every later action in this lab.

ⓧ No active subscription appears

Azure free accounts are available only to new Azure customers.

Payment verification can feel like a commitment. Microsoft says the free account stays uncharged unless you move to pay-as-you-go.

A temporary $1 authorization may appear during verification.

Confirm that you are eligible as a new Azure customer.
Open the Azure free account page in the same Google Chrome window.
Start signup with a Microsoft or GitHub account.
Provide a phone number for verification.
Provide a non-prepaid credit or debit card for verification.
Complete the guided signup process.
Return to the Azure portal after signup.
Search for Subscriptions again.

You should now see an active subscription that you can select for the lab.

Still Missing a Subscription?

Check that you signed in with the account connected to your Azure subscription.
Use only a personal or nonproduction subscription for this lab.
Ask your administrator for access to a nonproduction subscription if you are not eligible for a free account.

Help me restore access to my Azure subscription.

Confirm your Owner access

Azure role-based access control, also called Azure RBAC, determines what your account can do at each scope. The Owner role covers the policy assignment permissions required by this lab.

The same role also covers the permissions required to create or remove management locks.

Select Access control (IAM) from the menu for the subscription you selected.
Select the Check access tab.

Before you view the assignments, predict which role should appear for your account at this scope.

Select View my access.
Find Owner in the assignments pane.
Check whether the assignment applies at the subscription scope or comes from an inherited parent scope.

You should see Owner at the subscription scope or an inherited parent scope. That clears the permission hurdle for the rest of the lab.

Owner Role Missing?

Check that you selected the intended nonproduction subscription.
Check the inherited assignments shown for your account.
Ask the subscription administrator to grant Owner access before you continue if the role is absent.

Help me understand why my Owner role is missing.

Open the administration panes

The Resource groups pane shows the containers governed by this lab. The Policy pane shows the assignments that enforce subscription standards.

Enter Resource groups in the portal search bar.
Select Resource groups from the search results.

You should see the Resource groups pane load without an access error. This confirms that the administration pane is available.

Enter Policy in the portal search bar.
Select Policy from the search results.

You should see the Policy pane load without an access error. This confirms that the second administration pane is available.

Why These Panes Matter

Resource groups is where you will organize the sandbox that later receives tags and deletion protection.

Policy is where you will assign the rule that enforces required metadata across the subscription.

Before the final check, predict whether the assignments pane will still show Owner for your account.

Enter Subscriptions in the portal search bar.
Select Subscriptions from the search results.
Select the nonproduction subscription you verified earlier.
Select Access control (IAM) from the subscription menu.
Select the Check access tab.
Select View my access.

The assignments pane should show Owner at the subscription scope or an inherited parent scope. Your nonproduction Azure sandbox access is ready.

Your permissions and administration panes are confirmed. Next, you will create the tagged governance sandbox.

Create a Tagged Governance Sandbox

Your Owner access is verified in the Azure portal. Now you can create the first working piece of the governance baseline.

An Azure resource group gives the lab a safe target for later controls. Tags make key metadata visible from the overview.

In this step, get ready to:

Create rg-az104-governance in Central US.
Label the sandbox with its environment.
Label the sandbox with its owner.

Create the sandbox resource group

The group keeps this lab's governance work inside one named sandbox. Selecting the verified nonproduction subscription protects unrelated environments.

Switch back to the Resource groups pane from earlier.
Select Create.

You'll see the creation form with fields for Subscription, Resource group, and Region.

Select the verified nonproduction subscription in Subscription.
Enter rg-az104-governance in Resource group.

The form now points the sandbox at the subscription where you confirmed Owner access.

Select Central US in Region.
Select Review + Create.

You'll see the review page after the values pass validation.

Select Create.

You'll see a successful deployment confirmation in the portal. The new group then appears in the Resource groups list.

Good progress. rg-az104-governance is now the named sandbox for this lab.

Resource group creation blocked?

Confirm the selected subscription is the nonproduction subscription where you verified Owner access.
Check that the resource group name matches rg-az104-governance exactly.

Help me troubleshoot this resource group creation.

Add governance tags

Tags are name-value pairs that add metadata to a resource group. This metadata makes governance details visible in the portal.

Select rg-az104-governance from the Resource groups list.
Select Add tags from its overview.

You'll see rows where you can provide tag names and values.

Enter Environment as the first tag name.
Enter Lab as its value.

The first row now identifies this resource group as a lab environment.

Enter Owner as the second tag name.
Enter AZ104Learner as its value.

The second row now records the owner used for this sandbox.

Select Save.

What Do These Tags Record?

The Environment: Lab pair identifies this resource group as a lab environment.

The Owner: AZ104Learner pair records the owner used for this sandbox.

Verify the tagged overview

The overview is the visible checkpoint for your first governance baseline. It should show the metadata you just saved.

Before the final check, form a prediction about how many saved tag pairs the overview should display.

Select Overview in the resource group's left menu.

You'll see Environment: Lab in the overview. You'll also see Owner: AZ104Learner.

That's your first governance baseline in place with both required tags visible.

Tags Missing From the Overview?

Select Add tags again from the resource group overview.
Check that Environment uses a capital E.
Check that Owner uses a capital O.

Help me find or correct the missing tags.

Your tagged sandbox is ready for the next test. Next, you'll see what happens when a resource group is created without these labels.

Expose the Manual Tagging Gap

Your first resource group now carries Environment and Owner tags. Its purpose is easy to identify.

Manual tagging depends on every creator remembering the same fields. Tags do not automatically inherit across Azure resources.

A deliberately untagged resource group gives you a concrete test of the current guardrail. The result shows whether your subscription enforces consistent metadata.

In this step, get ready to:

Create an untagged resource group in Central US.
Compare the tag coverage across both resource groups.

Create an untagged resource group

Switch back to the Resource groups pane from earlier.
Select Create.
Choose your verified nonproduction subscription in Subscription.
Enter rg-az104-untagged in Resource group.
Select Central US in Region.
Leave all tags unset.
Select Review + Create.

Before you select Create, do you think the subscription currently has a control that rejects this untagged group?

Select Create to test the current governance setup.

You'll see rg-az104-untagged created successfully without any tags.

Why was the group accepted?

Your subscription has no Azure Policy assignment requiring an Environment tag. Azure therefore accepts a resource group that omits it.

You have now exposed the exact governance gap this lab is designed to close.

Resource group creation failed?

Confirm that Subscription contains the verified nonproduction subscription.
Confirm that Region contains Central US.
Return to your subscription access page if the portal reports a permissions problem.

Help me troubleshoot this resource group creation.

Compare the resource-group tags

The two resource groups were created through the same portal flow. Their tag coverage is the only deliberate difference.

Switch back to Resource groups.
Locate the rg-az104-governance row.
Locate the rg-az104-untagged row.

Before you compare their overviews, do you expect both resource groups to show the same tag coverage?

Select rg-az104-governance.
Confirm that Overview shows Environment: Lab.
Confirm that Overview shows Owner: AZ104Learner.
Switch back to Resource groups.
Select rg-az104-untagged.
Confirm that Overview has no Environment tag.
Confirm that Overview has no Owner tag.

The rg-az104-governance overview shows both governance tags. The rg-az104-untagged overview shows neither tag.

The governance gap is now visible in your subscription. Next, you'll add enforcement so new resource groups must include the required tag.

Enforce the Tag with Azure Policy

Your resource-group comparison proved Azure accepts missing governance tags when no control enforces them.

Azure Policy closes this gap by evaluating resource requests against a rule. In this step, you assign a built-in rule at an Azure Resource Manager scope that covers your subscription so every new resource group must include Environment.

In this step, get ready to:

Choose the nonproduction subscription as the assignment scope.
Configure the built-in rule to require the Environment tag.
Create the enabled assignment at subscription scope.

Choose the policy boundary

A policy assignment connects a policy definition to a scope. The selected scope controls which resource requests the rule evaluates.

Switch back to the Policy pane from earlier.
Select Assignments in the Policy navigation pane.
Select Assign Policy at the top of the assignments page.
Select your verified nonproduction subscription in the Scope field.
Select Require a tag on resource groups in the Policy definition field.

The assignment now targets your nonproduction subscription. The selected definition applies specifically to resource groups.

How Does Deny Enforcement Work?

The selected definition uses a deny effect. Once the assignment applies, Azure blocks matching create or update requests before they reach the resource provider.

The existing rg-az104-untagged resource group stays in place because you created it before this assignment.

Configure the assignment

A subscription-level policy can affect unrelated deployments. Keeping it inside your verified nonproduction subscription contains that risk.

Parameters specialize a reusable policy definition. The non-compliance message tells an administrator why Azure rejected a request.

Enter Require Environment on resource groups in the Assignment name field.
Confirm Policy enforcement shows Enabled.
Select the Parameters tab.
Enter Environment in the Tag Name field.
Confirm Tag Name now shows Environment.
Add Resource groups must include the Environment tag for this AZ-104 sandbox. in the non-compliance message area.

The parameter summary now shows Environment. The non-compliance message area shows the sentence you entered.

Create the policy assignment

The review page is your final checkpoint before the subscription begins applying the rule. It helps you catch a misplaced scope or parameter.

Select Review + create.
Confirm Scope shows your verified nonproduction subscription.
Confirm Policy definition shows Require a tag on resource groups.
Confirm Assignment name shows Require Environment on resource groups.
Confirm Tag Name shows Environment.
Confirm Policy enforcement shows Enabled.
Select Create.

You have closed the manual-tagging gap at the subscription boundary. Expect Azure Policy to take about five minutes to apply the assignment to its scope.

Before you check, make a quick prediction about the scope and enforcement state you expect to see.

Select Assignments in the Policy navigation pane.
Locate Require Environment on resource groups in the assignments list.
Confirm its Scope is your verified nonproduction subscription.
Confirm its Policy enforcement status is Enabled.

You should see Require Environment on resource groups at your nonproduction subscription scope. Its policy enforcement status shows Enabled.

Can't Find the Assignment?

Return to your verified nonproduction subscription if the assignment appears under a different scope.
Confirm your Owner access still applies at subscription scope if assignment creation is unavailable.
Check the assignment name for an exact match with Require Environment on resource groups.

Help me troubleshoot this Azure Policy assignment.

Your Environment tag rule is enabled. Next, you'll test the rule against a new request. After that, you'll protect the sandbox from deletion.

Prove Policy and Lock Enforcement

Your Azure Policy assignment now requires an Environment tag at subscription scope. A configured guardrail only matters when you can see it change an outcome.

This step turns the baseline into evidence. This test starts with a management lock on the tagged sandbox.

You will also submit a noncompliant resource group request. The result proves whether the policy actively enforces your standard.

In this step, get ready to:

Apply a Delete lock to rg-az104-governance.
Prove that the lock blocks a deletion request.
Prove that the Environment policy denies an untagged request.

Protect the governance sandbox with a lock

A Delete management lock blocks deletion at its scope. At resource-group scope, it protects the group from a direct deletion request.

In the Azure portal search bar, enter Resource groups.
Select Resource groups from the search results.
Select rg-az104-governance from the resource-group list.
In the resource group's left menu, select Locks.
Select Add.
Enter prevent-accidental-delete as the lock name.
Choose Delete as the lock type.
Save the lock.

You'll see prevent-accidental-delete listed with lock type Delete.

Good progress. The governance sandbox now has a safeguard against direct deletion.

Test the Delete lock

A lock becomes credible when it blocks a real destructive request. The portal's normal deletion flow provides that evidence.

Deleting a resource group is the most serious action in this lab. This test targets only rg-az104-governance.

Before you submit the request, do you think verified Owner access can bypass the Delete lock?

In the resource group's left menu, select Overview.
Select Delete resource group.
Enter rg-az104-governance in the confirmation field.
Submit the deletion request.

You'll see a lock-related failure. The resource group remains intact.

That is the lock doing its job. The direct deletion request cannot bypass the safeguard.

Was the deletion request accepted?

Return to Locks for rg-az104-governance.
Confirm that prevent-accidental-delete appears with lock type Delete.
Add the missing lock if no matching row appears.
Repeat the deletion request after the lock appears.

Help me troubleshoot this lock.

Test the Environment policy

Policy propagation can take about five minutes, so a short delay here is expected. The lock exercise used part of that interval.

Why does the older untagged group remain?

The assignment evaluates new create or update requests. Existing resources such as rg-az104-untagged remain in place unless another process changes them.

Wait until at least five minutes have passed since you created the policy assignment.

The assignment has now had time to apply across the nonproduction subscription.

In the portal search bar, enter Resource groups.
Select Resource groups from the search results.

You'll see rg-az104-governance beside rg-az104-untagged. The test group is absent.

Select Create.
Choose your verified nonproduction subscription.

The creation form now targets the subscription governed by your policy assignment.

Enter rg-az104-policy-test as the resource-group name.
Select Central US as the region.

The form now describes a new resource group in the same region as your sandbox.

Leave all tag entries empty.

Before you create it, do you expect the manual-tagging gap to remain? Could the policy stop this request?

Select Review + Create.
Select Create.

You'll see 403 (Forbidden) for the request. The portal identifies Require Environment on resource groups as the policy assignment that prevented it.

The resource group is not created. Your Environment requirement now has observable enforcement behind it.

Was the test group created?

Open rg-az104-policy-test.
Select Delete resource group.
Enter rg-az104-policy-test in the confirmation field.
Submit the deletion request.
Wait until at least five minutes have passed since the policy assignment was created.
Repeat the untagged creation test.

Help me investigate a policy request that succeeded.

You've proved both guardrails with real requests. The lock protected the sandbox from deletion. The policy rejected a new resource group without the required tag.

Secret mission

Layer a Second Governance Rule

Your Environment rule checks where a resource group belongs. This mission adds an Owner rule. You will prove that one tag still fails before creating a resource group that satisfies both controls.

Clean Up Your Resources

Your lab in the Azure portal created no billable service resources. There are no charges for using Azure Policy on Azure resources.

Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

Resources you used:

Resource group rg-az104-governance in Central US with its governance tags.
Resource group rg-az104-untagged in Central US without tags.
Resource group rg-az104-compliant in Central US with both required tags.
Policy assignment Require Environment on resource groups at subscription scope.
Policy assignment Require Owner on resource groups at subscription scope.
Delete lock prevent-accidental-delete on rg-az104-governance.

Keep everything running

No action is needed. Choose this if you want to keep using the subscription as an AZ-104 governance sandbox.

Leave Require Environment on resource groups enabled to keep enforcing the Environment tag.
Leave Require Owner on resource groups enabled to keep enforcing the Owner tag.
Keep prevent-accidental-delete in place to protect rg-az104-governance from deletion.
Use this subscription only for nonproduction testing while the policy assignments remain enabled.
Keep all three resource groups available for future policy experiments at no ongoing cost.

Pause - I'll come back to this later

Pause both policy assignments to stop their deny effects during future resource-group changes. Remove the Delete lock while retaining all three resource groups.

Return to Policy in the Azure portal.
Select Assignments.
Open Require Environment on resource groups for editing.
Set Policy enforcement to Disabled.
Apply the assignment update.

The Environment rule is now paused. Resource-group requests no longer receive its deny effect.

Open Require Owner on resource groups for editing.
Set Policy enforcement to Disabled.
Apply the assignment update.
Return to rg-az104-governance from the Resource groups pane.
Select Locks.
Select prevent-accidental-delete.
Select Delete to remove the lock.

Both policy assignments are disabled. The resource groups remain available without active enforcement or deletion protection.

Delete - I don't want to use this again

Deleting these resources is permanent. This cleanup removes only the empty resource groups and governance controls created for the lab.

Return to rg-az104-governance from the Resource groups pane.
Select Locks.
Select prevent-accidental-delete.
Select Delete to remove the lock.
Confirm that prevent-accidental-delete is no longer listed.

The deletion safeguard is now removed. You can clean up the protected resource group after deleting the policy assignments.

Return to Policy in the Azure portal.
Select Assignments.
Locate Require Environment on resource groups.
Select its ellipsis menu.
Select Delete assignment.
Locate Require Owner on resource groups.
Select its ellipsis menu.
Select Delete assignment.

Both lab assignments should disappear from the assignments list. New resource-group requests are no longer evaluated against these two tag requirements.

Return to Resource groups in the Azure portal.
Open rg-az104-governance.
Select Delete resource group.
Enter rg-az104-governance to confirm the deletion.
Submit the deletion request.

The protected sandbox can now be deleted because its Delete lock is gone.

Return to Resource groups.
Open rg-az104-untagged.
Select Delete resource group.
Enter rg-az104-untagged to confirm the deletion.
Submit the deletion request.

The deliberately untagged resource group is now queued for deletion.

Return to Resource groups.
Open rg-az104-compliant.
Select Delete resource group.
Enter rg-az104-compliant to confirm the deletion.
Submit the deletion request.

Cleanup complete. The three resource groups and both policy assignments are removed from your nonproduction subscription.

Nice Work!

You did it! You built a working governance baseline in the Azure portal.

You've learned how to:

Organize a nonproduction sandbox with visible Environment and Owner tags. Compare it with rg-az104-untagged to expose the gap left by manual tagging.
Assign an Azure Policy deny rule at subscription scope to require the Environment tag. Confirm enforcement through a policy-blocked 403 (Forbidden) result.
Apply a Delete management lock to rg-az104-governance. Prove its protection by submitting a deletion request that the lock blocks.
Secret Mission: Layer a second Azure Policy assignment that requires the Owner tag. Create rg-az104-compliant with both required tags after proving that one tag alone is denied.

Ready to quiz yourself?