Lesson 14 · Domain 3: Azure Management & Governance (30–35% of exam)

Governance & Compliance

RBAC (Lesson 9) already answers "who can do what." This lesson answers a different question: no matter who's allowed to act, what are they allowed to create, and what's protected from being touched at all — even by someone who technically has permission.

Primary source: Microsoft Learn — Describe features and tools in Azure for governance and compliance, part of Part 3: Describe Azure management and governance.

Quick calibration

An engineer has the Owner role on a resource group — the highest permission there is. They try to delete a production database inside it and get blocked anyway. RBAC granted them the permission. What stopped them?

Azure Policy

Azure Policy enforces rules about resource properties — not who can act, but what's allowed to exist. A policy might deny creating a storage account without encryption, audit any VM deployed outside an approved region, or automatically append a required tag. Policies get grouped into initiatives when several need to be tracked together toward one compliance goal (e.g. a regulatory standard). Policy evaluates and can block a request even from a user who has full RBAC permission to make it — RBAC decided they're allowed to try, Policy decides whether the result is compliant.

⚠ Confusable pair: Azure Policy vs. Azure RBAC

RBAC — controls who can perform which actions (read/write/delete), scoped to a role assignment. Azure Policy — controls what a resource's properties are allowed to be, regardless of who's creating it. A user can have full write permission via RBAC and still have their request denied by Policy for not meeting a rule (e.g. wrong region, missing tag, no encryption).

Anchor: RBAC gates the actor. Policy gates the outcome.

Resource locks

Resource locks prevent accidental change or deletion, and — like Policy — apply regardless of RBAC role, even to an Owner. Two levels:

LockBlocks
CanNotDeleteDeletion only — the resource can still be read and modified
ReadOnlyBoth modification and deletion — the resource is frozen until the lock is removed

Locks inherit downward (subscription → resource group → resource), and the more restrictive lock always wins if scopes disagree.

Microsoft Purview

Microsoft Purview is a unified data governance solution spanning on-premises, multicloud, and SaaS data estates — not just Azure. It discovers, catalogs, and classifies data wherever it lives, then layers on risk and compliance management (sensitive data protection, retention, insider risk) so an organization can govern data it doesn't fully control the infrastructure for.

Calibration answer: a resource lock (most likely CanNotDelete, or ReadOnly if they also couldn't edit it). RBAC and locks are independent — a lock overrides even the highest RBAC role.

Practice

If Policy vs. RBAC still feels interchangeable, that's worth a flag — it's the pair this lesson is built around, and the exam likes to test it with exactly the "Owner gets blocked anyway" scenario from the calibration question.
← Lesson 13: Cost Management Lesson 15: Managing & Deploying Resources →