Azure Architecture Guide

CH21-06: Governance, Compliance, and Evidence

Goal

Help readers connect governance, compliance, and evidence concerns to Azure solution options, useful patterns, trade-offs, and decision prompts.

The Short Version

Governance enables safe autonomy by making rules, ownership, cost, protection, and evidence visible.

Good Azure governance should not feel like a pile of approvals added after teams want to deploy. It should create a prepared path where teams know where resources belong, which rules apply, who can do what, how cost is attributed, and how compliance evidence is produced.

Concern

The organization must let teams deliver workloads while maintaining consistent access, policy, compliance, cost ownership, resource organization, and evidence.

Typical Symptoms

  • Teams deploy resources with inconsistent naming, regions, tags, or security settings.

  • Compliance evidence is gathered manually after the fact.

  • Subscription boundaries do not match ownership or environment separation.

  • Costs cannot be attributed to teams or products.

  • Exceptions are informal and hard to review.

Azure Solution Options

  • Management groups, subscriptions, and resource groups for scope and ownership.

  • Azure Policy for allowed, denied, audited, appended, or remediated resource states.

  • Azure RBAC for least-privilege access at scope.

  • Tags, budgets, and management group hierarchy for ownership and cost visibility.

  • Landing zones for reusable governed environments.

  • Microsoft Defender for Cloud or Microsoft Purview where security and data governance evidence is relevant.

Useful Patterns

  • Policy-as-code.

  • Deployment stamps for repeatable governed environments.

  • External configuration store where environment-specific configuration should be separated.

Trade-Offs

  • Strong guardrails improve consistency but can slow teams if exceptions are unclear.

  • Central governance improves evidence but must not remove workload accountability.

  • Too many policies can create noise and deployment friction.

  • Landing zones require upfront design but reduce repeated platform decisions.

Decision Prompt

Which rules should be inherited centrally, which decisions belong to workload teams, and how will exceptions be reviewed?

Common Mistakes

  • Treating governance as a blocker instead of an enabling path.

  • Using RBAC to solve resource-configuration compliance.

  • Using Policy to solve human access design.

  • Creating tags without enforcing or using them.

If Someone Asks You

How do you design governance in Azure?

I design governance with scopes, roles, policies, ownership, cost visibility, and evidence. Management groups, subscriptions, and resource groups organize responsibility. Azure RBAC controls who can perform actions. Azure Policy controls allowed or required resource states. Tags, budgets, landing zones, and security or data-governance tools help teams move quickly inside inherited guardrails while exceptions remain visible and reviewable.

What You Should Remember

Governance is safe autonomy with scopes, roles, policies, ownership, cost visibility, and evidence.

Questions to Check Your Understanding

  1. How are Azure Policy and Azure RBAC different?

  2. Why do landing zones help governance?

  3. Why should exceptions have owners and review paths?