Azure Policy and initiatives

The tag standard Harrow & Finch adopted on November 4 lasted less than a day before somebody broke it. On the morning of November 5, Liam Ferreira, the junior developer on StockLine, created a resource group for a quick experiment and forgot the tags. Nobody blamed him; he was in a hurry and the portal did not stop him. "That is the point," Renata told Theo. "A standard that depends on everyone remembering will fail. We need Azure to apply the rules for us." That afternoon they assigned their first set of Azure Policy rules to the HarrowFinch management group, and the cloud started enforcing the company's standards on its own.

What Azure Policy does

Azure Policy is a service that creates, assigns and manages rules for Azure resources. Each rule describes a condition that resources should meet, such as being in an approved region, carrying a required tag or using encryption, and an effect that says what happens when a resource does or does not meet it. Azure Policy evaluates resources when they are created or changed, and also checks existing resources regularly, reporting which ones are compliant and which are non-compliant. Depending on the effect, it can block non-compliant changes, record them for review, or fix them automatically.

It helps to contrast Azure Policy with role-based access control (RBAC), which MSAZ-101 introduced. RBAC controls who can do what: whether Liam may create resource groups in the nonproduction subscription. Azure Policy controls what resources must look like, regardless of who creates them: whether any resource group, created by anyone, must have a cost-center tag. A user with Owner rights can still be blocked by a policy. The two work together: RBAC limits actions to the right people, and policy keeps every resource within the organization's rules.

Policy definitions

A policy definition describes one rule. It is written in JSON and has a condition, written as an if block, and an effect, written as a then block. The condition can test almost any property of a resource: its type, its location, its tags, its SKU or settings deep inside its configuration. Definitions can take parameters, so one definition such as Allowed locations can be reused with different lists of regions for different scopes.

Azure includes a large library of built-in definitions written by Microsoft, covering common needs such as allowed locations, allowed virtual machine sizes, required tags, inheriting tags, requiring HTTPS on storage accounts, auditing virtual machines without backup and many security settings. Organizations can also write custom definitions for rules of their own. Most organizations start with built-in definitions, because they are tested and maintained, and add custom ones only where needed.

{
  "if": {
    "not": {
      "field": "location",
      "in": "[parameters('listOfAllowedLocations')]"
    }
  },
  "then": {
    "effect": "deny"
  }
}

Effects

The effect decides what Azure Policy does with a resource that matches the condition. Choosing the right effect is the most important design decision, because a deny that is too broad can stop legitimate work, while an audit that nobody reads changes nothing.

Modify and DeployIfNotExists change resources on the organization's behalf, so their assignments use a managed identity with the permissions needed to make those changes. They act on new and updated resources automatically. For resources that existed before the assignment, you create a remediation task, which applies the fix to the non-compliant resources already in the scope.

Initiatives

Real governance needs many rules. An initiative, also called a policy set, groups several policy definitions so they can be assigned and tracked as one unit with one compliance figure. Harrow & Finch created a custom initiative called HF baseline with five definitions: allowed locations, require a cost-center tag on resource groups, inherit the cost-center tag from the resource group if missing, allowed virtual machine size families for nonproduction, and audit virtual machines without backup.

Microsoft also provides built-in initiatives. The Microsoft cloud security benchmark initiative, which Microsoft Defender for Cloud uses as its default, contains a large set of security checks across services. Regulatory compliance initiatives map Azure Policy definitions to the controls of standards and regulations, such as ISO 27001, PCI DSS and NIST SP 800-53. Assigning one of these does not make an organization compliant by itself, because many controls are about people and processes, but it shows which technical settings support or break each control.

Assignments and scope

A definition or initiative does nothing until it is assigned to a scope: a management group, a subscription, a resource group or, rarely, a single resource. Assignments are inherited by everything below the scope, so assigning HF baseline to the HarrowFinch management group applies it to every subscription and resource group under it, including ones created later. This is one of the main reasons organizations build a management group hierarchy, as Harrow & Finch did in September.

An assignment sets the parameter values, such as the list of allowed regions, and can exclude child scopes that should not be covered. Separately, exemptions can record that a particular resource or scope is temporarily or permanently excused from a rule, with a reason and an optional expiry date. Exemptions are better than quietly removing rules because they leave an audit trail. When the web team needed a test resource in another region to measure response times from overseas customers, Renata created a 30-day exemption rather than loosening the rule for everyone.

az policy assignment create \
  --name hf-allowed-locations \
  --display-name "HF allowed locations" \
  --scope /providers/Microsoft.Management/managementGroups/HarrowFinch \
  --policy e56962a6-4747-49cd-b67b-bf8b01975c4c \
  --params '{ "listOfAllowedLocations": { "value": [ "centralus", "eastus2" ] } }'

Evaluation and compliance

Azure Policy evaluates resources at several moments: when a resource is created or updated, when an assignment is created or changed, and during a regular compliance scan of existing resources that runs about once a day. You can also start an on-demand scan. Results appear on the compliance dashboard, which shows, for each assignment and initiative, how many resources are compliant, how many are not and why. Each non-compliant resource can be opened to see which condition it failed.

The first scan after the HF baseline assignment found what Renata expected: the resource groups created before the policy, including Liam's experiment, were missing tags, and two test virtual machines had no backup, which was fine for test but showed up because Renata had mistakenly assigned the backup audit one level too high. She moved that assignment to the Production management group. A remediation task then copied cost-center tags onto the existing resources, and Liam added the missing tag to his resource group himself, a little embarrassed.

Theo wrote a small script to show the logic of evaluation. It checks a list of resources against two rules, the way Azure Policy reports compliance for an initiative.

allowed = {"centralus", "eastus2"}
resources = [
    {"name": "rg-stockline-prod", "location": "centralus", "tags": {"cost-center": "4100"}},
    {"name": "rg-liam-test",      "location": "centralus", "tags": {}},
    {"name": "rg-web-latency",    "location": "westeurope",    "tags": {"cost-center": "4300"}},
    {"name": "rg-backup-dr",      "location": "eastus2",    "tags": {"cost-center": "4100"}},
]
compliant = 0
for r in resources:
    problems = []
    if r["location"] not in allowed:
        problems.append("location not allowed")
    if "cost-center" not in r["tags"]:
        problems.append("missing cost-center tag")
    if problems:
        print(f"{r['name']:18s} NON-COMPLIANT: {'; '.join(problems)}")
    else:
        compliant += 1
print(f"{compliant} of {len(resources)} resources compliant")

rg-liam-test       NON-COMPLIANT: missing cost-center tag
rg-web-latency     NON-COMPLIANT: location not allowed
2 of 4 resources compliant

Rolling out policy safely

A deny policy assigned carelessly can stop a whole company's deployments. Renata's approach follows common practice. Start new rules with the Audit effect, read the compliance results for a week, fix the existing resources and talk to the teams affected, then switch to Deny. Assign at the highest scope where the rule truly applies, but test first on a nonproduction management group. Keep the number of custom definitions small, document every exemption with a reason and an expiry, and review the compliance dashboard as part of the monthly governance meeting. Policies can also be stored as code and deployed through pipelines, which lesson 10 touches on.

Policy and the developer experience

A rule that blocks people without explanation creates frustration and workarounds. Renata spent time on the developer experience of the HF baseline. Every custom definition has a clear display name and description, and every Deny assignment has a non-compliance message that appears in the error when a request is blocked, such as: Resource groups must have a cost-center tag with a finance code; see the cloud standards page. Liam's next resource group was blocked by exactly that message, and he fixed it in thirty seconds instead of opening a ticket.

She also published the list of assigned rules on the team's wiki page with the reason for each one, the effect, the scope and the person to ask for an exemption. Governance that people understand is governance they follow. When the web team later asked why they could not use a region in Europe for a latency test, the answer was already on the page, along with the exemption process that let them do it for thirty days.

Policy also helps outside the cloud team. Sunil uses the compliance dashboard to answer security questions quickly: how many storage accounts allow public access, how many VMs lack backup, how many resources are outside approved regions. Each number links to the list of resources involved, so a question from the audit committee becomes a five-minute check rather than a week of spreadsheets.

One more design choice matters: where definitions live. Custom definitions saved at the HarrowFinch management group can be assigned anywhere beneath it, so Renata stored them there rather than in individual subscriptions. That keeps one copy of each rule, and a fix to a definition applies everywhere it is assigned.