CH02-01: Governance Mental Model

Goal

Chapter 1 explained the Azure hierarchy: tenant, management groups, subscriptions, resource groups, and resources. That hierarchy is useful because it gives Azure decisions a place to live.

This section explains what governance means in that hierarchy.

Governance is not a separate cloud activity that happens after architecture. It is part of the architecture. It shapes who can change the environment, which rules apply, how cost is owned, how risky changes are prevented, and how teams prove that the environment is controlled.

The goal is not to memorize every governance feature. The goal is to build a practical mental model for how Azure keeps cloud growth safe and accountable.

The Short Version

Azure governance is how an organization gives teams freedom to build inside clear boundaries.

It helps answer five recurring questions:

Who can do what?
Which rules must resources follow?
Who owns cost and operations?
Which resources need extra protection?
How do we prove the environment is controlled?

Those questions matter because cloud platforms make it easy to create resources quickly. That speed is useful, but it also creates risk. Without governance, teams may use different regions, expose services publicly by accident, create resources without owners, give too much access, miss required monitoring, or leave expensive test environments running long after they are needed.

Governance turns cloud freedom into cloud responsibility.

A Practical Mental Model

Think of Azure governance as five responsibility areas:

flowchart TB
    A["Governance<br/><small>How do many teams use Azure safely?</small>"]
    B["Access<br/><small>Who can do what?</small>"]
    C["Policy<br/><small>What is allowed or required?</small>"]
    D["Ownership & Cost<br/><small>Who owns and pays?</small>"]
    E["Protection<br/><small>What should not change accidentally?</small>"]
    F["Evidence<br/><small>How do we prove control?</small>"]

    A --> B
    A --> C
    A --> D
    A --> E
    A --> F

This is not a deployment order. It is a way to keep the main governance responsibilities visible while designing Azure environments.

You will see several Azure names in this chapter: landing zones, Azure RBAC, Azure Policy, tags, budgets, and resource locks. Do not worry about memorizing all of them at once. Each name will be explained as it appears. For now, focus on the responsibility each control serves.

Access

Access governance answers:

Who can read Azure resources?
Who can create or change resources?
Who can delete resources?
Who can assign permissions to other people or automation tools?
How should access differ between production and non-production?

Azure role-based access control, usually called Azure RBAC, is Azure's system for granting management permissions at a scope. A scope can be broad, such as a management group or subscription, or narrow, such as a resource group or a single resource.

At this stage, the important idea is simple: access should match responsibility. A central security team may need read access across many production subscriptions. An application team may need contributor access only to its own non-production resource groups. A deployment pipeline may need permission to deploy one workload, not permission to change the whole subscription.

Good governance avoids both extremes: blocking teams so tightly that they cannot work, and granting broad permissions because it is faster in the moment.

Policy

Policy governance answers:

Which Azure regions may teams use?
Which resource types are allowed?
Which tags are required?
Which configurations are forbidden because they create risk?
Which settings should be audited or automatically applied?

Azure Policy is Azure's service for defining rules about resource configuration. For example, a policy can require a cost center tag, audit resources that do not send diagnostics, or deny storage accounts that allow unsafe public access.

Azure Policy is different from Azure RBAC. RBAC asks, "Is this identity allowed to perform this action?" Policy asks, "Is the resulting resource state allowed by our rules?"

Both are needed. A developer may be allowed to create a storage account, but the organization may still require that the storage account be deployed only in approved regions, tagged correctly, and configured safely.

Ownership and Cost

Cloud cost is not only a finance problem. It is an architecture and operations problem.

Ownership and cost governance answer:

Which team owns this resource?
Which application or product does it support?
Is it production, test, development, or temporary?
Which cost center pays for it?
How will spending changes be noticed early?
Who decides when the resource can be retired?

Azure tags are key-value labels placed on resources, resource groups, or subscriptions. Tags can describe owner, environment, application, cost center, data classification, criticality, or lifecycle. Azure Cost Management is Azure's cost analysis and budgeting capability. You do not need its details yet; the important point is that budgets and cost alerts help teams notice spending changes before a bill becomes a surprise.

Tags do not make a design secure by themselves. They make ownership and reporting visible. That visibility helps governance work in real life.

Protection

Protection governance answers:

Which resources would cause serious impact if deleted by accident?
Which shared platform services should not be changed by workload teams?
Which production resources need an extra safeguard against accidental modification?
Where would a resource lock help, and where would it create friction?

Azure resource locks are protection settings that can prevent accidental deletion or modification at a scope. A delete lock can help protect a production database, a shared network resource, or a central monitoring workspace from accidental removal.

Locks are useful, but they are not a complete safety model. They do not replace least-privilege access, backups, recovery design, deployment review, or monitoring. They are one extra safeguard for important resources.

Evidence

Evidence governance answers:

How do we know policies are being followed?
How do auditors see which controls are in place?
How do security teams find risky configurations?
How do operators know whether production resources are monitored?
How do teams prove who owns a workload and what environment it belongs to?

Evidence comes from several places: policy compliance results, activity logs, monitoring data, cost reports, tags, security posture tools, and deployment records. Azure Monitor is Azure's broad platform for collecting metrics, logs, and alerts. Microsoft Defender for Cloud is an Azure service that helps assess and improve cloud security posture. Details come later; for now, remember that governance is not only about setting rules. It is also about seeing whether the rules are working.

Why Scope Matters

Governance becomes practical when controls are assigned at the right Azure scope.

Scope	Governance Use	Example
Management group	Apply common governance across many subscriptions.	Require approved regions for all production subscriptions.
Subscription	Separate major ownership, billing, environment, quota, and access boundaries.	Give a business unit its own production subscription.
Resource group	Manage related resources with shared ownership, lifecycle, or deployment.	Let an application team deploy one workload component.
Resource	Apply a specific setting to one service instance.	Lock a critical production database from deletion.

The higher the scope, the broader the effect. A policy assigned at a management group can influence many subscriptions. A role assignment at a subscription can grant access across many resource groups. That power is useful, but it must be intentional.

Good governance usually starts with broad standards at higher scopes and then becomes more specific closer to the workload.

Example: A Customer API

Imagine a product team wants to deploy a customer API in Azure.

Without governance, the team might create whatever resources seem necessary: an application hosting service, a database, a storage account, a network, and a few monitoring settings. The application may work, but several questions remain unclear:

Is this workload allowed in the selected region?
Who owns the monthly cost?
Is the database reachable from the public internet?
Who can change production settings?
Are logs and alerts configured?
Which security team can inspect the environment?
How will temporary test resources be cleaned up?

With governance, many of these decisions are prepared before the team deploys. The workload lands in the right subscription. Required tags identify the owner, environment, application, and cost center. Azure RBAC gives the product team enough access to deploy while limiting production changes. Azure Policy enforces approved regions and audits missing monitoring. Resource locks protect critical shared resources. Cost alerts notify the owner when spending crosses agreed thresholds.

The team still designs the API. Governance does not choose every service or write the application. It creates the boundaries that let the team move quickly without leaving ownership, security, cost, and operations to chance.

Common Early Mistakes

Treating governance as paperwork. Governance is part of the architecture because it affects access, deployment, cost, compliance, and operations.
Waiting too long to define guardrails. It is harder to clean up inconsistent subscriptions, tags, policies, and permissions after many teams have already deployed workloads.
Giving broad access because it is convenient. Owner permissions at broad scopes can create serious risk and make auditing harder.
Confusing visibility with control. Seeing resources is useful, but governance also needs rules, ownership, and action.
Using tags only for decoration. Tags should support cost reporting, operations, compliance, lifecycle, and ownership decisions.
Treating governance as only a security topic. Governance also includes cost, ownership, reliability, operations, and evidence.
Making governance too restrictive. If every safe change requires central approval, teams will slow down or find workarounds.

If Someone Asks You

If someone asks, "What does Azure governance mean?" a clear answer is:

Azure governance is how an organization controls cloud usage without removing team autonomy. It defines who can do what, which rules resources must follow, who owns cost and operations, which resources need extra protection, and how the organization proves the environment is controlled. In Azure, governance uses scopes such as management groups, subscriptions, resource groups, and resources, with controls such as Azure RBAC, Azure Policy, tags, budgets, resource locks, and landing zones.

This answer shows that governance is not just a tool name. It is an operating model for safe cloud growth.

What You Should Remember

Azure governance is easier to understand when you connect every control to a responsibility.

The most important idea is this:

Governance is how autonomy gets boundaries.

Azure gives teams many ways to create and operate resources. Governance makes that freedom usable by defining access, rules, ownership, cost visibility, protection, and evidence at the right scopes.

Questions to Check Your Understanding

Why is governance more than security approval?
How does the Azure hierarchy support governance?
What is the difference between access control and policy control?
Why do tags matter for architecture and operations?
How can governance support team autonomy instead of blocking it?