This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
If a Policy is applied with the deny option to a Resource group, what happens to already existing noncompliant resources in that group?
The noncompliant resources get deleted.
No changes are made to the resources themselves but they're listed as noncompliant resources.
The resources have a read-only lock on them so that no changes can be made to them.
The resources become unusable and can't be used to connect to other resources.
What happens when you have a Policy set as deny at the Subscription level and the same Policy set as audit at the Resource group level?
The two Policies would cancel each other out and have no effect.
The Policy set as audit would take effect.
The Policy set as deny would take effect.
You would get an error when you attempt to deploy the second Policy that contradicts the first one, so you would be unable to proceed.
You have an Azure Policy applied at the Subscription level, but one of your AKS clusters needs to be exempt from a specific policy. What's the best way to handle the situation?
Move the Azure Kubernetes Service (AKS) cluster to another Subscription and apply the Policy to the previous Subscription.
Apply the Policy at the resource level to the resources that need to have it in that Subscription.
Tell your coworkers not to deploy resources that aren't compliant with that Policy and add it to your training manual.
Add an exclusion to the AKS cluster Resource group that the Policy shouldn't apply to.
You must answer all questions before checking your work.
Was this page helpful?