What's changed: Deepened AZ-305 Chapter 1 (added comparison tables, scenarios, FAQs, exam traps, deep-dive paragraphs to each section; localized figures to Japanese)
1.2Designing Governance
Understand organization-scale governance—management groups/subscriptions, Azure Policy, landing zones, tags, cost management, and resource locks. Design consistent guardrails and cost control.
At scale, guardrails are essential. With a management group hierarchy and Azure Policy, enforce consistent governance org-wide.
1.2.1Governance hierarchy
- Management groups: hierarchically group subscriptions, inheriting policy/RBAC.
- Azure Policy: enforce allow/deny/audit on resources for compliance (e.g., allowed regions).
- Landing zones: standardized foundation blueprints (pre-configured network/identity/policy).
- Tags/Cost Management/locks: enable cost allocation, budget alerts, and deletion protection.
Common on AZ-305: hierarchical multi-subscription governance = management groups, enforce allow/deny/audit = Azure Policy, standard foundation blueprint = landing zone, cost allocation = tags, budget alerts = Cost Management, deletion protection = resource locks. Azure Policy serves as a preventive guardrail (akin to AWS SCPs).
AZ-305 governance design probes "at which tier and via which mechanism to land the org’s control requirements." Management groups tier subscriptions so that policy/RBAC assigned at the root group inherit downward, enforcing company-wide guardrails centrally. Azure Policy is built from effects (Deny = preventively refuse creation, Audit = record drift, DeployIfNotExists/Modify = auto-remediate/tag), bundled into initiatives (policy sets) for distribution, with a compliance dashboard visualizing conformance. The org-wide foundation is an Azure landing zone (Cloud Adoption Framework enterprise-scale), deploying network (hub-and-spoke), identity, policy, and management as a pre-configured blueprint. For cost, tags allocate spend to departments/projects, Cost Management handles budgets/alerts/analysis/recommendations, and billing is managed via the EA/MCA account hierarchy. Resource locks (CanNotDelete/ReadOnly) prevent accidental deletion/changes and take precedence over roles and policies. The design key is to combine prevention (Deny), detection (Audit), and remediation (DeployIfNotExists), placing common guardrails at the top management group to inherit downward.
| Governance goal | Means | Key point |
|---|---|---|
| Centralize many subscriptions | Management groups | Policy/RBAC inherited |
| Enforce/audit/remediate config | Azure Policy (initiatives) | Deny/Audit/DeployIfNotExists |
| Standardized foundation | Landing zone | CAF; hub-and-spoke; pre-configured |
| Cost allocation/budgets/protection | Tags; Cost Management; locks | Locks take precedence over roles/policies |
Scenario: Enforce company-wide "resources only in Japan regions, no untagged resources, diagnostic logs always enabled," auto-applied to new subscriptions too. → Assign an initiative bundling allowed-regions (Deny), required-tags (Deny/Modify), and diagnostic settings (DeployIfNotExists) at the root management group, inherited by subscriptions below. Monitor conformance on the compliance dashboard; new subscriptions auto-inherit simply by being placed under the management group.
FAQ: Azure Policy vs RBAC? RBAC controls "who can perform which actions" (permissions); Azure Policy controls "what state resources must be in" (compliance). E.g., "permission to create a VM" is RBAC, while "created VMs must be a certain SKU/region" is Azure Policy. They are complementary—governance needs both.
Exam trap: Trying to "prevent resource creation outside certain regions" with RBAC is wrong. RBAC controls operation permissions; enforcing resource attributes (region/SKU/tags) is Azure Policy (Deny). Also, resource locks take precedence over roles/ownership—even an Owner cannot delete while a lock is in place.
1.2.2Section summary
- Governance = management group hierarchy + Azure Policy + landing zones
- Cost/protection = tags, Cost Management, resource locks
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. You want to apply consistent policy and RBAC hierarchically across many subscriptions. What?
Q2. You want an enforceable rule that resources can only be created in certain regions. What?
Q3. You want to prevent accidental deletion of production resources. What?