Defender for Cloud left Contoso Airlines with a list of recommendations and an obvious crack: it detects after the fact. Somebody creates a huge virtual machine in the wrong region with no tags, the resource exists, it bills and it sits there exposed; days later a recommendation flags it and somebody has to go and fix it. Worse still, the person who did it was perfectly entitled to: they were Contributor on the subscription, which is exactly the permission they need in order to work. RBAC cannot solve this, because RBAC only answers who. What is missing is a system that answers what, and that is Azure Policy: the rules of the game, applied at the moment the resource is created, regardless of who creates it. This lesson closes the security module, and the platform goes from being secured to being governed.

Important warning: governance and compliance policies have immediate, wide-reaching effects — a badly scoped Deny policy can halt legitimate deployments in production, and a badly written Modify can alter resources en masse. On top of that, real regulatory compliance (PCI DSS, GDPR, ENS) goes far beyond what any tool evaluates. Before applying any governance initiative in production, it must be reviewed by a security professional or by your organization's compliance team.

1. RBAC versus Policy: who can versus what can be done
2. Anatomy of a policy definition
3. The effects and when to use each one
4. Assignment, scope, exclusions and resources that already exist
5. Initiatives and the built-in compliance ones
6. Contoso's set of policies
7. Compliance evaluation and remediation tasks
8. Management groups: the root of governance
9. From Blueprints to template specs and landing zones
10. The cost of governance versus the cost of not having it
11. Policy and infrastructure as code
12. Common Mistakes and Tips
13. Exercises
14. Conclusion

Here is the example that explains everything. Diego Salas is Contributor on rg-contoso-reservas-dev, a perfectly legitimate permission Marta granted him in 04-02. With it he creates a Standard_E64s_v5 virtual machine in East US for a performance test, with no tags. Nothing he has done violates RBAC: he had permission to create resources.

The result, though, is a problem on four fronts: cost (some €3,500 a month nobody budgeted for), billing (with no centro-coste, it cannot be charged to anyone), compliance (data that could end up outside the EU) and operations (a resource in a region the team does not monitor).

They complement each other and do not replace each other: RBAC decides whether you can press the button; Policy decides what is acceptable to come out of pressing it. Note the asymmetry in the default models: with RBAC you can do nothing until it is granted; with Policy you can do everything until somebody restricts it.

Element by element:

• mode: Indexed evaluates only the resource types that support tags and location — it is the right one for regions and tags; All also includes resource groups and subscriptions. Using All where Indexed belongs produces false non-compliance on resources that have no real location.
• parameters: they make the policy reusable. The list of regions is decided when you assign it, not when you define it, so the same policy serves production and a future environment in another geography.
• policyRule.if: the conditions, combinable with allOf (AND) and anyOf (OR), and nestable. The usual operators are equals, notEquals, in, notIn, like, exists and contains.
• The example's two exclusions are not decoration: many resources have the global location (Front Door, Traffic Manager, DNS) and blocking them would break the platform; and resource groups are excluded because their location only says where their metadata is stored.
• then.effect: what to do when the condition is met.

Two distinctions worth committing to memory. Append versus Modify: Append only acts on creation and does not touch what already exists; Modify can fix already created resources through remediation tasks, which is why it is the one used for tags. Deny versus DeployIfNotExists: the first rejects and forces whoever is deploying to fix it; the second accepts and fixes it itself. Use Deny for what must never exist and DeployIfNotExists for what must always accompany the resource.

The Modify and DeployIfNotExists effects need a managed identity on the assignment, because Azure Policy has to act on your behalf, and that identity needs the corresponding roles. It is the number one cause of remediation tasks that fail.

A definition does nothing until it is assigned to a scope: management group, subscription or resource group. The assignment is inherited downwards, just like RBAC, and it supports exclusions of specific sub-scopes.

The point that causes the most confusion: what happens to resources that already exist.

• A Deny effect does not delete or block what is already created. It only acts on future creations and modifications. A pre-existing resource that breaches it shows up as non-compliant, and the block will fire the next time somebody tries to modify it (a side effect that catches people out: a routine update starts failing).
• The Audit and AuditIfNotExists effects evaluate everything that exists and report on it.
• Modify and DeployIfNotExists can fix what exists, but only if an explicit remediation task is launched (section 7).

Hence the correct rollout sequence, analogous to the WAF's in 04-04: assign in Audit, measure the real non-compliance, fix what exists, announce the date and only then change the effect to Deny.

An initiative (or policy set) groups policies that are assigned and measured together. Advantages: a single assignment, shared parameters and one compliance view. Contoso creates the initiative "Base de gobernanza de Contoso" with the six policies from the next section.

Azure ships built-in initiatives for complete standards: Microsoft Cloud Security Benchmark (assigned by default), PCI DSS 4.0, ISO 27001, CIS Azure Foundations, NIST SP 800-53 and Spain's ENS. They are the counterpart of the previous lesson's Defender compliance dashboard: there you saw the result, here is the mechanism that evaluates it. Nearly all their policies are of the Audit type, precisely because a standard exists to measure, not to block deployments.

Three comments on this block. The mandatory tags policy is assigned four times because the built-in one accepts a single tag per assignment; the order matters: the inheritance one (Modify) has to be evaluated before the requirement one, or deployments without centro-coste would be rejected instead of completed automatically. The inheritance assignment creates a managed identity with --mi-system-assigned and gives it the Contributor role at the scope: without that, the policy is assigned correctly and remediation always fails.

Two more policies are missing. The one for VM sizes in development is assigned only to the development subscription, because production's restrictions are different:

And the one for automatic diagnostics, the canonical DeployIfNotExists case, which solves Defender's recommendation number 7 (04-05) at the root: instead of configuring fourteen resources by hand, the policy configures them and configures every future one as well.

Azure Policy evaluates at three moments, and it is worth knowing them because they explain almost every "I assigned the policy and nothing happens" question:

• When a resource is created or modified: immediately. That is when Deny, Append and Modify act.
• When a policy is assigned or changed: an evaluation is triggered within about 30 minutes.
• The periodic cycle: everything is re-evaluated every 24 hours.

Remediation is what fixes what already exists. It only applies to Modify and DeployIfNotExists, and it is not automatic: you have to create a task that walks the non-compliant resources and applies the change to them using the assignment's managed identity.

If failedDeployments is greater than zero, the cause is nearly always the same: the assignment's managed identity does not have sufficient permissions in some sub-scope. You check it with az role assignment list --assignee <the assignment's principalId>.

Assigning policies subscription by subscription does not scale: every new subscription is born ungoverned and somebody has to remember. Management groups are containers above subscriptions that let you assign policies and RBAC once, inherited downwards.

Contoso's allocation, and the logic behind it:

• In mg-contoso: what is non-negotiable for everyone — allowed regions, mandatory tags, no public access on storage, HTTPS and automatic diagnostics. Nobody, in any present or future subscription, can get around it.
• In mg-contoso-plataforma: rules specific to the shared infrastructure, such as requiring every subnet to have an NSG attached.
• In mg-contoso-cargas: the applications' rules, and beneath it the VM size restriction that applies only to the development subscription.

Two practical warnings. The tenant root group always exists and assigning there affects absolutely everything, including subscriptions that do not exist yet; treat it with extreme care, and it requires the Management Group Administrator role. And exclusions should be few and documented: a hierarchy full of exceptions governs nothing.

Azure Blueprints was the attempt to package ARM templates, policy assignments and role assignments into a single artifact. It is deprecated and must not be used in new designs. Its replacement is two separate and better pieces:

• Template specs: ARM or Bicep templates, versioned and stored as an Azure resource, shareable with RBAC.
• Azure landing zones: the Cloud Adoption Framework's reference implementation, which deploys the management group hierarchy, the policies, the network topology and identity as one coherent whole. It is where what you have built by hand today evolves to, and it is covered in lesson 09-04.

Azure Policy is free: you pay nothing for definitions, assignments, evaluation or remediation. What it costs is the time to design it and the initial friction when a deployment is rejected.

Against that, the cost of not having it, with the figures from the example in section 1: the Standard_E64s_v5 VM in East US costs around €3,500 a month and, with no centro-coste, it cannot be charged to anyone, so it lands in the general allocation and nobody claims it. Add the real cost of an incident: a storage account with public access is a personal data breach, and GDPR fines are measured as a percentage of turnover. The whole governance section costs zero euros a month; the first badly created resource it prevents more than pays for the time invested. It is, by some distance, the best cost-benefit ratio in the module, and it is why Nuria Peña will be demanding it from module 8 onwards: with no centro-coste on every resource, no cost analysis is possible.

It might look as though, if the whole infrastructure is defined in Bicep with the right tags and regions, Policy is redundant. It is not, and the reason is the one that has come up all module long: the template protects what the pipeline deploys, the policy protects everything else. Somebody will create a resource from the portal to "try something out", a third-party tool will provision something on its own, or a poorly reviewed pipeline will deploy to the wrong region. Policy is the safety net that does not depend on anybody's discipline.

The correct way to combine them is in layers: the template defines the intent and makes the right thing easy; the policy prevents the wrong thing wherever it comes from; and the policy definitions and assignments themselves are managed as code, versioned in the repository and deployed by the pipeline, not clicked into the portal. How that is done with Bicep and Azure Pipelines is the content of lessons 05-03 and 05-06.

• Assigning Deny straight into production. Start in Audit, measure the non-compliance, fix, announce, and only then block.
• Forgetting the managed identity on Modify and DeployIfNotExists. The assignment is created with no error and every remediation fails.
• Expecting Deny to clean up what exists. It only acts on creations and modifications; existing resources are fixed with remediation tasks.
• Being impatient. Evaluation takes about 30 minutes after assigning, and the full cycle 24 hours.
• Requiring tags without the inheritance policy. Every deployment starts failing and the team ends up asking for the policy to be removed.
• Blocking the global location. Front Door, Traffic Manager and DNS can no longer be created. Always exclude global and resource groups.
• Using Blueprints in a new design. It is deprecated; use template specs and landing zones.
• Filling the hierarchy with exclusions. Every exception is a crack; document and review the few that are unavoidable.
• Tip: test every new policy in rg-contoso-reservas-dev before promoting it to the management group. The blast radius of a badly written policy at the root is the entire company.
• Tip: group your own policies into an initiative from the start. Ten loose assignments become unmanageable; an initiative is assigned, parameterized and measured in one go.

"Contoso Miles" (centro-coste=CC-2077) will have its own subscription. Requirements: West Europe only; the four mandatory tags with centro-coste inherited from the resource group; no database reachable from the internet; diagnostics sent to log-contoso-pro; and VMs limited to Standard_D4s_v5 at most.

1. For each requirement, state the appropriate effect and where in the hierarchy you would assign it.
2. Which ones need a managed identity, and what role would you give it?
3. Describe the rollout order so as not to block the team on day one.

After assigning the mandatory tags policy with the Deny effect at mg-contoso, Contoso's nightly pipeline starts failing with RequestDisallowedByPolicy and, on top of that, 240 pre-existing resources show up as non-compliant.

1. Why do the new deployments fail, and what is missing from the design?
2. What has to be done about the 240 existing resources, with the commands?
3. Propose the correct assignment order so that this would not have happened.

State the effect (Audit, Deny, Modify, DeployIfNotExists, DenyAction) and justify it:

1. Every new storage account must require TLS 1.2 as a minimum.
2. Every resource must have the propietario tag; if it is missing, it has to be set from the resource group's value.
3. Every SQL database must have auditing enabled, sending it to Log Analytics.
4. You want to know how many VMs have no backup, without changing anything yet.
5. Nobody must be able to delete kv-contoso-pro, not even an Owner.

Solution 1:

1. Regions: Deny, at the management group containing the Miles subscription (or at mg-contoso if the rest of the company shares the restriction; since here it is West Europe only, it is assigned at subscription level with its own parameter). Mandatory tags: Deny at the subscription. centro-coste inheritance: Modify at the subscription. Databases with no public access: Deny at the subscription. Diagnostics: DeployIfNotExists, better at mg-contoso because it applies company-wide. VM sizes: Deny at the subscription.
2. The Modify one (tag inheritance) and the DeployIfNotExists one (diagnostics). Role: Contributor at the assignment's scope, or better a narrower one — Tag Contributor for the first and Monitoring Contributor plus Log Analytics Contributor for the second — applying 04-02's least privilege.
3. First the Audit ones and the Modify/DeployIfNotExists ones with their remediation tasks, so that the platform brings itself up to date. Then measure compliance for a few days. Then tell the team the date it comes into force. And only then change the regions, tags, public access and sizes effects to Deny.

Solution 2:

1. Because the pipeline creates resources without the centro-coste tag, and with Deny the whole request is rejected. What is missing is the inheritance policy with the Modify effect, which should fill in the tag from the resource group before the requirement policy evaluates; also missing is having gone through an Audit phase, which would have revealed the problem without cutting anything off.
2. The Deny policies do not touch them: they carry on existing, marked non-compliant, but they will fail the next time somebody modifies them. They are fixed by assigning the inheritance policy with a managed identity and launching az policy remediation create -n corrige-etiquetas --policy-assignment hereda-centro-coste --resource-discovery-mode ExistingNonCompliant --scope /subscriptions/$SUB, and then checking deploymentSummary.failedDeployments. Resources whose resource group does not have the tag either will have to be tagged by hand, or the resource groups tagged first.
3. (a) Assign the inheritance one (Modify) and run its remediation. (b) Assign the tags one in Audit and measure for one or two weeks. (c) Manually fix whatever is left and give the team a date. (d) Change the effect to Deny. It is the same detect-analyze-fix-enforce sequence as the WAF's in 04-04, and for the same reason.

Solution 3:

1. Deny: it is a property known at creation time, there is no reason to accept an insecure account and the requirement is non-negotiable under PCI DSS. It is preceded by an Audit phase if accounts already exist.
2. Modify: it adds the missing tag and, unlike Append, it can fix existing resources with a remediation task. It requires a managed identity.
3. DeployIfNotExists: auditing is a related resource (a diagnostic setting) that has to be created, not a property of the database. It requires a managed identity with permissions on the workspace.
4. AuditIfNotExists: you only want to measure the absence of a related resource (the backup item) without deploying anything or blocking. It is the natural preliminary phase before deciding whether to move to DeployIfNotExists.
5. DenyAction on the delete operation, complemented by a CanNotDelete resource lock (01-05) and by the vault's own purge protection (04-03). Three layers for the same goal, because losing a Key Vault with encryption keys is irreversible.

This lesson closes module 4, and it is worth looking at what has changed. You can tell what RBAC cannot solve: RBAC answers who can do something and Azure Policy answers what can be done, with opposite default models — RBAC denies until you grant; Policy allows until you restrict. You have dissected a policy definition with its mode, its parameters, its conditions and its effects, and you know when to use each one: Audit to discover, Deny for the non-negotiable, Append and Modify to fill in values — with the difference that only Modify fixes what exists — DeployIfNotExists and AuditIfNotExists for related resources, and Disabled to pause. You understand that a Deny does not clean up what is already created, that evaluation takes about 30 minutes after assigning and 24 hours for its full cycle, and that remediation tasks are what bring the platform up to date, as long as the assignment has its managed identity with the right permissions.

You have implemented Contoso's set of policies: regions limited to West Europe and North Europe, the four mandatory tags with centro-coste inherited from the resource group, a ban on public access in storage, HTTPS and minimum TLS, bounded VM sizes in development and automatic deployment of diagnostics to log-contoso-pro — which solves at the root, and for the future too, one of the recommendations Defender produced in 04-05. All of it hanging off a hierarchy of management groups (mg-contoso → mg-contoso-plataforma and mg-contoso-cargas) that means no future subscription is born ungoverned. You know that Blueprints is deprecated and that its place is taken by template specs and the Cloud Adoption Framework's landing zones (09-04), that Policy is free while a single badly created resource costs thousands of euros, and that infrastructure as code and policy are complementary layers: the template makes the right thing easy, the policy prevents the wrong thing wherever it comes from.

Recapping the whole module: Contoso Airlines' platform came in with passwords typed by hand and leaves governed. Identities live in Microsoft Entra ID with groups, MFA, Conditional Access, PIM and an emergency account excluded from everything. Permissions are minimal and assigned to groups, with data roles kept separate from the management plane and a custom role for operations. Not a single secret is left in the code or in the deployment: managed identities eliminated the ones that could disappear and kv-contoso-pro holds the ones that could not, with @Microsoft.KeyVault(...) references the application resolves on its own. The perimeter is protected with the WAF on fd-contoso-global, its OWASP and bot rules, rate limiting and an attack response playbook, with the DDoS cost decisions reasoned rather than improvised. Posture watches itself with Defender for Cloud, its score, its prioritized recommendations, its alerts and its PCI DSS dashboard. And the rules of the game no longer depend on somebody remembering: they are written as policy and applied at the moment each resource is created.

There is, however, something this module has laid bare without saying it. Everything you have built across four modules has been deployed by hand, command by command, from the CLI. It works, but it does not scale, it is not reproducible, there is no way of knowing who changed what or of rolling back if something breaks, and there would be no way of recreating this platform in another region after a disaster. The same discipline you have applied to governance today has to be applied to delivery. In module 5, Azure DevOps, you will build the complete cycle: Azure Repos to version the code and the templates too, Azure Pipelines to build and test on every change, continuous deployment with environments and approvals so you can reach production without fear, Azure Artifacts for shared packages and, closing the circle, infrastructure as code with Bicep, where this whole platform — networks, applications, databases, policies included — stops being a collection of commands run once and becomes reviewable, versioned, repeatable code. See you there.