Designing Governance Solutions

Azure governance is the framework of rules, policies, and processes that ensure resources are deployed and managed in a consistent, compliant, and cost-effective manner. Without governance, organizations face sprawl, security risks, and cost overruns. The AZ-305 exam expects you to design governance solutions that align with business requirements, regulatory standards, and operational best practices.

Management groups are containers that help you manage access, policy, and compliance across multiple subscriptions. They form a hierarchy: a single root management group (tenant root group) at the top, with child management groups and subscriptions underneath. You can create up to 10,000 management groups in a single directory. A management group can have up to 1,000 child management groups. The hierarchy supports up to 6 levels of depth (not including the root level).

Azure Policy is a service that creates, assigns, and manages policies. These policies enforce different rules and effects over your resources, so those resources stay compliant with your corporate standards and service-level agreements. Azure Policy evaluates resources and actions against policy definitions.

- Policy Definition: A JSON document that defines the condition and the effect. Conditions use logical operators (if, then) and can check resource properties like location, size, tags, SKU, and more. Effects include: - Deny: Blocks the creation or update of a non-compliant resource. This is the strongest effect and is evaluated before the resource is created. - Audit: Creates a warning event in the activity log but does not block the request. Useful for detecting non-compliant resources without breaking deployments. - Append: Adds additional fields to the resource during creation or update. For example, automatically adding a required tag. - AuditIfNotExists: Enables auditing of resources related to the target resource. For example, auditing virtual machines that do not have a specific extension installed. - DeployIfNotExists: Deploys a template to remediate non-compliant resources. For example, automatically deploying a network security group. - Modify: Similar to Append but can also change existing properties on a resource. Requires a 'modify' role assignment. - Disabled: The policy is not evaluated. Useful for testing or temporarily turning off a policy.

Tags are metadata key-value pairs applied to Azure resources. They are not inherited from the resource group; you must explicitly assign them. Tags help with organization, cost allocation, and policy enforcement.

Azure Blueprints enable you to define a repeatable set of Azure resources that implements and adheres to your organization's standards, patterns, and requirements. A blueprint is a declarative package that includes:

Azure Resource Graph is a service that extends Azure Resource Manager and provides an efficient way to query resources across subscriptions. It uses the Kusto Query Language (KQL). You can use it to:

Understanding the order of evaluation is critical for the exam. When a resource creation request arrives at Azure Resource Manager: 1. Resource Manager receives the request and authenticates it. 2. Azure Policy evaluates the request against all applicable policies. Policies with 'Deny' effect are evaluated first. If any deny policy matches, the request is rejected with a 403 (Forbidden) status. 3. If no deny, policies with 'Append' or 'Modify' effects are applied, altering the request payload. 4. The resource is created with the modified payload. 5. Audit policies are evaluated and log events. 6. DeployIfNotExists policies trigger deployment of remediation templates if needed.

Compliance states include: - Compliant: Resource meets the policy condition. - Non-compliant: Resource does not meet the condition. - Exempt: Resource is exempt from policy evaluation (requires an exemption assignment). - Conflict: Two or more policies assign different effects to the same resource (rare).

Remediation: For policies with 'DeployIfNotExists' or 'Modify' effects, you can create a remediation task to bring existing non-compliant resources into compliance. Remediation tasks run asynchronously and can take time.

Aliases are the property paths that policies can evaluate. For example, Microsoft.Compute/virtualMachines/sku.name is an alias for the VM SKU. You can discover aliases using the Azure CLI:

az provider show --namespace Microsoft.Compute --expand "resourceTypes/aliases" --query "resourceTypes[].aliases"

When designing, consider: - Scope: Start with management groups for broad policies, then drill down to subscriptions and resource groups for specific needs. - Inheritance vs. Assignment: Assign policies at the highest possible scope to reduce duplication, but use exclusions carefully. - Policy Effects: Use 'deny' for mandatory requirements (e.g., allowed regions), 'audit' for monitoring, and 'modify' for auto-correction. - Tagging Strategy: Define a standard set of tags (e.g., CostCenter, Environment, Owner) and enforce them with policies. - Compliance Monitoring: Use Azure Policy compliance dashboard and Azure Resource Graph for reporting.

Create a policy definition:

az policy definition create --name "allowed-locations" --rules '{"if":{"not":{"field":"location","in":["eastus","westus"]}},"then":{"effect":"deny"}}'

Assign policy:

az policy assignment create --name "allowed-locations-assignment" --policy "allowed-locations" --scope /subscriptions/{subscription-id}

Create management group:

az account management-group create --name "MyGroup" --display-name "My Group"

Query resources with Resource Graph:

resources
| where type =~ 'microsoft.compute/virtualmachines'
| where properties.storageProfile.osDisk.osType == 'Windows'
| project name, location

A global company must ensure that all Azure resources are deployed only in approved regions (e.g., US East, EU West) to comply with data sovereignty laws. They use a root management group with a child group for each continent. At the root group, they assign a built-in policy 'Allowed locations' with a deny effect, specifying the approved regions. They also create a custom policy to require a 'DataClassification' tag (e.g., Public, Internal, Confidential). For resources missing the tag, an 'append' effect adds a default 'Internal' tag. They use Azure Blueprints to deploy a standard landing zone with these policies pre-assigned. Common issues: forgetting to add a new region to the allowed list causes deployment failures; policy updates take up to 30 minutes to propagate. They use Azure Resource Graph to audit compliance weekly.

A startup wants to prevent deployment of expensive VM SKUs (e.g., GPU instances) to control costs. They create a custom policy that denies creation of VMs with SKUs containing 'Standard_N' (N-series). They also enforce a 'CostCenter' tag on all resources, using a 'modify' effect to auto-tag resources from the resource group tag. They assign these policies at the subscription level. They use Azure Cost Management with tag-based filtering to allocate costs. Pitfall: developers often try to create VMs in a different region to bypass the policy, so they also enforce allowed regions. They set up compliance alerts to notify the finance team of any non-compliant resources.

A government agency must comply with NIST 800-53. They use Azure Policy's built-in 'NIST SP 800-53 R4' initiative, which includes hundreds of policies. They assign this initiative at the root management group. They also create custom policies for agency-specific requirements. They use Azure Blueprints to deploy a secure baseline that includes policies, RBAC roles, and network security groups. They perform monthly compliance scans using Azure Policy's compliance dashboard and generate reports for auditors. Challenge: the initiative includes many policies that may conflict with operational needs, requiring careful exclusions. They use exemptions sparingly and document each exemption. They also use Azure Resource Graph to quickly identify non-compliant resources across thousands of subscriptions.