SkarpChapter 14 of 20
Governance Foundations: Azure Policy, Resource Locks, and Tags
See how Azure turns organizational rules into enforceable, automated controls using policies, locks, and tags to keep environments compliant and consistent.
Why Governance Matters in Azure
Governance in Context
Governance turns your organization’s rules into repeatable technical controls so every team and subscription follows the same playbook in Azure.
Three Core Tools
Azure uses three lightweight but powerful governance tools: Azure Policy to enforce rules, resource locks to prevent accidental changes, and tags to categorize resources.
Exam Relevance
For AZ-900’s Azure Management and Governance domain, you must know what Azure Policy, locks, and tags do and when to use each one at a conceptual level.
Real-World Rules
Typical rules: keep resources in certain regions, protect production assets from deletion, and require tags like CostCenter and Environment for every resource.
Azure Policy: Canonical Definition and Big Picture
Canonical Definition
Azure Policy is a service in Azure that you use to create, assign, and manage policies that enforce rules and effects over your resources, so those resources stay compliant with your corporate standards and service level agreements.
What Azure Policy Does
Azure Policy lets you define rules about what resources can exist and how they must be configured, then continuously evaluates resources for compliance.
Azure Policy vs RBAC
RBAC controls who can do what. Azure Policy controls what is allowed to exist and how it must be configured, regardless of who creates the resource.
Typical Policy Uses
Common policies: restrict regions, require encryption, force specific SKUs, or require tags such as CostCenter and Environment on all resources.
Policy Definitions, Assignments, and Scopes
Policy Definitions
A policy definition describes the rule and effect, such as denying resources outside allowed regions. Azure includes many built-in definitions you can reuse.
Policy Assignments and Scope
A policy only takes effect when assigned to a scope, such as a management group, subscription, resource group, or individual resource.
Using Parameters
Policy parameters let you reuse one definition with different settings, like changing the list of allowed locations per assignment.
Hierarchy Awareness
Policies assigned at higher levels, like management groups, flow down to child subscriptions and resource groups unless explicitly excluded.
Compliance States and Policy Effects
Compliance View
Azure Policy evaluates resources and shows which are compliant or non-compliant with each assignment, plus an overall compliance percentage.
Deny vs Audit
Deny blocks non-compliant changes from being created or updated. Audit allows them but flags them for reporting and later remediation.
Other Effects
AuditIfNotExists, DeployIfNotExists, and Modify help you detect missing configurations, auto-deploy needed resources, or adjust settings on the fly.
Continuous Evaluation
Azure Policy runs continuously, so you can detect and correct drift when existing resources become non-compliant after policies change.
Mapping Real Governance Rules to Azure Policy
Scenario Overview
Contoso University requires EU-only regions, encrypted storage accounts, and mandatory tags like CostCenter, Environment, and Owner on all resources.
Restricting Regions
Use the built-in Allowed locations policy, assign it at subscription or management group scope, and deny resources created outside approved regions.
Enforcing Encryption
Assign a storage encryption policy to resource groups holding storage accounts, using Audit or Deny to enforce encryption compliance.
Requiring Tags
Use a Require a tag policy for CostCenter, Environment, and Owner, with Deny or Modify to ensure every new resource carries the right tags.
Resource Locks: Protecting Critical Assets
What Resource Locks Do
Resource locks protect important resources from accidental changes or deletions, acting as a safety net on top of RBAC and policy.
Delete vs Read-only
Delete locks allow read and update but block delete operations. Read-only locks allow only read and block both updates and deletes.
Where to Apply Locks
You can apply locks at the subscription, resource group, or individual resource level, and they inherit downwards from where they are set.
Locks vs RBAC
RBAC decides who can attempt actions; locks block certain actions even for authorized users, preventing accidental but not malicious changes.
When to Use Locks vs Policy vs RBAC
Protecting Production
To prevent accidental deletion of a production database, apply a Delete lock. It blocks deletes even for users who normally have permission.
Controlling Who Changes What
To ensure only the security team edits firewall rules, use RBAC roles for that resource, not locks or policy.
Enforcing Standards
To require tags like CostCenter or restrict regions, use Azure Policy, which enforces configuration standards across many resources.
Exam Pattern
Accidental deletion or change → locks. Who can do the action → RBAC. Configuration or compliance rules → Azure Policy.
Tags: Categorizing Resources for Governance and Cost
What Tags Are
Tags are key-value pairs attached to resources, like Environment=Production or CostCenter=FIN-001, used for organization and reporting.
Tags for Cost Management
Azure Cost Management can group and filter spending by tags, helping you see costs by project, team, or environment.
Tags for Governance
Tags such as Environment or Criticality help drive policies, backups, and monitoring priorities, and can be enforced with Azure Policy.
Exam Tip on Tags
If a question is about grouping resources for billing or reports, tags are usually the right answer, not extra subscriptions or regions.
Thought Exercise: Classify the Governance Tool
Work through these short scenarios and decide whether Azure Policy, resource locks, tags, or RBAC is the best primary tool. Then check the suggested answers.
- Scenario A
- The IT department wants to ensure no one can accidentally delete the production resource group that holds customer-facing web apps.
- Your choice: Policy, Lock, Tag, or RBAC?
- Scenario B
- Finance wants to see monthly Azure spend per department without changing the existing subscription structure.
- Your choice: Policy, Lock, Tag, or RBAC?
- Scenario C
- The cloud team wants to block creation of public IP addresses except for a small set of approved admins.
- Your choice: Policy, Lock, Tag, or RBAC?
- Scenario D
- The security team must ensure that all storage accounts have secure transfer required (HTTPS only).
- Your choice: Policy, Lock, Tag, or RBAC?
---
Suggested answers (compare after you think):
- Scenario A → Resource lock (Delete lock on the production resource group).
- Scenario B → Tags (for example, `Department = Finance | HR | IT` and then use cost reports by tag).
- Scenario C → Azure Policy + RBAC:
- Policy to deny public IP creation for everyone.
- RBAC exemption pattern or dedicated subscription for admins needing exceptions (in practice, advanced, but conceptually: policy for configuration, RBAC for who can change it).
- Scenario D → Azure Policy to enforce secure transfer and report compliance.
As you do more practice questions in Skarp, watch for these patterns. They appear frequently in the Azure Management and Governance (34%) part of AZ-900.
Quick Check: Azure Policy, Locks, and Tags
Test your understanding with a few AZ-900 style questions.
You are designing governance for a new Azure subscription. The organization wants to: 1. Prevent resources from being created outside the "westeurope" and "northeurope" regions. 2. Ensure that accidental deletion of the production resource group is blocked. 3. Track costs by project across multiple resource groups. Which combination of features best addresses these three requirements?
- 1: Azure Policy, 2: Resource lock, 3: Tags
- 1: Tags, 2: Azure Policy, 3: Resource lock
- 1: RBAC, 2: Resource lock, 3: Azure Policy
- 1: Azure Policy, 2: RBAC, 3: Tags
Show Answer
Answer: A) 1: Azure Policy, 2: Resource lock, 3: Tags
Requirement 1 (restrict regions) is a configuration rule, so use Azure Policy (for example, Allowed locations). Requirement 2 (prevent accidental deletion) is exactly what a Delete resource lock is for. Requirement 3 (track costs by project) is handled by tagging resources (for example, Project=XYZ) and using cost reports by tag. So the correct mapping is 1: Azure Policy, 2: Resource lock, 3: Tags.
Quick Check: Exam-Style Concept Questions
Another short quiz to reinforce key distinctions.
Which statement best describes the difference between Azure Policy and role-based access control (RBAC)?
- Azure Policy controls who can access resources, while RBAC enforces configuration standards.
- Azure Policy enforces rules and effects over resources to keep them compliant, while RBAC controls who can perform actions on those resources.
- Azure Policy and RBAC are the same service; the names are interchangeable.
- RBAC is only used for cost management, while Azure Policy is only used for security.
Show Answer
Answer: B) Azure Policy enforces rules and effects over resources to keep them compliant, while RBAC controls who can perform actions on those resources.
Azure Policy is a service in Azure that you use to create, assign, and manage policies that enforce rules and effects over your resources, so those resources stay compliant with your corporate standards and service level agreements. RBAC is an authorization system that controls who can perform which actions on Azure resources. They solve different problems: configuration/compliance vs permissions.
Flashcards: Key Governance Terms
Use these flashcards to reinforce the most testable definitions and distinctions.
- Azure Policy (canonical definition)
- Azure Policy is a service in Azure that you use to create, assign, and manage policies that enforce rules and effects over your resources, so those resources stay compliant with your corporate standards and service level agreements.
- Resource lock: Delete (CanNotDelete)
- A Delete lock allows authorized users to read and modify a resource but prevents them from deleting it until the lock is removed, protecting against accidental deletion.
- Resource lock: Read-only (ReadOnly)
- A Read-only lock allows only read operations on a resource and blocks both updates and deletions, effectively freezing configuration unless the lock is removed.
- Tags (purpose in governance)
- Tags are key-value pairs attached to resources that support governance and cost management by categorizing resources for organization, reporting, and automation (for example, Environment=Prod, CostCenter=HR).
- Azure Policy vs RBAC (core difference)
- Azure Policy enforces configuration rules and compliance over resources; RBAC controls who can perform which actions on those resources.
- Best tool: Prevent accidental deletion of a production resource group
- Apply a Delete resource lock to the production resource group.
- Best tool: Require all resources to include a CostCenter tag
- Use Azure Policy with a tag requirement policy (for example, Require a tag and its value on resources).
- Best tool: Group costs by project across many resource groups
- Use tags such as Project=ProjectName and then analyze costs by tag in Azure Cost Management.
Putting It All Together and Next Steps
Azure Policy Recap
Azure Policy enforces rules and effects over resources to keep them compliant with corporate standards and SLAs, using definitions, assignments, and effects.
Locks and Tags Recap
Locks prevent accidental changes or deletions; tags categorize resources for governance, cost management, and automation.
Scenario Keywords
Accidental deletion → locks; configuration/compliance → Azure Policy; billing and grouping → tags; who can act → RBAC.
Your Next Moves
Reinforce this module with Skarp’s diagnostic, mock exams, and spaced review so these concepts feel automatic by exam time.
Key Terms
- Tags
- Key-value metadata attached to Azure resources, resource groups, or subscriptions, used to categorize resources for governance, reporting, and cost management.
- Azure Policy
- Azure Policy is a service in Azure that you use to create, assign, and manage policies that enforce rules and effects over your resources, so those resources stay compliant with your corporate standards and service level agreements.
- Resource lock
- A governance feature that prevents accidental deletion or modification of Azure resources. Delete locks block deletion; Read-only locks block both updates and deletion.
- Compliance state
- The status reported by Azure Policy indicating whether a resource complies with an assigned policy (compliant or non-compliant).
- Policy assignment
- The application of a policy definition to a specific scope, such as a management group, subscription, resource group, or resource.
- Policy definition
- A rule in Azure Policy that describes what to evaluate and what effect to apply, such as denying resources in unapproved regions.
- Scope (governance)
- The level in the Azure hierarchy where a governance control like a policy or lock is applied, for example management group, subscription, resource group, or resource.
- Role-based access control (RBAC)
- Role-based access control (RBAC) is an authorization system built on Azure Resource Manager that provides fine-grained access management of Azure resources based on roles assigned to users, groups, and service principals.