Design Governance — Topic Lesson

This lesson integrates three governance-focused learning objectives for the AZ-305 exam: building scalable management-group hierarchies with effective tagging strategies (LO9), implementing compliance controls via Azure Policy and Microsoft Defender for Cloud (LO10), and establishing identity governance through Privileged Identity Management and entitlement management (LO11).

Reference: Ch. 1, §1.3–1.4, p. 28–40 of the AZ-305 exam book.

Why This Matters

Governance is the backbone of enterprise Azure deployments. Without a clear hierarchy, consistent compliance controls, and secure identity practices, organizations risk security breaches, compliance violations, and spiraling cloud costs. Large enterprises managing thousands of subscriptions and millions of resources need automated, policy-driven governance to enforce standards at scale. Azure's governance tools—management groups, Azure Policy, and PIM—work together to ensure that even the fastest-growing cloud estate remains compliant, secure, and cost-optimized.

During the AZ-305 exam, you'll encounter scenarios where you must design governance structures from scratch. Expect questions like: "Design a management-group hierarchy for a multinational company with regional subsidiaries" or "Enforce network security policies across 50 subscriptions without manual intervention." The principles tested are organizational design, scalability, and automation.

[!IMPORTANT] Governance decisions made at the design stage are hard to change later. A poorly structured hierarchy requires significant rework; policies locked into subscriptions cannot easily be shifted to management groups. The AZ-305 exam rewards architects who think about governance early and holistically.

Prerequisites

Before tackling this lesson, you should understand:

• Azure subscription and resource hierarchy basics: the relationship between tenants, subscriptions, resource groups, and resources.
• Azure role-based access control (RBAC): the difference between roles, scope, and principal assignment.
• Microsoft Entra ID / Entra ID fundamentals: user and group objects, application registration.
• Azure Policy syntax: basic familiarity with the Azure Policy language structure (conditions, effects, etc.).
• Bicep and ARM templates: comfort reading and writing infrastructure-as-code templates.
• Microsoft Entra ID (formerly Azure AD): understanding of service principals, managed identities, and conditional access concepts.

[!TIP] If you are unfamiliar with Azure RBAC or Azure Policy, review the AZ-305 Unit 0 foundation lessons first. This lesson builds heavily on those concepts.

Learning Objectives

After completing this lesson, you will be able to:

• LO9: Design a multi-level management-group hierarchy that supports organizational structure, cost allocation, and policy inheritance, and apply tagging strategies for cost management, compliance tracking, and resource organization.
• LO10: Select appropriate Azure Policy controls (built-in and custom), configure policy initiatives for regulatory compliance, and integrate Microsoft Defender for Cloud for continuous compliance monitoring.
• LO11: Implement Privileged Identity Management to enforce just-in-time access and approval workflows, design identity governance workflows with access reviews and entitlement management, and integrate conditional access with PIM to strengthen security posture.

Building Blocks

Management Groups are organizational containers that sit above subscriptions. They enable you to apply policies, roles, and RBAC assignments to multiple subscriptions at once, supporting hierarchies up to six levels deep (not counting the root).

Tagging is a key-value metadata system applied to resources, resource groups, and subscriptions. Tags enable cost tracking, resource filtering, automation, and compliance labeling. Azure Policy can enforce tagging rules and ensure compliance with organizational tagging standards.

Azure Policy is a service that defines and enforces rules for resource properties and configurations. It operates via policy definitions (the rule), assignments (scope + parameters), and effects (Deny, Audit, Append, Modify, DeployIfNotExists, AuditIfNotExists).

Privileged Identity Management (PIM) is a security service that manages, monitors, and audits access to critical Azure resources. PIM enables just-in-time (JIT) activation, time-limited assignments, and approval workflows for privileged roles.

Access Reviews are periodic recertifications conducted by resource owners to confirm that active role assignments are still appropriate. Reviews can be recurring (e.g., quarterly) and support delegation to managers.

Entitlement Management provides a self-service catalog of access packages (bundles of permissions and resources) that users can request, with automated approval workflows and expiration policies.

Deep Dive

Management-Group Hierarchy & Tagging (LO9)

Organizational Design Patterns

When designing a management-group hierarchy, the principle is inheritance from the top. Policies and RBAC assignments flow down the tree, so decisions made at the root affect all descendants. Common design patterns include:

1. By Environment: Root → Production/Staging/Development. This separates workloads by lifecycle, applying stricter policies to Production.
2. By Business Unit: Root → Sales/Engineering/Finance. Useful for large organizations where teams manage their own subscriptions but share core policies.
3. By Geography: Root → North America/EMEA/APAC. Aligns with regulatory boundaries and data residency requirements.
4. Hybrid: Root → Business Unit (L1) → Environment (L2) → Geography (L3). This pattern supports complex enterprises but requires careful naming and documentation.

Each subscription belongs to exactly one management group, and each management group (except the root) has exactly one parent. The hierarchy cannot exceed six levels of depth.

Tagging Strategy

Effective tagging requires upfront planning. Common tag categories include:

[!NOTE] Tags are case-insensitive but whitespace-sensitive. Avoid spaces in tag values; use hyphens or camelCase instead. For example, use environment: prod-east not environment: prod east.

Azure Policy can enforce tagging rules at creation and modification time. Policies can use the Append or Modify effect to add missing tags automatically, or the Deny effect to reject non-compliant resources.

Policy-Driven Tag Inheritance

While Azure does not natively inherit tags from parent resource groups or subscriptions to child resources, you can use Azure Policy with the Modify effect to copy tags from resource group to child resources at deployment time. This enables pseudo-inheritance.

[!TIP] For the AZ-305 exam, remember that tag inheritance is not automatic — it requires an Azure Policy with the Modify effect. The built-in policy Inherit a tag from the resource group (policy ID cd3aa116-8754-49c9-a813-ad46512ece54) is the quickest way to enable this pattern.

Resource Group Design Considerations

Resource groups are the lowest scope at which Azure Policy can be assigned and are the natural unit of lifecycle management. A well-designed resource group strategy answers three questions: (1) which resources share the same lifecycle? (2) who needs access? (3) which cost centre owns the spend?

For deeper coverage of naming conventions and advanced inheritance patterns, see the LO9-level lesson.

Compliance Management (LO10)

Azure Policy Fundamentals

Azure Policy evaluates resource properties against user-defined rules. A policy definition contains:

• mode: All (all resource types) or Indexed (only resource types with tags/location properties)
• conditions: logical checks using operators like equals, like, contains, in
• effect: the action taken if the condition is true

Common policy effects:

Policies are assigned to a scope: management group, subscription, or resource group. Assignments inherit down the hierarchy.

Policy Initiatives

An initiative (or initiative definition) groups multiple policies together. For example, the built-in initiative Enable Monitoring in Azure Security Center contains 100+ policies related to monitoring and logging. Initiatives streamline management and ensure consistent coverage.

Microsoft Defender for Cloud Integration

Defender for Cloud (formerly Security Center) provides:

• Secure Score: A normalized 0–100 score reflecting your security posture across Azure, hybrid, and multi-cloud environments.
• Regulatory Compliance Dashboard: Shows compliance status against frameworks (PCI-DSS, HIPAA, CIS, etc.).
• Policy Recommendations: Suggests built-in policies to improve compliance and security.
• Just-in-Time VM Access: Restricts RDP/SSH access to virtual machines and audits access attempts.
• Threat Protection: Detects suspicious activities and alerts on compromises.

Defender for Cloud integrates with Azure Policy, automatically deploying policies as recommendations.

Azure Blueprints (Deprecation Note)

Azure Blueprints enabled repeatable deployments of resource groups, templates, and policy assignments. However, Microsoft is transitioning to Deployment Stacks and Template Specs for similar functionality. For new designs, prefer Deployment Stacks; Blueprints remain supported but are not recommended for new architectures.

Microsoft Defender for Cloud Plans

Microsoft Defender for Cloud provides two tiers: the free Foundational CSPM and the paid Defender plans that add runtime threat protection per resource type.

The secure score aggregates findings into a 0–100% metric. Regulatory compliance dashboards map recommendations to controls in CIS, PCI-DSS, and ISO 27001.

For custom policy authoring patterns and regulatory compliance workflows, see the LO10-level lesson.

Identity Governance (LO11)

Privileged Identity Management (PIM)

PIM enforces the principle of least privilege by making privilege temporary and approval-gated. Key features:

• Just-in-Time (JIT) Activation: Users request temporary elevation to a privileged role (e.g., Owner, Contributor). Once approved, access is granted for a set duration (e.g., 8 hours) and automatically revoked.
• Approval Workflows: Activation requests are routed to designated approvers. Multiple approvers can be required for sensitive roles.
• Time-Bound Assignments: Even permanent role assignments can be configured to expire after a set date, forcing re-review.
• Audit Trail: All activation requests, approvals, and privilege usage are logged in the activity log.
• Multi-Factor Authentication (MFA): Activation can require MFA, adding a second verification factor.

Access Reviews

Access reviews are periodic (e.g., quarterly) audits where resource owners or managers certify that active role assignments are still appropriate. A review can:

• Target Azure RBAC roles, Entra ID groups, or application assignments.
• Be self-reviewed (user confirms their own access) or manager-reviewed (manager certifies on behalf of team).
• Automatically remove or disable access if not reviewed within a deadline.
• Generate reports for compliance audits.

Entitlement Management

Entitlement Management provides self-service access provisioning and compliance. Users can request bundles of permissions and resources (access packages) from a self-service catalog. Access packages can include:

• Azure RBAC roles
• Entra ID group memberships
• Microsoft 365 group memberships
• Application access (via Entra ID)

Organizations define approval workflows, which can involve multiple approvers, manager verification, or automated business rules. Packages can include expiration dates, triggering automatic access revocation.

Conditional Access + PIM Integration

Conditional Access policies can require MFA, device compliance, or specific locations before allowing access to sensitive resources. When combined with PIM, Conditional Access policies can:

• Require MFA for PIM activation requests from untrusted locations.
• Block PIM activation unless the user's device is compliant (e.g., encrypted disk, firewall enabled).
• Log all PIM activations to a Conditional Access policy log for later audit and threat investigation.

Entitlement Management in Depth

Entitlement management bundles resource roles into access packages that users can request through a self-service portal. A catalog organises related packages, and connected organisations allow pre-approved external domains to request packages with automatic approval policies.

Configure access packages with periodic access reviews so every 90 days the resource owner must re-certify each assignee — denied reviews automatically revoke access.

For Conditional-Access integration and catalog design patterns, see the LO11-level lesson.

Worked Examples

Example 1: Easy — Design a Simple Hierarchy for a Mid-Market Company

Scenario: Contoso Technologies has three departments (Sales, Engineering, Operations) and operates in two regions (US, EU). They run separate subscriptions for dev, staging, and production. Design a management-group hierarchy and tagging strategy.

Solution:

Each leaf management group hosts subscriptions for that department-environment combination. Tagging:

• environment: prod / staging / dev
• department: sales / engineering / operations
• region: us / eu
• cost-center: 1001, 1002, 1003 (per department)
• data-class: public / internal / confidential

Policies applied at the Production level enforce stricter disk encryption and network isolation; Development level policies are more permissive to encourage experimentation.

Example 2: Medium — Enforce Tagging with Azure Policy

Scenario: Contoso wants to ensure all resources are tagged with environment, cost-center, and owner. Resources without these tags should be denied creation. Write a policy to enforce this.

Solution: A custom policy using the Deny effect:

Alternatively, use a Modify policy to auto-append default tags (e.g., owner: unassigned) and enforce the required three tags via a separate Audit policy that monitors for their presence. This approach is less disruptive during rollout.

Example 3: Hard — Implement PIM for a Multi-Approval Workflow

Scenario: Contoso's production subscriptions contain mission-critical resources. They want to require PIM activation with two-step approval: (1) the team lead, then (2) the security manager. Activation is limited to 4 hours. Design the PIM configuration.

Solution:

1. Create a custom Azure RBAC role Production-Operator with limited permissions (read + restart VMs, no delete).
2. Use PIM to define an "eligible" assignment of this role to a group containing team leads.
3. Configure PIM settings for the role:
   • Activation duration: 4 hours
   • Require MFA for activation
   • Require approval: Yes
   • Approvers: Add the security manager as primary, team lead as fallback
   • Require justification: Yes (user must explain why they need access)
   • Audit active assignments: Yes
4. Create an access review scheduled for quarterly, managed by the security manager.
5. Integrate Conditional Access: require MFA and device compliance for PIM activations from outside the corporate network.

When a team lead requests activation, the security manager receives a notification, reviews the justification, and approves or denies. Once approved, the activation is granted for exactly 4 hours.

Visual Explanations

Diagram 1: Management-Group Hierarchy with Policy Inheritance

Diagram 2: Azure Policy Evaluation Flow

Diagram 3: PIM Approval Workflow

Userflow: User → Request → Approver(s) → Decision → Activation → Expiration

Diagram 4: Tagging Strategy Hierarchy

Diagram 5: Hub-Spoke Governance Architecture (TikZ)

Table: Azure Policy Effects Comparison

Table: PIM vs. Static RBAC

Table: Management-Group Design Patterns

Common Mistakes

Myth 1: Tagging is optional; I can filter resources by name or search.

Reality: Tags are the only consistent, programmatic way to organize and automate governance across resources. Without tags, cost allocation becomes guesswork, compliance audits fail, and automation breaks. Azure Policy can enforce tagging; resource names cannot be reliably parsed.

Why it's tricky: Early-stage projects often skip tagging as "nice-to-have," but retrofitting tags later across thousands of resources is costly and error-prone.

---

Myth 2: A flat management-group structure (just the root) is simpler and sufficient.

Reality: A flat structure scales poorly. Policies assigned to the root affect all subscriptions identically; you cannot apply different policies to different teams, environments, or regions. With 50+ subscriptions, a flat structure becomes unmaintainable. A thoughtful hierarchy enables delegation and reduces the blast radius of misconfigurations.

Why it's tricky: The immediate simplicity of "no hierarchy" is appealing, but it creates technical debt as the organization scales.

---

Myth 3: Azure Policy Deny effects always block non-compliant resources.

Reality: Deny policies can be bypassed by resource owners who have the "Microsoft.Authorization/policyAssignments/write" permission. Deny effects are strong but not absolute; they rely on RBAC to prevent privilege escalation. Additionally, Deny effects do not remediate already-deployed non-compliant resources; they only prevent new ones.

Why it's tricky: Teams often assume a Deny policy is a hard technical block, then discover the policy was ineffective because someone with the right RBAC permission worked around it.

---

Myth 4: PIM activation is instantaneous; users get access immediately upon approval.

Reality: PIM activation takes several seconds to propagate through Azure's role-assignment system. Cached tokens and permission evaluations may take up to 10 minutes to refresh. Users should expect a brief delay (typically under 1 minute) between approval and usable access.

Why it's tricky: If a user activates a role and immediately tries to perform a restricted action, they may encounter a "not authorized" error, thinking the activation failed, when in fact the propagation is still in progress.

---

Myth 5: Entitlement Management and Access Reviews duplicate PIM; I only need one.

Reality: They serve different purposes. PIM manages who has access and when they can use it. Access Reviews ensure that access is still needed. Entitlement Management provides self-service provisioning of bundles of access. Used together, they form a complete identity governance system.

Why it's tricky: Many architects select only one tool, missing the complementary benefits of the others.

Practice Exercises

Exercise 1: Design a management-group hierarchy for a financial services company with three business units (Investment Banking, Retail Banking, Risk Management), two regions (US, EU), and three environments (Production, Staging, Dev). Each region-environment combination requires a separate subscription per business unit. Draw or describe the hierarchy. How many management groups do you create?

▶💡 Hint

Consider a hybrid approach: Layer 1 = Business Unit, Layer 2 = Region, Layer 3 = Environment. Count the total depth.

▶✅ Solution

Structure:

Root ├── Investment Banking │ ├── US │ │ ├── Prod │ │ ├── Staging │ │ └── Dev │ └── EU │ ├── Prod │ ├── Staging │ └── Dev ├── Retail Banking (similar structure) └── Risk Management (similar structure)

Total management groups: 1 (root) + 3 (business units) + 6 (regions, 2 per unit) + 18 (environments, 3 per region) = 28 groups. (Subscriptions are not management groups.) Depth: 4 levels, within the 6-level limit. Each production subscription can inherit strict policies from the Prod management group; development subscriptions inherit permissive policies.

---

Exercise 2: Write a PowerShell script to create three management groups: Production, Staging, and Development, all under the root. Then assign a built-in policy ("Allowed locations") to the Production group to restrict resources to East US and West US only.

▶💡 Hint

Use New-AzManagementGroup to create groups and -ParentId to specify the parent. For policy assignment, use New-AzPolicyAssignment.

▶✅ Solution

powershellCopy

# Create management groups $rootId = (Get-AzTenant).Id New-AzManagementGroup -GroupName "Production" -DisplayName "Production" -ParentId "/providers/Microsoft.Management/managementGroups/$rootId" New-AzManagementGroup -GroupName "Staging" -DisplayName "Staging" -ParentId "/providers/Microsoft.Management/managementGroups/$rootId" New-AzManagementGroup -GroupName "Development" -DisplayName "Development" -ParentId "/providers/Microsoft.Management/managementGroups/$rootId" # Get the Production management group ID $prodMgId = (Get-AzManagementGroup -GroupName "Production").Id # Get the built-in policy definition for allowed locations $policy = Get-AzPolicyDefinition | Where-Object { $_.Properties.DisplayName -eq "Allowed locations" } # Assign the policy New-AzPolicyAssignment ` -Name "AllowedLocations-Prod" ` -DisplayName "Restrict to East/West US (Production)" ` -PolicyDefinition $policy ` -Scope $prodMgId ` -PolicyParameterObject @{"listOfAllowedLocations" = @("eastus", "westus")}

---

Exercise 3: Write a Bicep template that deploys an Azure Policy assignment. The policy should enforce that all storage accounts have encryption at rest enabled. Assign it to a subscription scope.

▶💡 Hint

Use Microsoft.Authorization/policyAssignments resource type. Reference a built-in policy by ID. Storage encryption is commonly covered by the Require secure transfer to storage account or similar built-in policy.

▶✅ Solution

bicepCopy

param subscriptionId string = subscription().subscriptionId param policyDisplayName string = 'Enforce Storage Encryption' resource policyAssignment 'Microsoft.Authorization/policyAssignments@2021-06-01' = { name: 'storage-encryption-enforce' properties: { displayName: policyDisplayName policyDefinitionId: '/providers/Microsoft.Authorization/policyDefinitions/7c1b1214-f927-48bf-8882-84f0af7b9d64' // Built-in: Require secure transfer to storage account scope: '/subscriptions/${subscriptionId}' enforcementMode: 'Default' parameters: { effect: { value: 'Deny' } } } } output assignmentId string = policyAssignment.id

---

Exercise 4: Your organization has 100 subscriptions and wants to ensure all resources are tagged with environment (prod/stage/dev) and cost-center (numeric ID). Write a custom Azure Policy definition that appends the default cost-center: 9999 tag if missing, and audits for the missing environment tag.

▶💡 Hint

Create two policy definitions: one with Append effect for cost-center (add if missing), one with Audit effect for environment (log if missing).

▶✅ Solution

jsonCopy

{ "mode": "All", "policyRule": { "if": { "allOf": [ { "field": "tags[cost-center]", "exists": false } ] }, "then": { "effect": "Append", "details": [ { "field": "tags[cost-center]", "value": "9999" } ] } } }

For the environment tag audit:

jsonCopy

{ "mode": "All", "policyRule": { "if": { "field": "tags[environment]", "exists": false }, "then": { "effect": "Audit" } } }

---

Exercise 5: Configure PIM for a custom role Database-Admin-Prod assigned to the Production subscription. Require two approvers (security manager + database team lead) for activation, limit activation duration to 2 hours, and require MFA. Create an access review scheduled for quarterly.

▶💡 Hint

Use Azure Portal → PIM → Azure Resources → Production subscription → Roles → Database-Admin-Prod. Configure "Role settings" (approvers, duration, MFA) and "Access reviews" (quarterly schedule, approver = security manager).

▶✅ Solution

Steps:

1. Navigate to PIM → Azure Resources → Production subscription.
2. Click "Roles" and find or create "Database-Admin-Prod".
3. Click "Role settings" (gear icon).
4. Activation requirements:
   • Set "Maximum activation duration" to 2 hours.
   • Enable "Require Azure Multi-Factor Authentication on activation" → Yes.
   • Enable "Require approval to activate" → Yes.
   • Set "Approvers" to Security Manager and Database Team Lead.
5. Save.
6. Go to Access reviews section.
7. Click Create access review.
8. Scope: select the role and subscription.
9. Frequency: Quarterly.
10. Reviewer: Security Manager.
11. Auto-apply: disabled (manual review).
12. Create.

Result: Users who are eligible for Database-Admin-Prod must activate through PIM, get approval from both approvers, and access is granted for 2 hours only. Quarterly, the security manager reviews who still needs access.

Summary & Concept Map

Key Takeaways:

• Management groups enable hierarchical policy inheritance across subscriptions; design them to match your organizational structure (by environment, business unit, or geography).
• Tagging is the foundation of cost allocation, compliance, and automation; use Azure Policy to enforce tagging rules at creation and modification.
• Azure Policy provides declarative governance with multiple effects (Deny, Audit, Modify, DeployIfNotExists) that scale across hundreds of subscriptions.
• Privileged Identity Management enforces just-in-time, time-limited, and approval-gated access for sensitive roles, reducing the attack surface of excessive standing privilege.
• Access reviews and entitlement management complete the identity governance picture, ensuring that access is regularly recertified and provisioning is self-service.
• Integration is critical: combine management groups, policy, PIM, Conditional Access, and Defender for Cloud to create a defense-in-depth governance strategy.

Concept Map:

Connections & Next Steps

Horizontal Connections:

• This lesson on governance complements the AZ-305 lessons on infrastructure security (network isolation, encryption) and data governance (data classification, encryption keys).
• Governance directly supports cost management: tagging enables chargeback; policy prevents expensive misconfigurations (e.g., unencrypted storage replication).
• Identity governance (PIM, access reviews, entitlement) aligns with lessons on identity and access management.

Recommended Next Steps:

1. Implement a pilot: Design and deploy a management-group hierarchy for a non-critical subscription set. Apply basic policies (tagging, encryption) and monitor compliance in Defender for Cloud.
2. Master Bicep and ARM: Governance-as-code (Bicep templates for policy assignments, role definitions, and management groups) is essential for scalable deployments.
3. Study conditional access policies: Conditional Access is a powerful complement to PIM; learn how to layer authentication factors, device compliance checks, and location-based policies.
4. Prepare for governance scenarios: The AZ-305 exam often includes scenario-based questions like "Design a governance strategy for a multi-cloud enterprise" or "Remediate non-compliant resources across 50 subscriptions." Practice designing solutions that balance automation, compliance, and user experience.
5. Explore advanced topics: Custom policy definitions, Azure Lighthouse for delegated resource management, and cost optimization with Azure Cost Management + Billing.

[!IMPORTANT] Governance is not a one-time project; it is an ongoing practice. As your Azure estate grows, regularly review and refine your hierarchy, policies, and identity workflows. Use Defender for Cloud recommendations and access review feedback to stay compliant and secure.