Chapter 11 · AZ-305 bridge

The Microsoft Cloud Adoption Framework

Chapters 1 to 10 were about building things right. The last two chapters are about building the right things, the way an architect thinks. The Cloud Adoption Framework (CAF) is Microsoft's guidance for taking a whole organisation to the cloud: why, in what order, with which people, and on which foundation. In the lab you build an Azure landing zone-style management group hierarchy and put guardrails on it.

What CAF is

The Cloud Adoption Framework is a collection of documentation, best practices, templates and tools from Microsoft, based on what worked (and failed) at thousands of customers. It isn't a product you deploy and it doesn't cost anything. Think of it as a playbook with answers to questions like:

• Why are we moving to the cloud, and how do we know it worked?
• Which workloads go first, and what do we do with each one?
• Who does what: which teams and skills do we need?
• What foundation (subscriptions, network, identity, policies) must exist before the first workload lands?
• How do we stay secure, compliant and in budget once we're running?

CAF works at the level of the organisation and its whole cloud estate. The Well-Architected Framework (chapter 12) works at the level of one workload. You need both: CAF builds the city, WAF designs each building.

The CAF lifecycle

CAF is organised into methodologies. Four of them follow each other as you start; three run continuously next to everything else:

Strategy: why are we doing this?

Many cloud projects fail not on technology but because nobody agreed on why they were doing it. The Strategy methodology makes this explicit:

• Motivations: what triggers the move. Often a critical business event: a datacenter lease ending, end of support for hardware or software, a merger, a compliance requirement. Other motivations are about innovation: new products, AI, faster releases, global reach.
• Business outcomes: the measurable results the business expects, with KPIs. For example: "cut infrastructure costs by 20% in two years" (fiscal), "release new features weekly instead of quarterly" (agility), "serve customers in Asia with <100 ms latency" (reach), "99.95% availability for the web shop" (performance).
• Business case: costs vs. expected returns. Azure Migrate's business case and the TCO calculator help here.
• First project: pick a workload that's low risk and visible, to learn and to show early success.

Plan: what moves, how, and who does it?

The digital estate and the 5 Rs

The digital estate is your inventory of everything you run: servers, apps, databases, data. You collect it (for example with Azure Migrate discovery, chapter 7) and then decide for each workload what to do with it. This is called rationalisation, and CAF uses the "5 Rs" plus two extra options:

The further down the table, the more effort, but also the more cloud benefit (less to manage, better scaling). A datacenter exit with a hard deadline usually means mostly rehost first, and modernise later.

People and skills

Technology is the easy part. CAF's Plan methodology also covers:

• A skills readiness plan: who needs which training (a guide like this one is part of it).
• A cloud adoption plan: the backlog of workloads, in waves, often tracked in Azure DevOps (CAF provides a template).
• Teams and roles. Typical ones: a cloud strategy team (business and IT leaders), a cloud adoption team (does the migrations), a cloud platform team (builds and runs the landing zones), a cloud governance team and a security team. In mature organisations a Cloud Center of Excellence (CCoE) brings these together and spreads best practices.

Ready: Azure landing zones

Before the first workload moves, you need a prepared environment with identity, networking, policies, monitoring and subscriptions in place. CAF calls this an Azure landing zone. The idea: the platform is built once by a central team, and every workload "lands" in a subscription that's already governed and connected.

• Platform landing zones: subscriptions with shared services that every workload uses: identity (e.g. domain controllers), management (central Log Analytics, automation), connectivity (the hub VNet, firewall, VPN/ExpressRoute gateways, DNS).
• Application landing zones: one or more subscriptions per workload, created from a template (subscription vending), peered to the hub and covered by inherited policies.

You built a small version of this in this guide: vnet-hub with shared DNS was a platform piece, vnet-spoke was the workload's network.

The management group hierarchy

The Azure landing zone reference architecture organises subscriptions in a management group hierarchy that follows what kind of workload runs there, not the org chart. Policies and RBAC are assigned at the management groups, so every subscription inherits them (chapter 2):

• Intermediate root: never assign at the Tenant Root Group directly; use your own top group so you can test changes and keep control.
• Corp: internal apps, connected to the hub, typically deny public IPs and require private endpoints.
• Online: internet-facing apps, public endpoints allowed but behind a WAF.
• Sandbox: for learning and experiments, not connected to the corporate network, often with budgets.
• Decommissioned: subscriptions on their way out, with policies that block new resources.

Design areas and how to deploy

CAF describes the decisions behind a landing zone in eight design areas. You already know most of them from this guide:

You don't have to build all of this by hand. Microsoft provides landing zone accelerators: a portal-based deployment, and Bicep and Terraform modules (based on Azure Verified Modules). Small organisations can start small and expand; large ones usually deploy the full reference architecture from day one.

Adopt: migrate and innovate

Adopt is where workloads actually move or get built:

• Migrate: move workloads in waves, each following assess → deploy → release. Tools: Azure Migrate, Database Migration Service and Data Box (chapter 7). Most early waves are rehost.
• Modernize: refactor and rearchitect migrated workloads to PaaS to get more cloud value.
• Innovate (cloud-native): build new solutions with cloud services, for example AI, analytics and serverless (chapter 8).

Govern, Secure and Manage

These three run all the time, across the whole estate:

• Govern: a governance team identifies risks (data leaving the EU, runaway costs, untagged resources), writes policies ("all resources must be in EU regions"), enforces them with Azure Policy, RBAC, budgets and tags (chapter 2), and monitors compliance. The aim is guardrails that keep teams safe without slowing them down.
• Secure: applies Zero Trust and defense in depth (chapter 6) to the estate: security roles, posture management with Defender for Cloud, incident response, and keeping the business running during attacks.
• Manage: run the cloud day to day. Set an operations baseline for everything (monitoring, patching, backup), then add more for critical workloads based on their criticality and the business commitments (SLAs, RTO, RPO). Tools: Azure Monitor (chapter 9), Azure Update Manager, Backup and Site Recovery (chapter 10).

Naming and tagging conventions

A small but very practical part of CAF (and part of the Ready methodology): agree on names and tags before you create anything, because most Azure resources can't be renamed.

CAF recommends a name built from components, for example:

<resource type>-<workload>-<environment>-<region>-<instance>
vm-sqlshop-prod-weu-001      rg-webshop-dev-weu      vnet-hub-prod-weu-001

• The type prefix uses CAF's abbreviations list: rg, vnet, snet, vm, nsg, pip, lbe / lbi, kv, log, st… This guide used them from chapter 2 on.
• Some resources have stricter rules: storage accounts allow only lowercase letters and digits (3–24) and must be globally unique, which is why yours was called staz104xx01 without dashes.

Tags (chapter 2) carry information that doesn't fit in a name. CAF's common minimum set: workload/application name, owner, environment, cost center or business unit, criticality and data classification. Enforce the important ones with Azure Policy ("Require a tag on resource groups", "Inherit a tag from the resource group").

Self-check

You play the cloud architect for a fictional company, Fabrikam Logistics: first on paper (strategy, rationalisation, naming), then in Azure (a landing zone management group hierarchy with policies). Everything you create in Azure is free, and the last step removes it.

The variables from chapter 0 ($RG, $LOC, $LOC2, $INIT, $ST, $ACR, $MYIP) load automatically in every terminal; if they don't, run . ~/az104.env. Any other variable a task needs is set at the top of that task's Azure CLI solution, so every solution works on its own in a fresh terminal.

1. Task · on paper

   Write Fabrikam's cloud strategy on one page

   Write down:

   • the motivation (what's triggering the move);
   • two business outcomes, each with a measurable KPI;
   • which of the four apps you'd move first, and why.
   Done when

   • Each outcome has a number and a deadline in it.
   • Your first workload is low risk and its success is visible.
   Example answer

   • Motivation: a critical business event, the datacenter lease ending in 14 months. Secondary: innovation for the customer portal.
   • Outcome 1 (fiscal): hosting costs at least 20% lower than the current datacenter contract within 24 months.
   • Outcome 2 (agility): TrackIt releases go from quarterly to every two weeks within 12 months of moving.
   • First workload: TrackIt. In-house code (you control it), customer-visible (a quick win to show), and a good learning case for PaaS. Retiring ReportBox is an even easier first "win", but it doesn't teach the team anything about Azure.
2. Task · on paper

   Rationalise the four applications

   Choose one R (rehost, refactor, rearchitect, rebuild, replace, retire or retain) for each application, with one sentence of reasoning, and name the Azure service or tool you'd use.

   Done when

   • All four apps have an R, a reason and a target.
   Example answer

   App	R	Why and how
   TrackIt	Refactor	In-house ASP.NET code can move to App Service with small changes (App Service migration assistant); slots make frequent releases easy, which serves outcome 2.
   FleetDB	Rehost	Vendor software tied to Windows Server: move the VM with Azure Migrate server migration. Revisit when the vendor offers something better.
   HR-Pay	Replace	The vendor's SaaS removes servers, patching and upgrades entirely.
   ReportBox	Retire	Unused for 18 months. Archive its data to a storage account (Archive tier, chapter 7), then switch it off.

3. Task · on paper

   Agree on names and tags

   Using CAF's naming pattern and abbreviations, write the names for TrackIt's production resources in West Europe: its resource group, App Service plan, web app, key vault and storage account. Then list the tags every TrackIt resource group must carry.

   Done when

   • Every name follows one pattern, and the storage account name is valid.
   • You have at least four tags, including an owner.
   Hint

   Look up the abbreviations for App Service plan, web app, key vault and storage account in the CAF abbreviations list (linked under "Read more").

   Example answer

   rg-trackit-prod-weu-001
   asp-trackit-prod-weu-001
   app-trackit-prod-weu-001
   kv-trackit-prod-weu-001        (max 24 characters, globally unique)
   sttrackitprodweu001            (lowercase letters and digits only, globally unique)

   Tags: workload=trackit, env=prod, owner=<team or person>, costcenter=<code>, criticality=high, dataclass=confidential.

4. Task

   Build the landing zone management groups

   Create this management group hierarchy under the Tenant Root Group (IDs and display names may be the same):

   mg-az104                     (intermediate root)
   ├── mg-az104-platform
   │   ├── mg-az104-identity
   │   ├── mg-az104-management
   │   └── mg-az104-connectivity
   ├── mg-az104-landingzones
   │   ├── mg-az104-corp
   │   └── mg-az104-online
   ├── mg-az104-sandbox
   └── mg-az104-decommissioned

   Done when

   • Management groups in the portal shows the tree exactly like this.
   • You can say which of Fabrikam's four apps (after your rationalisation) would get a subscription under which group.
   Hint

   Create parents before children. In the CLI, --parent takes the parent's ID. New groups can take a minute to appear in the portal tree.

   Solution · Portal

   1. Management groups → Create: ID mg-az104, display name mg-az104. It's created under the Tenant Root Group.
   2. Open mg-az104 → Create (inside it): mg-az104-platform, mg-az104-landingzones, mg-az104-sandbox, mg-az104-decommissioned.
   3. Open mg-az104-platform → create the three platform children; open mg-az104-landingzones → create mg-az104-corp and mg-az104-online.

   Mapping: TrackIt production → Online (customer-facing); FleetDB → Corp (internal); HR-Pay and ReportBox → no subscription (SaaS and retired).

   Solution · Azure CLI

   az account management-group create -n mg-az104 --display-name mg-az104
   for C in platform landingzones sandbox decommissioned; do
     az account management-group create -n mg-az104-$C --display-name mg-az104-$C --parent mg-az104
   done
   for C in identity management connectivity; do
     az account management-group create -n mg-az104-$C --display-name mg-az104-$C --parent mg-az104-platform
   done
   for C in corp online; do
     az account management-group create -n mg-az104-$C --display-name mg-az104-$C --parent mg-az104-landingzones
   done
   az account management-group show -n mg-az104 --expand --recurse \
     --query "{root:name, children:children[].{name:name, children:children[].name}}" -o json

5. Task

   Put guardrails at the right level

   Assign three built-in policies, each at the highest management group where it should apply and no higher:

   • Allowed locations: only your two lab regions, for everything Fabrikam owns.
   • Require a tag on resource groups: tag owner, for all workload subscriptions (not platform, not sandbox).
   • Not allowed resource types: block Microsoft.Network/publicIPAddresses for internal workloads only.
   Done when

   • Three assignments exist, on mg-az104, mg-az104-landingzones and mg-az104-corp.
   • Opening Policy → Assignments with scope mg-az104-corp shows all three (two inherited). Why?
   Hint

   Assignment names at management group scope can be at most 24 characters. Built-in definition IDs: Allowed locations e56962a6-4747-49cd-b67b-bf8b01975c4c, Require a tag on resource groups 96670d01-0a4d-4649-9c89-2d3abc0a5025, Not allowed resource types 6c112d4e-5bc7-47ae-a041-ea2d9dccd749.

   Solution · Portal

   1. Policy → Assignments → Assign policy. Scope: management group mg-az104. Definition Allowed locations, name allowed-locations; Parameters: your two regions. Create.
   2. Again, scope mg-az104-landingzones, definition Require a tag on resource groups, name require-owner-tag, tag name owner.
   3. Again, scope mg-az104-corp, definition Not allowed resource types, name deny-public-ip, type Microsoft.Network/publicIPAddresses.
   4. Assignments, scope filter mg-az104-corp: you see all three, because assignments inherit down the hierarchy (chapter 2).
   Solution · Azure CLI

   # Variables for this task
   MG=/providers/Microsoft.Management/managementGroups
   
   az policy assignment create -n allowed-locations --scope $MG/mg-az104 \
     --policy e56962a6-4747-49cd-b67b-bf8b01975c4c \
     --params "{\"listOfAllowedLocations\":{\"value\":[\"$LOC\",\"$LOC2\"]}}"
   az policy assignment create -n require-owner-tag --scope $MG/mg-az104-landingzones \
     --policy 96670d01-0a4d-4649-9c89-2d3abc0a5025 --params '{"tagName":{"value":"owner"}}'
   az policy assignment create -n deny-public-ip --scope $MG/mg-az104-corp \
     --policy 6c112d4e-5bc7-47ae-a041-ea2d9dccd749 \
     --params '{"listOfResourceTypesNotAllowed":{"value":["Microsoft.Network/publicIPAddresses"]}}'
   az policy assignment list --scope $MG/mg-az104-corp --disable-scope-strict-match \
     --query "[].{name:name, scope:scope}" -o table

6. Task · optional, lab subscription only

   Land a subscription in Corp and test the guardrails

   Move your lab subscription into mg-az104-corp. Then try to create a resource group without an owner tag, then one with it, and in that group a public IP. Afterwards, move the subscription back to the Tenant Root Group.

   Done when

   • The untagged resource group and the public IP were both refused with RequestDisallowedByPolicy, and you know which assignment blocked each.
   • The subscription is back under the Tenant Root Group and the test group is deleted.
   Hint

   Policy can take up to 30 minutes to take effect after a move. If the first attempt succeeds, delete what you made and try again later. Don't do this with a subscription that other people use.

   Solution · Azure CLI

   # Variables for this task
   MG=/providers/Microsoft.Management/managementGroups
   SUB=$(az account show --query id -o tsv)
   TENANT=$(az account show --query tenantId -o tsv)
   
   az account management-group subscription add -n mg-az104-corp --subscription $SUB
   # wait a few minutes, then:
   az group create -n rg-caf-test -l $LOC                        # refused: require-owner-tag
   az group create -n rg-caf-test -l $LOC --tags owner=$INIT     # allowed
   az network public-ip create -g rg-caf-test -n pip-caf-test --sku Standard   # refused: deny-public-ip
   
   az group delete -n rg-caf-test --yes
   az account management-group subscription add -n $TENANT --subscription $SUB   # back to the root

   The Tenant Root Group's ID is your tenant ID, which is why $TENANT works as a management group name.

7. Task

   Clean up

   Remove the three policy assignments and all ten management groups. Make sure your subscription isn't under any of them.

   Done when

   • az account management-group list --query "[?starts_with(name,'mg-az104')].name" -o tsv returns nothing (or only mg-az104-lab from chapter 2, if you kept it).
   Hint

   A management group can only be deleted when it has no children: delete from the leaves up.

   Solution · Azure CLI

   # Variables for this task
   MG=/providers/Microsoft.Management/managementGroups
   
   az policy assignment delete -n deny-public-ip --scope $MG/mg-az104-corp
   az policy assignment delete -n require-owner-tag --scope $MG/mg-az104-landingzones
   az policy assignment delete -n allowed-locations --scope $MG/mg-az104
   for C in identity management connectivity corp online; do az account management-group delete -n mg-az104-$C; done
   for C in platform landingzones sandbox decommissioned; do az account management-group delete -n mg-az104-$C; done
   az account management-group delete -n mg-az104