Experts answer your Azure Policy questions

Image of blue background with Azure logo and question marks Image of blue background with Azure logo and question marks

Azure Policy gives us so much control over our Azure environment—making it a crucial part of good governance. We rounded up your Azure Policy questions and had Azure experts answer them.

Have you ever noticed that the more you learn about a topic, the more questions you have about it? Last week Microsoft’s Jussi Roine (@jussiroine) and Azure MVP Stephane Lapointe (@s_lapointe) hosted a webinar on Azure Policy essentials where they offered lots of insights and advice on creating governance plans. And they walked us through how to use tools such as Azure Policy, Azure Blueprints, and Azure Arc.

And even though they were thorough with their information and we learned a lot, the chatbox was still full of questions—which is amazing!

So for all of you who might have had questions, or those who may just wonder about Azure Policy, we rounded up your questions and our expert answers to help make sure you have all the information you need in order to run an efficient and organized Azure environment.  

ShareGate has helped IT professionals at companies such as Ikea, Fujitsu, and Siemens succeed with the Microsoft cloud. We hope that we answer some of your questions here—but if you’re looking for more hands-on, immediate help, check out how ShareGate Overcast can make managing Azure even easier. 

What's the difference between Azure Policy and Azure Blueprints?

Azure Policy allows you to set explicit allow or deny actions against your resources and resource groups. Azure Blueprints allows you to package multiple definitions to subscriptions. With a blueprint, you control what is automatically deployed and what permissions, policies, and locks should be assigned for scopes in that subscription.

For example, a common Azure policy is to lock down all services you deploy in a specific Azure region. With Azure Blueprints, you can deploy a network resource like a virtual network and lock down that resource group to only Network Administrators of your organization. Instead of figuring out all the different policies you would need to put in place to deny that action, you can create one blueprint. And you can amend and add on to blueprints later as well.

Another key difference between Azure Policy and Azure Blueprints is their locking mechanisms. With the typical policy lock in Azure, the owner has the power to remove a lock. Using blueprint, you can categorically deny everyone except a certain group of people or applications, even if that includes the owner of the resource.

Even if you manually checked the ID of the owner and set multiple policies to try to lock them out, the owner can still remove those policies. So blueprints offer you more control in that way.

Is there a risk to moving existing subscriptions from one management group to another?

There can be. Policies and role-based access controls (RBACs) can be set at the management group level. If you want to push the same policies across multiple subscriptions, being able to set these definitions at the management group level can save you time and manual tedium.

Screenshot of the moving a subscription from one management group to another in Azure

But if you move a subscription to a different management group, it will inherit the policies and RBACs of the new management group. So, make sure you know what changes will be made to your subscription if it’s moved, before you move it.

Can Azure Policy influence both Azure Identity and Access Management (IAM) and Azure Active Directory (AAD) roles?  

Azure Policy only impacts roles within Azure, which means policies will affect RBAC, but they won't affect AAD roles.

Is there a faster way to see the results of a policy evaluation than running it through Azure Policy Engine?  

It can take a long time to get results from an Azure Policy Engine evaluation. There’s a way with REST API that you can manually trigger the evaluation of your policies.

You can translate the condition you put inside your policy to an Azure Resource Graph query. Then you can instantly see which resources and resource groups would be affected by your policy. 

Screenshot of Microsoft Azure Resource Graph Explorer

Using Azure Resource Graph, you can get the results in a matter of seconds instead of having to wait for the Azure Policy Engine to run through all of your resources—which can take hours. And using Azure Resource Graph can help you can dramatically reduce the feedback loop for your development.

What is the difference between AuditIfNotExist and DeployIfNotExist? 

When you set the action to AuditIfNotExist, you’ll receive a report detailing any resources that match your ‘if’ condition but are missing a component specified. When you set the action to DeployIfNotExist, instead of auditing and creating a report, it will automatically deploy an Azure Resource Manager (ARM) template.  

DeployIfNotExist is an automatic remediation option available to you. If you have a virtual machine (VM) that should have a diagnostic extension but doesn’t, DeployIfNotExist will be triggered automatically when you deploy that VM. This allows you to ensure the diagnostic extension is installed on VMs even if the person creating it didn’t configure that extension.  

This will invoke an ARM template, so you’ll need credentials with your policy to push it down. You can do that by assigning a Managed Identity to it. 

I wrote an Azure policy and applied it to a subscription, but I noticed that it didn’t auto-remediate the subscription. Why is that?  

If you enable auto-remediation, it will only apply to new resources in your subscription. In an effort to prevent negative side effects, it won’t auto-remediate existing resources. But you can manually trigger the remediation for existing resources.  

Can I have two definitions in one policy? 

Typically, when you create a policy in Azure, it will only do one thing. You can create a policy with two scenarios, but that can get messy. What is often easier is creating one policy per scenario and then grouping multiple policies together in one Policy Initiative.  

You can group between 1-N policies together in an initiative, assign that definition, and deploy them together. You can add or remove policy definitions to initiatives, so it’s essentially a group of policies that can evolve over time. 

There are constantly new releases and updates in the Azure cloud. But before new features can help you manage your Azure environment more easily, you have to understand how they work. For more details on Azure policy, you can watch Jussi and Stephane’s webinar or read the session recap

If you’ve got more questions about Azure and its tools, ask them in the comments below! 

Thursday, May 7 | 9am-5pm ET

Discover Azure governance best practices from the experts at this one-day virtual event

Recommended by our team

What did you think of this article?