AZ-305 - Design Governance
1. Azure Policy Overview
Azure Policy is a service that creates, assigns, and manages policies to enforce rules and effects on your resources. It ensures that resources stay compliant with corporate standards and service level agreements. Azure Policy evaluates resources and actions by comparing resource properties to business rules defined in policy definitions.
How Azure Policy Works
Policy Definitions and Assignments
A policy definition is a JSON document that describes the evaluation condition and the effect to take. An initiative definition (policy set) groups multiple policy definitions together for a single goal. A policy assignment attaches a definition or initiative to a specific scope (management group, subscription, or resource group). Policies are inherited from parent scopes to child scopes.
Policy Evaluation
Azure Policy evaluates resources at several points: when a resource is created or updated (real-time), when a policy is newly assigned or updated, during the standard compliance evaluation cycle (once every 24 hours), and on-demand via compliance scans. Evaluation results appear in the Policy Compliance dashboard in the Azure portal.
Built-in vs Custom Policies
Azure provides hundreds of built-in policies covering common governance scenarios. When built-in policies do not meet your requirements, you can create custom policy definitions using JSON. Custom policies use the same structure as built-in policies and support parameters for flexible reuse across different assignments.
| Aspect | Built-in Policies | Custom Policies |
|---|---|---|
| Management | Maintained and updated by Microsoft | Created and maintained by your organization |
| Availability | Available immediately in all tenants | Must be defined in your subscription/management group |
| Use Case | Common compliance (allowed regions, required tags) | Organization-specific rules and naming conventions |
| Parameters | Often parameterized for flexible assignment | Fully customizable parameters |
2. Assigning Policies
Policy assignments determine where a policy or initiative takes effect. Proper assignment strategy is critical for effective governance without blocking legitimate operations.
Assignment Scope
Scope and Exclusions
Policies can be assigned at management group, subscription, or resource group level. Assignments at higher scopes are inherited by all child scopes. You can use exclusions to exempt specific child scopes from a policy assignment. For example, assign a policy at the subscription level but exclude a sandbox resource group used for experimentation.
Policy Parameters
Parameters make policies reusable by allowing you to specify values at assignment time. For example, a single "Allowed locations" policy definition can be assigned multiple times with different region lists. Parameters can have default values, allowed values, and descriptions. Using parameters reduces the total number of policy definitions needed.
Remediation Tasks
Remediation for Existing Resources
Policy effects like deployIfNotExists and modify can remediate non-compliant existing resources through remediation tasks. A remediation task creates a managed identity that performs the deployment or modification. For existing resources that were created before the policy was assigned, you must create a remediation task manually. New resources are remediated automatically at creation time.
3. Policy Effects
Policy effects determine what happens when a policy rule is evaluated and the condition is met. Choosing the right effect is crucial: too permissive and non-compliant resources slip through; too restrictive and legitimate deployments are blocked.
Available Policy Effects
| Effect | Behavior | When to Use |
|---|---|---|
| Audit | Logs a warning in the activity log; resource is still created | Monitoring compliance without blocking; initial policy rollout |
| Deny | Blocks the resource creation or modification | Preventing non-compliant resources; enforcing hard requirements |
| DeployIfNotExists | Deploys a related resource if it does not exist | Ensuring diagnostic settings, extensions, or configurations exist |
| Modify | Adds, updates, or removes properties on a resource | Enforcing tags, disabling public access on storage accounts |
| AuditIfNotExists | Audits if a related resource does not exist | Checking that a diagnostic setting or lock exists |
| Disabled | Policy is not enforced | Testing policy definitions or temporarily suspending enforcement |
| Append | Adds additional fields to the resource during creation or update | Adding IP restrictions, enforcing HTTPS (legacy, prefer Modify) |
| DenyAction | Blocks specific actions on resources | Preventing deletion of critical resources |
Policy Effect Evaluation Order
Evaluation Order
When multiple policies apply to a resource, Azure Policy evaluates effects in this order: Disabled (checked first to skip evaluation), then Append/Modify, then Deny, then Audit. If a Deny effect fires, the request is blocked immediately. DeployIfNotExists and AuditIfNotExists run after the resource provider successfully completes the request.
Choosing Between Audit and Deny
Gradual Enforcement Strategy
Best practice is to start with Audit to understand the compliance impact before switching to Deny. This lets you identify non-compliant resources and notify resource owners before enforcement begins. Use Audit during initial rollout, then switch to Deny once stakeholders are prepared. Use DeployIfNotExists when you want to automatically fix non-compliance rather than block operations.
4. Template Specs
Template Specs are Azure resources that store ARM templates for later deployment. They enable centralized template management, versioning, and sharing across your organization without requiring external repositories.
Template Specs Key Features
What Are Template Specs?
A Template Spec is a resource type (Microsoft.Resources/templateSpecs) that stores an ARM template in Azure. Key benefits: Version control - maintain multiple versions of a template. Access control - use Azure RBAC to control who can deploy. Linked templates - can include linked templates as relative references. No external storage needed - templates are stored in Azure, not in external repos or storage accounts.
Template Specs vs Other Approaches
Compared to storing templates in a Git repository or storage account, Template Specs offer native Azure integration with RBAC, built-in versioning, and deployment via Azure portal, CLI, or PowerShell without needing a SAS token or external access. Users with Reader access to the Template Spec can deploy it, making it easy to share approved templates across teams.
Template Specs Governance Use Cases
Use Template Specs to provide approved, pre-configured infrastructure patterns: compliant VM configurations with required extensions, storage accounts with required security settings, networking patterns with approved NSG rules, and application hosting environments with proper monitoring. Teams can deploy these approved patterns without needing to understand all the underlying configurations.
5. Deployment Stacks
Deployment Stacks are Azure resources that manage a group of Azure resources as a single atomic unit. They provide lifecycle management, protection against unauthorized changes, and cleanup of resources that are no longer needed.
Deployment Stacks Key Features
What Are Deployment Stacks?
A Deployment Stack is a native Azure resource type that wraps an ARM/Bicep deployment and tracks all resources it creates. Key capabilities: Deny settings - prevent modifications or deletions of managed resources. Detach or delete on removal - choose whether removed resources are detached (kept but unmanaged) or deleted. Scope flexibility - can be created at resource group, subscription, or management group level.
Deny Settings for Resource Protection
Deployment Stacks support three deny settings: DenySettingsMode: None - no protection applied. DenySettingsMode: DenyDelete - prevents deletion of managed resources but allows updates. DenySettingsMode: DenyWriteAndDelete - prevents both modification and deletion of managed resources. These deny settings protect against accidental or unauthorized changes.
Deployment Stacks vs Resource Groups
| Feature | Resource Group | Deployment Stack |
|---|---|---|
| Resource Protection | Resource locks (CanNotDelete, ReadOnly) | Deny settings (DenyDelete, DenyWriteAndDelete) |
| Lifecycle Management | Manual cleanup of unused resources | Automatic cleanup when resources removed from template |
| Cross-Scope | Resources in one resource group only | Can manage resources across multiple resource groups |
| Template Tracking | Deployment history only | Maintains link between template and managed resources |
Governance with Deployment Stacks
Deployment Stacks enforce infrastructure-as-code governance by maintaining a persistent link between the template definition and the deployed resources. When you update the template and redeploy the stack, resources removed from the template can be automatically cleaned up. Combined with deny settings, this ensures that the deployed infrastructure always matches the approved template and cannot be modified outside of the deployment pipeline.
Key Terms
| Term | Definition |
|---|---|
| Azure Policy | Service for creating, assigning, and managing policies that enforce compliance rules on Azure resources. |
| Policy Initiative | A collection of policy definitions grouped together to achieve a single governance goal. |
| Policy Effect | The action taken when a policy condition is met (Audit, Deny, DeployIfNotExists, Modify, etc.). |
| Remediation Task | A process that applies DeployIfNotExists or Modify effects to existing non-compliant resources. |
| Template Spec | Azure resource that stores ARM templates with versioning, RBAC, and native deployment support. |
| Deployment Stack | Azure resource that manages a group of resources as a single unit with deny settings and lifecycle management. |
| DenyAction | Policy effect that blocks specific actions (like delete) on resources matching the policy condition. |
Exam Tips
- Start with Audit, then move to Deny: Best practice is to use Audit effect first to assess compliance impact, then switch to Deny once teams are ready. This avoids blocking legitimate deployments during rollout.
- DeployIfNotExists requires a managed identity: The policy assignment needs a managed identity to perform the remediation deployment. Existing non-compliant resources require a manual remediation task.
- Policy evaluation order matters: Disabled is checked first, then Append/Modify, then Deny, then Audit. If Deny matches, the request is blocked before Audit runs.
- Template Specs use Azure RBAC: Users with Reader access to a Template Spec can deploy it. This is simpler than managing SAS tokens for storage accounts or managing Git repository access.
- Deployment Stacks provide stronger protection than resource locks: Deny settings (DenyWriteAndDelete) prevent both modification and deletion, and they automatically clean up removed resources. Resource locks only prevent deletion or all changes.
- Policies are inherited from parent to child scopes: A policy assigned at the management group level applies to all subscriptions and resource groups below it. Use exclusions for exceptions.
Practice Questions
Question 1
Your organization requires that all Azure resources must have a "CostCenter" tag. Non-compliant resources that are already deployed should be automatically tagged with a default value. What policy effect should you use?
A. Audit
B. Deny
C. Modify
D. Append
Answer: C
The Modify effect can add, update, or remove tags on existing resources. It works during both creation and update operations and can remediate existing non-compliant resources via remediation tasks. Deny would block resource creation but would not fix existing resources. Audit would only log the non-compliance.
Question 2
You need to ensure that all VMs have the Azure Monitor Agent extension installed. If the extension is not present, it should be deployed automatically. What policy effect should you use?
A. Deny
B. AuditIfNotExists
C. DeployIfNotExists
D. Modify
Answer: C
DeployIfNotExists checks whether a related resource (the AMA extension) exists for the evaluated resource (the VM). If it does not exist, it triggers a deployment to install the extension. This automatically ensures compliance without blocking VM creation.
Question 3
You need to share a pre-approved ARM template for a compliant three-tier architecture across 10 development teams. Teams should be able to deploy the template but not modify it. What should you use?
A. Store the template in a shared Azure Storage account with SAS tokens
B. Create a Template Spec and grant Reader access to the development teams
C. Email the template file to all team leads
D. Store the template in a public GitHub repository
Answer: B
Template Specs store ARM templates as Azure resources with built-in RBAC, versioning, and deployment support. Granting Reader access to teams allows them to deploy the template but not modify the definition. This is more manageable and secure than SAS tokens or public repositories.
Question 4
You deployed a set of critical infrastructure resources using a Bicep template. You need to prevent anyone from deleting or modifying these resources outside of the deployment pipeline, and any resources removed from the template should be automatically cleaned up. What should you use?
A. Resource locks set to ReadOnly on all resources
B. Deployment Stack with DenyWriteAndDelete deny setting
C. Azure Policy with Deny effect on delete operations
D. Azure Blueprints with lock mode set to DoNotDelete
Answer: B
A Deployment Stack with DenyWriteAndDelete deny setting prevents unauthorized modification and deletion of managed resources. When resources are removed from the template and the stack is updated, those resources are automatically cleaned up. This provides both protection and lifecycle management.
Question 5
You are rolling out a new policy that requires all storage accounts to use HTTPS only. You want to understand the compliance impact before enforcement. Many teams actively create storage accounts daily. What approach should you take?
A. Assign the policy with Deny effect immediately
B. Assign the policy with Audit effect, review compliance, then switch to Deny
C. Create a custom initiative with both Audit and Deny effects
D. Use DeployIfNotExists to automatically enable HTTPS on all storage accounts
Answer: B
Starting with Audit effect lets you assess how many existing storage accounts are non-compliant and which teams would be affected by enforcement, without blocking any operations. After reviewing the compliance data and notifying stakeholders, you can change the effect to Deny to begin enforcement.
AZ-305 Designing Azure Infrastructure Solutions - Table of Contents
Master all exam topics with comprehensive study guides and practice questions.