Well-Architected Framework: Governance Pillar

The Governance pillar of the Well-Architected Framework provides guidance on how to manage and control Azure resources at scale. It ensures that your environment remains secure, compliant, and cost-effective by enforcing organizational standards and best practices. Without governance, a cloud environment can quickly become a chaotic mix of unmanaged resources, security vulnerabilities, and spiraling costs. The pillar focuses on four key areas: - Policy and Compliance: Using Azure Policy to enforce rules and ensure resources comply with corporate or regulatory standards. - Resource Organization: Using management groups, subscriptions, and resource groups to structure resources logically. - Cost Governance: Monitoring and controlling spending through budgets, alerts, and tagging. - Automation and Remediation: Automating compliance checks and remediation actions to maintain a desired state.

For the AZ-104 exam, you must understand how to implement these controls, especially Azure Policy and management groups, as they are frequently tested.

Azure governance operates through a hierarchy of management groups, subscriptions, resource groups, and individual resources. At the top, a tenant has a root management group. Under it, you can create a hierarchy of management groups to represent your organization's structure (e.g., by department, geography, or environment). Each management group can have Azure Policy assignments and role assignments that are inherited by all child subscriptions and resource groups.

Azure Policy is the core enforcement mechanism. When you create a policy definition (e.g., 'Allowed locations for resources'), Azure Policy evaluates all existing and new resources against that definition. The evaluation occurs at resource creation, update, and periodically (every 24 hours for compliance scanning). The policy engine checks the resource's properties against the policy rule. If a resource violates a policy with effect 'Deny', the creation or update is blocked. If the effect is 'Audit', a compliance warning is logged but the action proceeds. 'Append' adds additional properties (like tags) during creation. 'DeployIfNotExists' triggers a remediation task to fix non-compliant resources.

Azure Blueprints extend this by packaging policy assignments, role assignments, ARM templates, and resource groups into a repeatable artifact. When you assign a blueprint to a subscription, Azure Blueprints deploys all included artifacts and creates a versioned deployment record. This allows you to track which blueprint version was applied and audit changes over time.

- Management Groups: Up to 10,000 management groups in a single directory. A management group tree can support up to six levels of depth (not including the root). The root management group is created automatically for each Azure AD tenant and cannot be deleted. - Azure Policy: Over 100 built-in policy definitions. Custom definitions can be created. Policy assignments can target management groups, subscriptions, or resource groups. The default compliance scan interval is 24 hours, but you can trigger an on-demand scan using Start-AzPolicyComplianceScan. - Policy Effects: - Deny: Blocks the resource creation/update and returns an error. - Audit: Creates a warning in the activity log but allows the action. - Append: Adds specified fields (e.g., tags) to the resource during creation/update. - AuditIfNotExists: Audits resources that do not have a specified extension or configuration. - DeployIfNotExists: Deploys a template to remediate non-compliant resources. - Disabled: Turns off the policy. - Azure Blueprints: Each blueprint can have multiple artifacts. Blueprint versions are created when you publish. Assignments can be locked to prevent unauthorized modifications (ReadOnly, DoNotDelete, or None). - Tags: Resource tags are key-value pairs. Tags can be applied to resources, resource groups, and subscriptions. Azure Policy can enforce tagging rules (e.g., require a 'CostCenter' tag). - Cost Management + Billing: Budgets can be set at subscription or resource group scope. Alerts trigger at thresholds (e.g., 50%, 100%, 200% of budget).

To create a management group:

New-AzManagementGroup -GroupName "Contoso" -DisplayName "Contoso"

To assign a built-in policy:

$definition = Get-AzPolicyDefinition | Where-Object {$_.Properties.DisplayName -eq "Allowed locations"}
New-AzPolicyAssignment -Name "AllowedLocations" -PolicyDefinition $definition -Scope "/subscriptions/{subscription-id}" -PolicyParameterObject @{listOfAllowedLocations=@("eastus","westus")}

To check compliance:

Get-AzPolicyState -PolicyAssignmentName "AllowedLocations" -Scope "/subscriptions/{subscription-id}"

To create a blueprint:

Import-AzBlueprintWithArtifact -Name "MyBlueprint" -SubscriptionId "{subscription-id}" -InputPath "./blueprint"
Publish-AzBlueprint -Blueprint $blueprint -Version "1.0"
New-AzBlueprintAssignment -Name "MyBlueprintAssignment" -Blueprint $blueprint -SubscriptionId "{subscription-id}" -Location "eastus"

Azure Policy integrates with Azure RBAC: while RBAC controls who can perform actions, Policy controls what resources can be created or modified. Policy does not replace RBAC; they work together. For example, a user may have Contributor role (can create VMs), but a policy may deny creating VMs in certain regions.

Azure Blueprints interact with Azure Policy and RBAC by bundling them into a single assignable package. Blueprints also integrate with Azure DevOps through the Azure Blueprints extension, enabling CI/CD for governance.

Cost Management uses tags and policy compliance data to provide cost analysis and recommendations. Budgets can trigger automation runbooks to shut down resources when spending exceeds limits.

| Component | Limit/Default | |-----------|---------------| | Management groups per directory | 10,000 | | Levels of management group hierarchy | 6 (excluding root) | | Policy assignments per scope | 200 | | Policy definition size limit | 1 MB | | Blueprint artifact count per blueprint | 200 | | Compliance scan interval | 24 hours | | Number of tags per resource | 50 | | Tag key length limit | 512 characters | | Tag value length limit | 256 characters |

These numbers are frequently tested on the exam.

A global company with operations in North America, Europe, and Asia needs to ensure that all Azure resources comply with regional data sovereignty laws. For example, European resources must stay within EU regions, and US resources must be in US regions. The company creates a management group hierarchy: a root group for the entire tenant, then child groups for 'Americas', 'EMEA', and 'APAC'. Under each region, there are 'Production' and 'Non-Production' groups. At the regional management group level, they assign an Azure Policy with 'Deny' effect that restricts allowed locations to the specific regions. For example, the 'EMEA' group policy only allows 'West Europe' and 'North Europe'. Additionally, they require all resources to have a 'DataResidency' tag indicating the region. This policy uses 'Append' to add the tag if missing. The company also uses Azure Blueprints to deploy a standard landing zone for each region, including network topology, governance policies, and RBAC. A common issue is that developers sometimes try to deploy resources in unauthorized regions, but the 'Deny' policy blocks the deployment and logs the attempt. The governance team monitors these attempts and provides training to developers. Performance-wise, the policy evaluation adds negligible latency to resource creation (typically less than 100ms). Misconfiguration can occur if the policy scope is too broad or too narrow; for example, accidentally allowing all locations at the root management group would override regional policies if not properly structured.

A startup has separate Azure subscriptions for Engineering, Marketing, and Sales. Each team has a monthly budget. The company uses Azure Policy to enforce tagging: every resource must have 'Department' and 'Project' tags. A policy with 'Append' effect adds the tags during creation, but for existing resources, they run a remediation task. They set up budgets at each subscription level. For example, the Engineering subscription has a $10,000 monthly budget with alerts at 80%, 100%, and 120%. When the 100% alert fires, an action group triggers an Automation runbook that stops all non-production VMs. This prevents cost overruns. The company also uses management groups to aggregate costs across departments. A common problem is that teams forget to tag resources, causing budget alerts to miss certain costs because tags are missing. To mitigate, they enforce tagging with policy and also use Cost Management's 'Group by' tag feature. Another issue is that budget alerts sometimes fire late due to the 24-hour latency in cost data. The company accounts for this by setting alerts at lower thresholds (e.g., 70% instead of 80%). This scenario highlights the importance of combining policy enforcement with proactive cost monitoring.

A government agency must comply with FedRAMP and NIST frameworks. They use Azure Policy to enforce hundreds of security controls, such as requiring encryption at rest, enforcing TLS versions, and blocking public IP addresses on VMs. They create custom policy initiatives (policy sets) that bundle multiple policies into a single assignment. For example, an initiative called 'FedRAMP High Baseline' contains 50 policy definitions. They assign this initiative at the root management group to cover all subscriptions. They also use Azure Blueprints to deploy a secure landing zone that includes network security groups, encryption configurations, and logging. The blueprint includes role assignments for security administrators. To maintain compliance, they run weekly compliance scans and generate reports using Azure Policy's compliance dashboard. They also use Azure Sentinel to integrate policy violation alerts. A common mistake is assigning too many policies at the root, which can cause performance issues during policy evaluation. Azure recommends limiting the number of policy assignments per scope to 200. Another issue is that some policies may conflict; for example, one policy requires a tag, while another denies resources without that tag. Proper testing in a non-production environment is essential.