Path 2 · Module 1 · Draft version B: Case study

Design governance

You've just been hired as the Azure architect at Kestrel Logistics. Over the next hour, four colleagues come to you with requests. Each request is one unit of the Microsoft Learn module: management groups, subscriptions, resource groups, tags, Azure Policy, RBAC and landing zones. By the end, you've designed Kestrel's whole governance model, one decision at a time.

Meet Kestrel Logistics

Kestrel moves goods by road across the Netherlands, Germany and Poland. About 2,000 employees. Today, everything runs in one Azure subscription that a developer created three years ago with a company credit card. It holds:

• TrackIt: the customer-facing shipment tracking website (internet-facing, 24/7).
• Fleet: an internal app that collects GPS data from 1,200 trucks (IoT, lots of data).
• Payroll: the HR and payroll system (personal data, strict access).
• A pile of test VMs nobody admits to owning.

The people you'll meet:

1 · "Where do we even start?" · Design for governance

Governance means keeping control over your applications and resources: deciding requirements, planning initiatives and setting priorities. But rules need a place to live. If Kestrel has one subscription, every rule applies to everything: production, test VMs and payroll alike.

So the first step is a hierarchy with four levels, each a place to attach rules:

• Management groups: access, policy and compliance across multiple subscriptions.
• Subscriptions: units of management, billing and scale.
• Resource groups: containers to deploy and manage resources in.
• Resources: the VMs, databases and storage accounts themselves.

Above them is the tenant root group, which contains everything in the Entra tenant. Anything assigned at a level is inherited by everything below it. The governance tools in this module are Azure Policy, tags and RBAC; the hierarchy decides where each one applies.

2 · "Same rules for every country" · Design for management groups

A management group holds subscriptions (and other management groups) so you can manage them as one. Use them to limit regions across subscriptions, grant access to many subscriptions with one role assignment, and audit roles and policies across subscriptions.

Facts to know:

• The tree can be six levels deep, not counting the root or the subscriptions.
• Each management group or subscription has one parent.
• New subscriptions land under the root by default. That's exactly how the CISO's "next year's subscriptions" would slip through; set a default management group.
• RBAC authorization for creating management groups is off by default; turn on hierarchy protection so not everyone can reshape the tree.

Design recommendations:

• Design with governance in mind: workloads that need the same security, compliance and connectivity rules share a management group.
• Keep it flat: three or four levels.
• A top-level management group (here: "Kestrel") for organisation-wide policies and roles.
• By department or by geography, when rules differ per department or region.
• A production management group for rules that apply to all production workloads.
• A sandbox management group for experiments, isolated from dev, test and production.
• Isolate sensitive data (like the corporate office's HR) in its own management group with enhanced policies.

3 · "Who's paying for all this?" · Design for subscriptions

A subscription is the container you create and pay for resources in. It's a billing boundary, a management boundary and a scale unit (each subscription has limits and quotas). Policies for an individual subscription can meet different compliance standards.

Considerations, applied to Kestrel:

• Treat subscriptions as a democratised unit of management, aligned to business needs: one per application and environment.
• Group them under management groups that carry the shared rules.
• A dedicated shared services subscription for the network (ExpressRoute, Virtual WAN, hub VNet), billed together and isolated from workloads.
• Scale limits: large specialised workloads (IoT, HPC, SAP) get their own subscription so they don't hit limits shared with others. That's Fleet.
• Administration: do these teams need different admins? Payroll does.
• Policy boundary: a workload with extra rules (PCI, or German HR data) can be isolated by a subscription rather than yet another management group.
• Network: a VNet can't span subscriptions; workloads that talk need peering or VPN.
• Owners' responsibilities: run access reviews quarterly or twice a year with Entra Privileged Identity Management.

4 · "Let me just delete the test stuff" · Design for resource groups

A resource group is the container you deploy resources into. You use it to group resources of similar usage, type or location; to organise by lifecycle; to apply roles; and to protect resources with locks.

Facts that matter in design:

• An RG has a region where its metadata is stored. If that region is down, you can't update its resources, though they keep running.
• Resources in an RG can be in other regions, and can connect to resources in other RGs.
• Resources can be moved between RGs (with some exceptions) and added or removed at any time.
• RGs can't be nested or renamed; each resource is in exactly one.

Strategies: by application (everything for one app, same policies and lifecycle; good for test and prototypes) or by type (all SQL in one RG, all web in another; for shared, on-demand services). Less common: by department, region or cost centre. Most designs combine them, then check: lifecycle, administration overhead (central or decentralised admins?), access control (policy, roles, locks at RG level) and compliance (must the metadata be in a particular region?).

5 · "Who owns this VM?" · Design for resource tags

Tags add metadata to resources as name-value pairs (env = production). You can put them on resources, resource groups and subscriptions, and add, change or remove them with the portal, CLI, PowerShell, ARM/Bicep or REST. Important: tags on a resource group aren't inherited by its resources.

Start with the goal (search, automation, cost?) and the organisation's own taxonomy. Then choose an alignment: IT-aligned tags (workload, function, environment) simplify operations; business-aligned tags (ownership, cost responsibility, criticality) show business value. Many organisations are moving towards business-aligned, usually mixed with a few IT tags.

Start small: prototype a few critical tags, see if they're used, then add more. Enforce with Azure Policy (require tags on creation, re-add removed ones). And not every resource needs every tag: if only critical resources get impact, the rest are by definition not critical. Ask stakeholders for input before you decide.

6 · "Make it impossible" · Design for Azure Policy

Azure Policy creates, assigns and manages rules over resource configurations. Know these:

• Individual policies and groups of them called initiatives; many are built in.
• Policies are inherited down the hierarchy and can be assigned at any level.
• They evaluate Azure resources and Arc-enabled resources outside Azure.
• They show non-compliant resources, prevent new ones, and remediate.
• They integrate with Azure Pipelines (pre- and post-deployment checks).

When does Policy evaluate? On create, update or delete of a resource in scope; on a new assignment; on an updated assignment; and in the standard 24-hour cycle. Expect a short delay before non-compliance shows.

What happens to a non-compliant resource is your choice: deny the change (Deny), log it (Audit), alter the resource (Modify, Append), or deploy a related compliant resource (DeployIfNotExists). The compliance dashboard shows the overall state with drill-down and bulk remediation.

Policy isn't RBAC. RBAC decides who may act; Policy decides what the result may look like, whoever acts. Even an Owner can't deploy a VM in Brazil if Policy denies it. Use both. In the bigger picture: a user gets access via RBAC, it's checked by Conditional Access, watched by Entra ID Protection, and confirmed by access reviews.

7 · "Everybody is Owner" · Design for RBAC

Azure RBAC evaluates each request and allows or blocks it. It's an allow model: you can do only what a role explicitly allows. Typical uses: one user manages VMs, another VNets; a DBA group manages all SQL databases; a user manages one resource group; an application accesses a resource group.

How to design it:

• Define roles → assign them to principals (users, groups, service principals) → scope them (MG, subscription, RG, resource). Assign at the highest scope that meets the requirement, no higher.
• Least privilege: limit roles and scopes, so a compromised account can do less damage. A scope-role matrix helps.
• Groups, not users: fewer assignments to manage.
• Custom roles when no built-in role fits; they can be shared between subscriptions that trust the same Entra tenant.
• Overlapping assignments add up: Contributor on the subscription + Reader on an RG = Contributor on that RG too.

8 · "Can we do this again next year?" · Design for landing zones

An Azure landing zone is the environment workloads land in, with the foundation in place before they arrive. Like a new neighbourhood where water, gas and electricity are connected before the houses go up: network, identity and access, policies and monitoring are ready first.

• Landing zones are management groups and subscriptions designed to scale.
• A platform landing zone (Identity, Connectivity, Management subscriptions, run centrally) plus application landing zones for workloads in dev, test and prod.
• Policies keep them compliant.
• They're pre-provisioned through code. The recommended way is the Azure landing zone IaC accelerator (Bicep or Terraform with Azure Verified Modules); a portal accelerator exists for teams without IaC skills.

Design considerations: include landing zones in the design; build them in code and expect to refactor (a central team reviewing short- and long-term scenarios limits that); use the accelerator; focus on applications rather than lifting VMs; prefer Azure-native services and follow the platform roadmap; scope for migrations and greenfield across the whole portfolio; and to transition an existing estate, deploy the accelerator into the same tenant in parallel with a new MG structure, then move subscriptions. An Azure landing zone review assessment helps check the result.

Kestrel's design, all together

Module assessment

Larkspur Health runs three hospitals in the Netherlands and one clinic in Belgium. Requirements:

• All patient data must stay in EU regions. The Belgian clinic has an extra national rule: its data must stay in Belgium Central.
• Finance wants costs per hospital and per application.
• Three applications: the patient portal (internet-facing), the internal HR system, and a research platform that needs large GPU quotas.
• Each application has dev and prod. Developers must be able to try new services without risk to production.
• A central platform team runs the network (ExpressRoute to the hospitals) and identity. Application teams must not change the network.
• Minimise administrative effort.

1. Task

   Design the management group hierarchy

   Draw the tree from the tenant root down to (but not including) subscriptions. Write next to each management group why it exists.

   Done when

   • The tree has at most 4 levels below the root.
   • Every management group has a governance reason (a policy or access rule that differs from its siblings).
   • There's a place for experiments that's isolated from production.
   Hint

   Start from the landing zone reference architecture (Platform, Landing zones, Sandbox, Decommissioned). Which requirement is different for the Belgian clinic?

   Model answer

   • Larkspur (top level): Allowed locations = EU regions; required tags; Defender for Cloud.
   • └ Platform: only the platform team has write access.
     └ Identity · Management · Connectivity.
   • └ Landing zones: deny changes to the hub network for app teams; diagnostics to the central workspace.
     └ Corp (internal: HR, research): deny public IPs.
     └ Online (patient portal): WAF in front of public endpoints.
   • └ Sandbox: no ExpressRoute connectivity, budget alerts, looser service list.
   • └ Decommissioned.

   The Belgian rule applies to the clinic's subscriptions (an extra Allowed locations assignment), not a separate geographic MG, since it's one rule for a few subscriptions. Splitting by hospital isn't needed: hospitals differ in cost, not in governance, and tags solve cost.

2. Task

   Decide subscriptions and resource groups

   List the subscriptions and, for one application, its resource groups. Give the "BASC" reason for each subscription.

   Done when

   • Dev and prod are separated.
   • The GPU-heavy research platform doesn't share quota with others.
   • The network has its own subscription.
   Model answer

   • sub-connectivity (Admins + Billing: ExpressRoute, hub VNet), sub-identity, sub-management (Log Analytics, automation).
   • sub-portal-prod, sub-portal-dev under Online (Compliance: internet-facing rules).
   • sub-hr-prod, sub-hr-dev under Corp.
   • sub-research-prod, sub-research-dev under Corp (Scale: GPU quota).
   • sub-sandbox-* per team under Sandbox.
   • For the patient portal (prod): rg-portal-web, rg-portal-data, rg-portal-monitor; grouped by lifecycle (data lives longer than the web tier).
3. Task

   Attach tags, policies and roles

   Make a table: requirement → control → scope, for every requirement in the scenario.

   Done when

   • Each requirement maps to Policy, RBAC, tags, or a structure choice.
   • Roles are assigned to groups, at the highest scope that fits.
   • Cost per hospital is possible even for shared resources.
   Model answer

   Requirement	Control	Scope
   EU only	Policy: Allowed locations (Deny)	Larkspur MG
   Belgium Central for the clinic	Policy: Allowed locations (Deny), narrower	Clinic subscriptions
   Cost per hospital and app	Tags hospital, app, env (accounting/functional); Policy: require on RG + inherit to resources	Landing zones MG
   App teams can't change the network	RBAC: Network Contributor only for the platform group; app groups get Contributor on their own subscriptions	Connectivity subscription / app subscriptions
   Safe experiments	Sandbox MG + budget alerts, no peering to hub	Sandbox MG
   Minimise effort	Landing zone accelerator in code; groups instead of users	Whole tenant