AZ-104
Deep Dive
Azure Policy lets you evaluate and control resource compliance at scale. It's one of the most frequently tested sections on the AZ-104: effects, scope, initiatives, and the difference between audit and deny are guaranteed questions.
Contents
Azure Policy is a governance service that lets you create, assign, and manage policies that control or audit resource configuration in Azure. Unlike RBAC (which controls who can do what), Policy controls which configurations are allowed, regardless of who performs the action.
RBAC
Who can do what. Controls the actions of users and services.
Policy
What configuration is allowed. Controls the state of resources.
Locks
What management operations are blocked on a specific resource.
Typical use cases
A policy definition is a JSON document describing the conditions under which it applies and the resulting effect. It has two key parts: policyRule (condition + effect) and parameters (configurable values).
| Field | Description | Example |
|---|---|---|
| displayName | Human-readable name of the policy | "Require tags on resources" |
| description | Detailed explanation of the purpose | "All resources must have a CostCenter tag" |
| mode | Scope: All (everything) or Indexed (only tags and location) | "All" |
| parameters | Values that can be parameterized in the assignment | { "tagName": { "type": "String" } } |
| policyRule.if | Logical condition that triggers the policy | { "field": "tags", "notContainsKey": "[parameters('tagName')]" } |
| policyRule.then.effect | Action when the condition is met | "deny" | "audit" | "modify" |
// Minimal structure of a Policy Definition
{
"mode": "All",
"parameters": {
"allowedLocations": {
"type": "Array",
"metadata": { "displayName": "Allowed locations" }
}
},
"policyRule": {
"if": {
"not": {
"field": "location",
"in": "[parameters('allowedLocations')]"
}
},
"then": { "effect": "deny" }
}
}Definition types
Built-in
Created and maintained by Microsoft. Not modifiable. Prefix /providers/Microsoft.Authorization/policyDefinitions/
Custom
Created by your organization. Require your own JSON. Limit: 500 custom policies per tenant.
The effect determines what happens when the policy's condition is met. The AZ-104 especially tests the difference between deny (blocks the operation) and audit (only logs it, doesn't block it).
| Effect | Behavior | Blocks? | When to use |
|---|---|---|---|
| deny | Blocks the PUT/PATCH operation if it violates the policy. Returns a 403 error. | ✅ Yes | A rule that must NEVER be violated |
| audit | Allows the operation but flags the resource as NonCompliant in the dashboard. | ❌ No | Visibility without operational impact |
| auditIfNotExists | Audits when a related resource does NOT exist (e.g., a VM without an extension). | ❌ No | Detecting missing related resources |
| modify | Adds, updates, or removes tags/properties during CREATE/UPDATE. | ❌ No | Automatically standardizing tags |
| append | Adds fields to the resource during CREATE/UPDATE (without removing existing ones). | ❌ No | Enforcing additional configuration |
| deployIfNotExists | Deploys a related resource if it does not exist (uses a managed identity). | ❌ No | Automatically remediating existing resources |
| disabled | The policy is defined but not evaluated. Useful for testing. | ❌ No | Temporarily disabling without deleting |
Effect evaluation order
When multiple policies apply, Azure evaluates the effects in this order of precedence:
An initiative (also called a Policy Set) groups multiple policy definitions into a single assignable object. It simplifies management when you need to apply 20+ related policies at once, like the CIS or PCI-DSS standards.
Important built-in initiatives
Policy vs Initiative
Policy Definition
A single rule: "deny resources outside eastus"
Initiative Definition
A set of rules: all the CIS rules together (150+ policies)
Policy Assignment
Assigning a policy OR an initiative to a scope
A policy only takes effect once it's assigned. The scope defines where it applies and can be a Management Group, Subscription, Resource Group, or an individual resource.
Scope hierarchy — inherits downward
Components of a Policy Assignment
The compliance dashboard (Portal → Policy → Compliance) shows the compliance status of all policies and resources. The possible states are:
Compliant
Resource meets the policy
Non-compliant
Resource violates the policy (if the effect is audit)
Exempt
Resource explicitly excluded
Conflict
Two conflicting policies on the same resource
Evaluation cycle
Policies are automatically evaluated every 24 hours. They are also evaluated immediately when:
az policy state trigger-scanPolicies with a deployIfNotExists or modify effect can remediate existing resources that don't comply with the policy. New resources are controlled automatically, but already existing resources require an explicit remediation task.
Remediation flow
▸1. Assign a policy with deployIfNotExists or modify effect
▸2. The policy evaluates existing resources → flags them as NonCompliant
▸3. Create a Remediation Task (Portal → Policy → Remediation → New)
▸4. The task uses the assignment's Managed Identity to execute the deploy/modify
▸5. Resources move to Compliant status once the task completes
Important requirement
The assignment's Managed Identity must have the Contributor role (or equivalent) on the scope where it will remediate. Without permissions, remediation fails silently.
Exclusion (Not Scope)
Defined at assignment time. Excludes specific sub-scopes from the assignment's scope.
The Dev-RG resource group is exempt from the policy even though it's within the subscription.
Exemption
A formal exception with an expiration and category. Shows in the dashboard as "Exempt" (not as NonCompliant).
| Name | Effect | What it does |
|---|---|---|
| Allowed locations | deny | Restricts where resources can be created |
| Allowed virtual machine size SKUs | deny | Limits allowed VM sizes |
| Require a tag and its value on resources | deny | Requires a specific tag with a specific value |
| Add a tag to resources | modify | Automatically adds a tag if it doesn't exist |
| Audit VMs that do not use managed disks | audit | Detects VMs with unmanaged disks |
| Deploy Log Analytics agent for Windows VMs | deployIfNotExists | Installs the AMA agent on new VMs |
| Storage accounts should use customer-managed keys | audit | Audits accounts without CMK configured |
| MFA should be enabled on accounts with write permissions | auditIfNotExists | Audits admin accounts without MFA |
deny vs audit — when it blocks
Audit does NOT block resource creation, it only flags it as NonCompliant. Only deny prevents the operation. Typical question: "You need to make sure no one can create resources outside westeurope" → deny, not audit.
Policy is NOT retroactive by default
A policy assigned today does not remediate existing resources. It only controls new or modified resources. To remediate existing ones you need a Remediation Task (only with deployIfNotExists or modify).
deployIfNotExists requires a Managed Identity
When you assign a policy with a deployIfNotExists or modify effect, you MUST configure a managed identity on the assignment. Without it, remediation won't work.
Policy vs RBAC: independent and complementary
RBAC deny prevents performing the action. Policy deny prevents the outcome (the resource in that state). An Owner can be blocked by Policy even if RBAC doesn't restrict them.
Custom policy limits
500 custom policy definitions per tenant. 200 custom initiative definitions. 200 exemptions per assignment. These limits show up in design scenarios.
Did you get this topic?
Test what you just learned
A company needs to guarantee that NO Azure resource can be created outside the westeurope and northeurope regions, including resources created by Global Administrators. What is the correct solution?
Put what you learned to the test with original AZ-104 exam questions.
Start AZ-104 mock examUnlimited mock exams with the Pro plan
Log in to track your progress.