Exercise: Azure Policy

Natasha Ong
This is some text inside of a div block.
4 min read

Exercise Overview:

In this exercise, you will:

  • Create a management group
  • Create a new policy definition
  • Evaluate compliance

But before that, here's a recap of key concepts related to Azure Policy:

Azure Administrators use Azure Policy to create policies that define conventions for resources.

  • A policy definition = the rules for when and how a policy should be applied. For example, a policy definition can stop virtual machines in your account from being set up if they have a public IP address. Another example is limiting the places users can choose when deploying resources.
  • An initiative definition = a set of policy definitions that help you track your larger compliance goals.

There are four basic steps to create and work with policy definitions:

  1. Create policy definitions - You can create your own policy definitions, or choose from built-in definitions in Azure Policy.
  2. Create an initiative definition - You can create your own initiative definitions, or use built-in definitions in Azure Policy.
  3. Scope the initiative definition - You can limit the scope of an initiative definition to specific management groups, subscriptions, or resource groups.
  4. Determine compliance - After you assign an initiative definition, Azure Policy can help you the state of compliance for all your resources.

Now let's get back to action!

Task 0: Search for the Management Groups Service in Azure

  1. You can create a management group with Azure Policy by using the Azure portal, PowerShell, or the Azure CLI. In the Azure portal, head to the Management Groups console.

Here's what you'll see in the Azure portal:

Task 1: Create Management Group

Let's create your first management group in Azure.

1. Click the Create button, assign an unique Management Group ID (e.g. mymanagementgroupID), and an unique Management group display name (e.g. My Management Group).

2. Wait for Azure to create the new management group - it might take up to a minute before the Azure portal finally refreshes with your fancy new group inside!

Task 2: Assign a policy

The first step in enforcing compliance with Azure Policy is to assign a policy definition. In this example, assign the built-in policy definition called Inherit a tag from the resource group if missing.

Can you decipher what this policy does based on its name? No worries if not! This policy adds automatically tags a resource if you don't create/update it with a tag yourself. The resource will have the exact same tag as its resource group.

1. Go to the Azure portal to assign policies. Search for and select Policy.

Screenshot of searching for Policy in the search bar.

2. Select Assignments on the left side of the Azure Policy page. An assignment is a policy applied to a specific scope e.g. to the resource level, resource group level, management group level.

Screenshot of selecting the Assignments node from the Policy Overview page.

3. Select Assign Policy from the top of the Policy - Assignments page.

Screenshot of selecting the 'Assign policy' button on the Assignments page.

4. On the Assign Policy page's Basics tab, select the Scope by selecting the ellipsis and selecting your management group - it might already be selected for you. Select Select at the bottom of the Scope page.

5. Exclusions start at one level lower than the level of the Scope. Exclusions are optional, so let's leave it blank for now.

6. Select the Policy definition ellipsis to open the list of available definitions. You can filter the policy definition Type to Built-in to view all and read their descriptions.

Screenshot of the search filter while selecting a policy definition.

7. Select Inherit a tag from the resource group if missing. If you can't find it right away, type inherit a tag into the search box and then press ENTER or select out of the search box. Select Add at the bottom of the Available Definitions page once you have found and selected the policy definition.

8. The Assignment name is automatically populated with the policy name you selected, but you can change it. For this example, leave Inherit a tag from the resource group if missing. You can also add an optional Description. The description provides details about this policy assignment.

9. Leave Policy enforcement as Enabled. Disabling it allows you to simulate the policy's impact without taking real actions on resources.

10. Assigned by is automatically filled based on who is logged in. This field is optional, so custom values can be entered.

11. Select the Parameters tab at the top of the wizard.

12. For Tag Name, enter Environment.

13. Select the Remediation tab at the top of the wizard.

14. Leave Create a remediation task unchecked. This box allows you to create a task to alter existing resources in addition to new or updated resources.

15. Select the Non-compliance messages tab at the top of the wizard.

16. Set the Non-compliance message to This resource doesn't have the required tag. This custom message is displayed when a resource is denied or for non-compliant resources during regular evaluation.

17. Select the Review + create tab at the top of the wizard.

18. Review your selections, then select Create at the bottom of the page.

Task 3: Your policy in action

Let's see your first policy in action. This time, you will see what happens if we forgot to add a tag to a newly created resource.

  1. Create a new resource, then follow the steps in creating a new Blob Storage.
  2. Under Tags, leave the details blank.

3. Select Review, wait Azure to run its validation, then click Create.

4. After creating a new resource, go to Policy in the search bar, then to Compliance. You should see a non-compliant resource.

Nice! That's Azure Policy's power in helping you evaluate the compliance of your resources against the rules you've set up.

Task 3: Create and add new policy definitions

Now that you've assigned a built-in policy definition, you can do more with Azure Policy. Next, create a new custom policy to save costs by validating that virtual machines created in your environment can't be in the G series*. This way, every time a user in your organisation tries to create a virtual machine in the G series, the request is denied.

*The G series in Azure is a category of powerful virtual machines with high computing power and memory, making them suitable for demanding tasks. An organisation would want to make sure that people don't accidentally use these powerful but potentially expensive virtual machines.

1. Select Definitions under Authoring in the left side of the Azure Policy page.

Screenshot of the Definitions page under Authoring group.

2. Select + Policy definition at the top of the page. This button opens to the Policy definition page.

3. Enter the following information:

  • The management group or subscription in which the policy definition is saved. Select by using the ellipsis on Definition location.
Note: If you plan to apply this policy definition to multiple subscriptions, the location must be a management group that contains the subscriptions you assign the policy to. The same is true for an initiative definition.
  • The name of the policy definition - Require VM SKUs not in the G series
  • The description of what the policy definition is intended to do - This policy definition enforces that all virtual machines created in this scope have SKUs other than the G series to reduce cost.
  • Choose from existing options (such as Compute), or create a new category for this policy definition.

4. Write your policy using JSON, specifying

  • The policy parameters.
  • The policy rules/conditions, in this case - VM SKU size equal to G series
  • The policy effect, in this case - Deny.

Here's what the JSON should look like:

5. Select Save.

Task 4: Create an Initiative Definition

1. Select Definitions under Authoring in the left side of the Azure Policy page.

Screenshot of the Definitions page under the Authoring group.

2. Select + Initiative Definition at the top of the page to open the Initiative definition wizard.

3. Use the Initiative location ellipsis to select a management group or subscription to store the definition. If the previous page was scoped to a single management group or subscription, Initiative location is automatically populated.

4. Enter the Name and Description of the initiative.

5. This example validates that resources are in compliance with policy definitions about getting secure. Name the initiative Get Secure and set the description as: This initiative has been created to handle all policy definitions associated with securing resources.

6. For Category, choose from existing options or create a new category.

7. Set a Version for the initiative, such as 1.0.

8. Select Next at the bottom of the page or the Policies tab at the top of the wizard.

9. Select Add policy definition(s) button and browse through the list. Select the policy definition(s) you want added to this initiative. For the Get Secure initiative, add the following built-in policy definitions by selecting the checkbox next to the policy definition:

  • Allowed locations
  • Endpoint protection should be installed on machines
  • Non-internet-facing virtual machines should be protected with network security groups
  • Azure Backup should be enabled for Virtual Machines
  • Disk encryption should be applied on virtual machines
  • Add or replace a tag on resources (add this policy definition twice)

10. After selecting each policy definition from the list, select Add at the bottom of the list. Since it's added twice, the Add or replace a tag on resources policy definitions each get a different reference ID.

Screenshot of the selected policy definitions with their reference ID and group on the initiative definition page.
Note: The selected policy definitions can be added to groups by selecting one or more added definitions and selecting Add selected policies to a group. The group must exist first and can be created on the Groups tab of the wizard.

11. Select Next at the bottom of the page or the Groups tab at the top of the wizard. New groups can be added from this tab. For this tutorial, we aren't adding any groups.

12. Select Next at the bottom of the page or the Initiative parameters tab at the top of the wizard. If we wanted a parameter to exist at the initiative for passing to one or more included policy definitions, the parameter is defined here and then used on the Policy parameters tab. For this tutorial, we aren't adding any initiative parameters.

Note: Once saved to an initiative definition, initiative parameters can't be deleted from the initiative. If an initiative parameter is no longer needed, remove it from use by any policy definition parameters.

13. Select Next at the bottom of the page or the Policy parameters tab at the top of the wizard.

14. Policy definitions added to the initiative that have parameters are displayed in a grid.

The "value type" can be one of three options: 'Default value,' 'Set value,' or 'Use Initiative Parameter.' If you choose 'Set value,' you need to enter the relevant value in the 'Value(s)' field. If the policy definition includes a list of allowed values for a parameter, the entry box will be a dropdown list. If you opt for 'Use Initiative Parameter,' a dropdown list will appear with the names of initiative parameters that you've created on the 'Initiative parameters' tab.
Screenshot of the options for allowed values for the allowed locations definition parameter on the policy parameters tab of the initiative definition page.

15. Set the 'Allowed locations' value type to 'Set value' and select 'East US 2' from the dropdown list.

16. For the two instances of the Add or replace a tag on resources policy definitions, set the Tag Name parameters to 'Env' and 'CostCenter and the Tag Value parameters to 'Test' and 'Lab' as shown below.

Screenshot of the entered options for allowed values for the allowed locations definition parameter and values for both tag parameter sets on the policy parameters tab of the initiative definition page.

17. Leave the others as 'Default value'.

This configuration adds or updates an 'Env' tag to 'Test' and a 'CostCenter' tag to 'Lab' for resources covered by the assignment.

18. Select Review + create at the bottom of the page or at the top of the wizard.

19. Review the settings and select Ceate.

Task 5: Revisit the compliance of Azure Resources

Nice - you have your policies defined, your initiative definition created, and your policies assigned to affected resources.

The last step is to evaluate the state of compliance for your scoped resources. We have seen this a while ago in the previous task.

The following example shows how you can use the Compliance feature to look for non-compliant initiatives, policies, and resources.

1. Go to the Compliance tab under Policy to check the report as shown:

Azure Policy has evaluated your resources against the policy initiatives you've set up! Each resource is either compliant or non-compliant. You're now ready to identify non-compliant resources to understand the compliance state of your environment.

Task 6: Identify non-compliant resources

1. Select Compliance in the left side of the page. Then locate Audit VMs that do not use managed disks policy assignment you created.

Screenshot of compliance details on the Policy Compliance page.

2. If there are any existing resources that aren't compliant with this new assignment, they appear under Non-compliant resources.

Task 7: Clean up resources

To remove the assignment created, follow these steps:

  1. Select Compliance (or Assignments) in the left side of the Azure Policy page and locate  Audit VMs that do not use managed disks.
  2. Right-click the Audit VMs that do not use managed disks policy assignment and select Delete assignment.


You created a Management Group, an Azure policy, and checked its compliance. Keep it up chief!

Bonus for the curious

This table outlines how various policy actions determine whether a resource is compliant or non-compliant based on different conditions:

  • Resource state: Describes the state of the resource, whether it's new, updated, or already exists.
  • Effect: Represents different policy actions such as Audit, Modify, DeployIfNotExist, etc.
  • Policy evaluation: Indicates whether the condition specified in the policy (IF statement) is true or false. An IF statement could be something like "IF: The virtual machine does not use managed disks."
  • Compliance state: Reflects whether the resource is considered compliant or non-compliant based on the policy evaluation.

Note: The DeployIfNotExist and AuditIfNotExist effects require the IF statement to be TRUE and the existence condition to be FALSE to be non-compliant. When TRUE, the IF condition triggers evaluation of the existence condition for the related resources.

For "DeployIfNotExist" and "AuditIfNotExist" to say a resource is non-compliant, two things must happen:

  1. The initial condition (IF statement) should be true. i.e. IF: The virtual machine does not use managed disks.
  2. The thing it's looking for should not exist.

So, if both of these are true, it means your resource is not compliant. It checks if the thing it's asking for is there or not when the initial condition is true.