Module: Manage Azure Identities and Governance

Lesson: Assigning Policies and Initiatives

Introduction: Why Policy Matters in the Cloud

In the early days of cloud computing, organizations often operated under a "wild west" mentality. Developers and administrators would spin up resources as needed, often without regard for naming conventions, location restrictions, or security configurations. While this allowed for rapid innovation, it quickly led to ballooning costs, security vulnerabilities, and significant management overhead. As organizations scale their presence in Azure, the need for automated guardrails becomes not just a benefit, but a fundamental requirement for survival.

Azure Policy is the primary mechanism for implementing these guardrails. It allows you to enforce rules on your cloud environment so that resources stay compliant with your corporate standards and service-level agreements. By assigning policies and initiatives, you translate high-level business requirements—such as "all resources must be tagged" or "only specific virtual machine sizes are allowed"—into technical constraints that the Azure platform enforces automatically.

Understanding how to assign these policies effectively is the difference between a chaotic, expensive environment and one that is predictable, secure, and cost-effective. This lesson will guide you through the mechanics of policy assignment, the distinction between individual policies and initiatives, and the best practices for managing these configurations at scale.

Understanding the Core Components: Policies vs. Initiatives

Before we dive into the assignment process, it is critical to distinguish between the two primary building blocks of Azure governance: Policies and Initiatives.

A Policy Definition is a single rule that evaluates a resource against a specific condition. For example, a policy might check if a resource has a specific tag, or if a storage account is configured to allow public access. Each policy definition contains the logic for what to evaluate and the effect to take if the condition is met (such as Deny, Audit, or DeployIfNotExists).

An Initiative Definition (often called a Policy Set) is a collection of policy definitions grouped together toward a single goal. Instead of assigning fifty individual policies to a subscription, you can bundle them into a single initiative. This makes management significantly easier, as you only need to manage one assignment for a group of related rules.

Callout: Policy vs. Initiative Think of a Policy as a single line item in a contract—for example, "Employees must wear a safety helmet." Think of an Initiative as the entire safety manual, containing all the rules for a construction site. While you could enforce each rule one by one, it is far more efficient to enforce the entire manual at once to ensure total compliance.

Comparison Table: Policies vs. Initiatives

Feature	Policy Definition	Initiative Definition
Scope	Single rule/condition	Collection of multiple rules
Complexity	Low; focused on one check	Higher; provides a holistic view
Assignment	One per assignment	One per assignment (for the set)
Best Use Case	Unique, specific requirements	Compliance standards (ISO, NIST, etc.)

The Assignment Lifecycle: How Policies are Applied

Assigning a policy is the act of linking a policy definition (or initiative) to a specific scope within your Azure hierarchy. The hierarchy in Azure flows from Management Groups to Subscriptions, then to Resource Groups, and finally to individual Resources.

When you assign a policy, it applies to all resources within that scope, including any child scopes. For example, if you assign a policy to a Management Group, it automatically inherits down to every subscription within that group. This is the most efficient way to maintain governance, as it prevents "configuration drift" where different teams might accidentally disable or ignore security settings.

Step-by-Step: Assigning a Policy through the Azure Portal

Navigate to Policy: Open the Azure Portal and search for "Policy" in the top search bar.
Select Definitions: Click on "Definitions" in the left-hand menu to browse the built-in policies provided by Microsoft.
Choose a Policy: Use the filter to find a specific policy, such as "Allowed resource locations." Click on the policy name to view its JSON definition.
Initiate Assignment: Click the "Assign" button at the top of the screen.
Configure Scope: Select the subscription or resource group where this policy should be enforced. You can also specify exclusions if certain resources should be exempt.
Parameters: If the policy requires parameters (e.g., a list of allowed locations), define them in the "Parameters" tab.
Remediation: If you are using a policy that can change resources (like DeployIfNotExists), choose whether to create a managed identity to perform these remediations.
Review and Create: Review your settings and click "Create."

Tip: Use Management Groups Always try to assign policies at the highest possible level in your hierarchy (Management Group level). This ensures that all existing subscriptions and any future subscriptions added to that group automatically inherit the governance rules, saving you from manual administrative work later.

Working with Parameters and Logic

Many policies are not "hard-coded" to a single value. Instead, they use parameters to allow flexibility. For instance, instead of a policy that says "Only allow US East," you might have a policy that says "Only allow locations specified in the list."

When assigning such a policy, you must provide the values for these parameters. This allows you to use the same policy definition for different departments or regions. If your Finance department requires resources to be tagged with CostCenter: Finance, and your Engineering department requires CostCenter: Engineering, you can assign the same "Require Tag" policy twice, providing different parameter values for each assignment.

Code Snippet: Example Policy Definition (JSON)

Below is a simplified example of how a policy definition looks behind the scenes. Understanding this structure helps when you need to troubleshoot why a policy is or is not triggering.

{
  "properties": {
    "displayName": "Require a tag on resources",
    "policyType": "BuiltIn",
    "mode": "Indexed",
    "parameters": {
      "tagName": {
        "type": "String",
        "metadata": {
          "description": "The name of the tag to require."
        }
      }
    },
    "policyRule": {
      "if": {
        "field": "[concat('tags[', parameters('tagName'), ']')]",
        "exists": "false"
      },
      "then": {
        "effect": "deny"
      }
    }
  }
}

In this example, the policyRule checks if a specific tag exists. If it does not exist (exists: false), the effect is deny, meaning Azure will block the creation of the resource.

Practical Examples of Policy Assignments

To truly understand the power of Azure Policy, let's look at three common scenarios that administrators face in the real world.

1. Enforcing Resource Naming Conventions

Consistency in naming is vital for billing and operations. You can assign the "Resource names should match a pattern" policy to a Resource Group. By providing a regex (regular expression) as a parameter, you can ensure that all virtual machines follow a standard like vm-prod-app-001. If a user tries to name a resource test-vm, the deployment will be rejected.

2. Restricting Resource Locations

Data residency is a major concern for many industries. You can assign the "Allowed locations" policy to a Subscription. By selecting only "West Europe," you prevent any user from accidentally deploying a database or storage account in a region that violates local data laws or privacy regulations.

3. Enforcing Tagging for Cost Allocation

Cost management is nearly impossible without accurate tagging. You can assign the "Require a tag on resources" policy to a Management Group. This ensures that every time a resource is created, the user must provide a Department or ProjectID tag. If the tag is missing, the resource creation fails, forcing the user to provide the metadata needed for accurate billing reports.

Warning: The 'Deny' Effect Be careful when using the Deny effect on existing environments. If you assign a policy with a Deny effect to a scope that already contains resources that violate the policy, the existing resources will not be deleted, but you will be unable to modify them until they are made compliant. Always start with Audit or AuditIfNotExists if you are applying policies to an existing, live environment.

Advanced Assignment: Remediation and Managed Identities

Some policies go beyond simply blocking non-compliant actions; they can actively fix them. These are known as DeployIfNotExists or Modify policies. For example, if you have a policy that requires all storage accounts to have "Secure Transfer" enabled, you can use a DeployIfNotExists policy to automatically enable this setting if a user forgets.

To perform these automated changes, the policy needs permission to modify your resources. This is where Managed Identities come into play. When you assign a policy that requires remediation, Azure will ask you to assign a Managed Identity to the assignment. This identity acts as a service account that has the necessary permissions (defined in your Role-Based Access Control) to perform the specific remediation task.

Steps to Enable Remediation:

Assign a policy that supports DeployIfNotExists or Modify.
During the assignment process, ensure the "Managed Identity" checkbox is selected.
Once the assignment is created, go to the "Remediation" tab in the Azure Policy blade.
Select the policy assignment and click "Remediate."
Azure will trigger a task to evaluate all existing resources and apply the fix to those that are non-compliant.

Best Practices for Governance at Scale

Managing policies across thousands of resources requires a disciplined approach. Here are the industry-standard best practices for maintaining a healthy governance posture:

Audit First: Never start by applying a Deny policy to a production environment. Always start with Audit to see how many resources would be impacted. Once you have cleared the backlog of non-compliant resources, then switch to Deny.
Use Policy Sets (Initiatives): Instead of managing individual policies, group them into initiatives. This makes reporting and auditing much cleaner. For example, create an initiative called "Production Security Baseline" that includes all your security-related policies.
Leverage Policy Exclusions: Sometimes, a specific resource needs to be an exception. Use the "Exclusions" feature in the assignment rather than disabling the policy entirely. This keeps your documentation accurate regarding why an exception exists.
Monitor Compliance Trends: The Azure Policy dashboard provides a compliance view. Use this to identify which departments or subscriptions have the highest rates of non-compliance and focus your training or remediation efforts there.
Version Control for Custom Policies: If you create custom policy definitions, store them in a Git repository. Treat your policies as code (Policy-as-Code). This allows you to track changes, review updates, and deploy policies consistently across environments using CI/CD pipelines.

Callout: Policy-as-Code (PaC) Policy-as-Code is the practice of managing policy definitions and assignments using a version control system like GitHub or Azure DevOps. By defining your governance rules in JSON and deploying them via pipelines, you ensure that your governance setup is repeatable, documented, and auditable, just like your application code.

Common Pitfalls and How to Avoid Them

Even experienced administrators run into issues with policy management. Below are the most common mistakes and how to steer clear of them.

1. Over-Applying Policies

One of the most common errors is applying policies that are too restrictive, which can break automation scripts or CI/CD pipelines.

The Fix: Always test your policies in a sandbox or development subscription before applying them to production. Ensure that your automation service principals have the necessary permissions and are not being blocked by your policies.

2. Ignoring the 'Audit' State

Many teams assume that because a policy is assigned, the environment is compliant. However, if the policy effect is Audit, the resource is still created, even if it is non-compliant.

The Fix: Set up Azure Monitor alerts on the "Policy Compliance" status. If the number of non-compliant resources increases, you should receive a notification so you can investigate immediately.

3. Creating Duplicate Policies

It is easy to create a custom policy that does exactly what a built-in policy already does. This leads to clutter and confusion.

The Fix: Always search the library of built-in policies before creating your own. Microsoft updates these built-in policies regularly to reflect new Azure features and security best practices.

4. Not Using Parameters

Hard-coding values into policies makes them brittle and difficult to manage as your organization grows.

The Fix: Whenever possible, use parameters for values that might change, such as region names, allowed SKU sizes, or contact email addresses for tags. This allows you to reuse the same definition across different business units.

Troubleshooting Policy Assignments

When a resource fails to deploy, or a resource is showing as non-compliant, you need to be able to troubleshoot the issue efficiently.

Check the Deployment Error: If a deployment is blocked, the error message in the Azure Portal or CLI will explicitly state that it was blocked by a specific policy. It will include the name of the policy and the assignment ID.
View Resource Compliance: Navigate to the specific resource in the Azure Portal and click on the "Policy" blade. This will show you exactly which policies are currently being evaluated for that resource and whether it is compliant or not.
Review the Activity Log: If you are unsure why a policy was triggered, check the Activity Log for the resource. Look for the "Delete" or "Write" operation and inspect the JSON output to see the details of the policy rejection.
Wait for Evaluation Cycles: Remember that policy compliance is not always real-time for existing resources. It can take up to 24 hours for a policy to re-evaluate a resource after a change is made. If you need an immediate check, you can trigger a scan via the Azure CLI using az policy state trigger-scan.

Summary Checklist: Policy Assignment Workflow

To wrap up this lesson, here is a summary of the workflow you should follow when implementing a new governance requirement:

Identify the Requirement: Determine exactly what business rule needs to be enforced (e.g., "No public IP addresses on SQL databases").
Research Built-in Policies: Search the Azure Policy library for an existing definition that matches the requirement.
Create or Customize: If no built-in policy exists, create a custom definition or modify an existing one using parameters.
Test in Sandbox: Assign the policy to a non-production scope using the Audit effect.
Analyze Results: Review the compliance report to see if any existing resources would be affected by a Deny effect.
Promote to Production: Once testing is successful, assign the policy to the production scope.
Monitor and Remediate: Use the compliance dashboard to track status and trigger remediation tasks if needed.

Key Takeaways

As you move forward with managing Azure governance, keep these core principles in mind:

Governance is Iterative: You will not get your policy configuration perfect on the first day. Start small, audit your environment, and slowly tighten your controls as you gain confidence.
Hierarchy is Everything: Always assign policies at the highest level of your hierarchy that makes sense. Management Groups are your best friend for maintaining broad, consistent governance.
Audit Before You Deny: Never surprise your users or your developers. Always use the Audit effect first to understand the impact of a policy before moving to a Deny effect that could disrupt business operations.
Use Initiatives for Standards: Group related policies into initiatives. This makes it much easier to align your Azure environment with industry compliance standards like CIS, ISO, or NIST.
Leverage Automation: Use Policy-as-Code to store your assignments in version control. This ensures that your governance rules are consistent and can be reproduced across different environments or subscriptions.
Managed Identities are Essential: For policies that perform automated fixes (like DeployIfNotExists), ensure that your managed identities have the minimum required permissions to perform the task—no more, no less.
Documentation is Key: Keep a log of why certain policies are in place and why certain exclusions were made. This is invaluable when you are audited or when new team members need to understand the environment's configuration.

By mastering the assignment of policies and initiatives, you transform from an administrator who reacts to problems into an architect who builds a secure, compliant, and cost-efficient cloud environment from the ground up. This proactive approach is the hallmark of a mature cloud governance strategy.

Assigning Policies and Initiatives