Chapter 2

Azure Architecture and Core Building Blocks

Microsoft Azure Fundamentals (AZ-900) Study GuideBased on the Microsoft AZ-900 exam objectives

Every cloud provider sells the same fantasy: you write code, it runs somewhere, you never think about hardware again. The reality is different. The hardware still exists — it sits in enormous concrete buildings with diesel generators out back — and if you want to pass the AZ-900, you need to understand how Microsoft organizes those buildings, what they promise about reliability, and how you manage everything inside them. This chapter is about the physical and logical skeleton of Azure: where your workloads physically run, how Microsoft structures management and permissions, and how you keep applications alive when things break. Because things break. Always plan for it.

Azure Global Infrastructure: The Physical Foundation

When you create a virtual machine in Azure, you are renting a slice of a physical server in a physical building. Microsoft operates more than 60 regions worldwide (the number keeps growing — check the current count, but the exact figure is not something the exam will nail you on). Each region is a set of datacenters deployed within a latency-defined perimeter and connected through a dedicated regional low-latency network.

Why does that matter? Because latency is physical. Light takes time to travel. If your users are in London and your application runs in Sydney, every request pays roughly 280 milliseconds just for the round trip — before your code does anything. Azure puts regions on every inhabited continent so you can park your workloads near your users.

Regions are not all identical. Microsoft classifies them loosely:

• General regions: available to everyone with an Azure subscription. Examples: East US, West Europe, Southeast Asia.
• Sovereign regions: built for specific governments or data-residency requirements. Azure Government (US federal agencies), Azure China (operated by 21Vianet under Chinese law), and Azure Germany (under EU data residency rules) fall here. These are physically and legally separated. You can't deploy to them unless your organization qualifies.

Why Sovereign Regions Exist: Data, Law, and Trust

It's worth pausing on why Microsoft builds entirely separate clouds for certain customers, because the exam tests the reasoning, not just the names.

Data is subject to the laws of the country where it physically sits. If a European company's customer database lives in a US datacenter, US law enforcement can potentially compel access to it — regardless of the company's European headquarters. This legal reality drives everything about sovereign clouds.

Azure Government serves US federal, state, and local agencies plus their contractors. It meets certifications like FedRAMP High, DoD IL5, and CJIS. Physically, it's separate datacenters operated by US citizens with security clearances. Logically, it's a separate Azure instance — you can't accidentally deploy a government workload to a public region, because the two environments don't share a management plane.

Azure China is operated by 21Vianet, a Chinese company, under Chinese law. This isn't a partnership detail — it's a legal necessity. Chinese regulations require data about Chinese citizens to be stored in China and operated by a Chinese entity. A multinational running factories in Shanghai keeps its Chinese operational data in Azure China, legally walled off from its global Azure footprint.

Azure Germany (and the broader EU Data Boundary initiative) addresses European data-protection law. After the Schrems II court ruling invalidated the EU-US Privacy Shield, European organizations became wary of any architecture where US authorities might access their data. Sovereign EU regions answer that concern structurally, not contractually.

Region Pairs: The 300-Mile Rule

Every Azure region is paired with exactly one other region. East US pairs with West US. West Europe pairs with North Europe. Japan East pairs with Japan West. This is called a region pair, and the pairing exists for one reason: disaster recovery.

The rules of region pairs are elegant:

1. Geographic separation. Paired regions are at least 300 miles apart, so a single regional disaster — hurricane, earthquake, grid failure — won't take out both.
2. Platform updates roll out sequentially. When Microsoft updates the Azure platform, it never updates both regions of a pair at the same time. One goes first, the other waits. This means a bad update can't brick your disaster recovery copy at the same moment it bricks your primary.
3. Data residency. Some services (like geo-replicated storage and SQL Database) use the region pair as their default replication target. Your data stays within the same geography — important for compliance.

Not every region has a pair (some newer regions are still waiting), and not every service uses the pair. But when a question involves disaster recovery and region selection, the pair is almost always the intended answer.

Availability Zones: Surviving a Datacenter Fire

Inside a region, Microsoft deploys availability zones: physically separate datacenters within the same region. Each zone has independent power, cooling, and networking. Think of them as three separate buildings, each able to run the whole show on its own.

Zones are connected by high-speed private fiber, so latency between them is tiny — typically under 2 milliseconds. From your application's perspective, zones behave like one region. But from a failure perspective, they're independent. If Zone 1 loses power, Zones 2 and 3 keep running.

The AZ-900 tests three availability concepts, and mixing them up is the single most common mistake in this domain. Here's the clean version:

Availability zones protect against datacenter-level failure. You deploy VM 1 in Zone 1, VM 2 in Zone 2, VM 3 in Zone 3. A fire in one building doesn't stop the other two. This gives you the highest SLA: 99.99% for VMs spread across zones.

Availability sets protect against rack-level failure inside a single datacenter. When you put VMs in an availability set, Azure spreads them across fault domains (separate power and network switches — so a rack power failure only kills one domain) and update domains (groups that get rebooted together during platform maintenance — so Microsoft never reboots all your VMs at once). Availability sets are the older mechanism, used in regions without zones or when you need VMs close together with very low latency.

Why not always use zones? Sometimes you need the absolute lowest latency between VMs — for example, a tightly coupled database cluster. Cross-zone latency is tiny but not zero. Availability sets keep VMs in the same building, minimizing latency at the cost of surviving only rack-level failures.

Fault Domains and Update Domains: A Closer Look

Availability sets deserve a deeper explanation because the exam tests the two domain types separately, and students routinely conflate them.

Imagine a datacenter hall with 50 server racks. Each rack has its own power feed and its own top-of-rack network switch. Microsoft divides these racks into fault domains — typically 2 or 3 per availability set. When you place four VMs in an availability set, Azure distributes them across fault domains: VM1 and VM3 on fault domain 0, VM2 and VM4 on fault domain 1, for example. Now suppose a power distribution unit fails and takes down every rack on fault domain 1. VM2 and VM4 go dark — but VM1 and VM3 keep serving traffic. The application survives because a single hardware failure can only ever kill one fault domain.

Update domains solve a different problem: Microsoft's own maintenance. The Azure platform needs periodic updates — host OS patches, firmware upgrades, security fixes. These require rebooting the physical servers. If Microsoft rebooted every host simultaneously, every VM in the datacenter would go down at once. Instead, hosts are grouped into update domains (up to 20 per availability set). Maintenance proceeds one update domain at a time: Microsoft patches and reboots the hosts in update domain 0, waits for them to come back healthy, then moves to update domain 1. Your VMs, spread across update domains, are never all rebooting at the same moment.

Notice the symmetry: fault domains protect against unplanned hardware failures; update domains protect against planned maintenance. Together, they're why an availability set delivers 99.95% SLA instead of 99.9%.

One more nuance: availability zones are not available in every region. Older or smaller regions may only support availability sets. The exam won't ask you to name which regions have zones, but it might present a scenario where zones aren't an option and availability sets are the answer.

The Datacenter Itself: What's Inside

Microsoft doesn't publish the full blueprint, but the AZ-900 expects you to know the general picture. Azure datacenters are massive facilities — some span more than a million square feet. They contain tens of thousands of servers organized into racks, rows, and halls. The supporting infrastructure is as important as the servers:

• Power: multiple utility feeds plus on-site diesel generators and battery banks (UPS) that bridge the gap if the grid drops.
• Cooling: evaporative and adiabatic cooling systems — datacenters are among the largest water and electricity consumers in their regions, which is why Microsoft invests heavily in renewable energy and water-positive designs.
• Networking: redundant fiber connections to other datacenters in the region and to Microsoft's global backbone — a private fiber network spanning the planet, which is why traffic between Azure regions never touches the public internet.

The Management Hierarchy: Organizing Everything

Now we move from the physical to the logical. Azure lets you create thousands of resources — virtual machines, databases, storage accounts, virtual networks. Without organization, this becomes chaos: nobody knows who owns what, which bill pays for what, or which policies apply where. Microsoft's answer is a four-level management hierarchy. It nests like Russian dolls:

Management groups → Subscriptions → Resource groups → Resources

Each level inherits from the one above it. Policies and access controls flow downward. Let's walk through each level from the top.

Management Groups: The Enterprise View

Management groups are the highest level. They exist for one reason: large organizations with many subscriptions need to apply governance — policies, access control, compliance rules — across all of them at once.

A management group can contain subscriptions and other management groups (nesting up to six levels deep, though three is typical). Whatever policy you assign at the management group level automatically applies to everything beneath it. Change it once at the top, and hundreds of subscriptions comply instantly.

Here's a concrete example. Contoso Corporation has separate subscriptions for Finance, HR, and Engineering. The CISO wants every resource in the company to require encryption. Instead of configuring this 300 times, she assigns an encryption policy at the root management group. Done. Every subscription, every resource group, every resource inherits it.

Subscriptions: The Billing and Access Boundary

A subscription is the unit of billing and the primary access boundary. Every Azure resource lives in exactly one subscription. When Microsoft sends a bill, it's per subscription. When you set spending limits or budgets, they're per subscription.

Subscriptions also define trust boundaries. Access granted in one subscription doesn't automatically extend to another. This is why organizations split subscriptions by department, project, or environment (dev, test, production). If the dev team's experiments go haywire and burn through their budget, production is unaffected — separate subscriptions, separate bills, separate blast radius.

Common subscription patterns:

• By department: Finance, Marketing, Engineering each get their own.
• By environment: Dev, Test, and Production are isolated so a developer's mistake can't take down the live system.
• By project: a temporary project gets its own subscription that can be deleted cleanly when the project ends.

Subscription Limits and Quotas: The Guardrails

Every subscription comes with default limits and quotas — maximum numbers of VMs, storage accounts, virtual networks, and so on. These aren't there to annoy you; they're guardrails. A compromised account or a runaway script could otherwise spin up 10,000 VMs in minutes and generate a catastrophic bill. Quotas cap the blast radius.

Quotas are soft limits — you can request increases through support — but the exam wants you to know they exist and why. If a deployment fails with a quota error, the fix is requesting a quota increase, not creating a new subscription (though some organizations do isolate workloads that way).

Subscriptions also come in types that affect what's available. The common ones: Free Trial (limited credit, 30 days), Pay-As-You-Go (the standard), Enterprise Agreement (large organizations with negotiated pricing), and Student (free credit for verified students). The exam occasionally asks which subscription type suits a scenario — a student learning Azure gets the Student subscription; a large company gets an Enterprise Agreement.

Resource Groups: The Lifecycle Container

A resource group is a logical container for resources that share a lifecycle. The classic example: a web application consists of a virtual machine, a database, a virtual network, and a storage account. These four resources are different types, but they live and die together. Put them in one resource group called webapp-prod-rg, and you can deploy, manage, monitor, and — critically — delete them as a unit.

Deleting a resource group deletes everything in it. This is the single most useful cleanup feature in Azure. Spin up 40 resources for a test, delete the resource group, and all 40 vanish. No orphaned disks haunting your bill for six months.

Key rules about resource groups:

1. Every resource must be in exactly one resource group. No exceptions. You cannot create a resource without assigning it to a group.
2. Resources in a group can span regions. A resource group in East US can contain a VM in West Europe. The group's location only determines where the group's metadata is stored — not where the resources physically run.
3. Resources can move between groups (with some limitations), but the group itself is just a logical boundary. It doesn't provide network isolation or security boundaries by itself.

Resources: The Actual Things

At the bottom of the hierarchy sit resources — the actual services you consume. Virtual machines, storage accounts, SQL databases, virtual networks, app services. Every resource has a unique resource ID, a long path that encodes its full position in the hierarchy:

/subscriptions/{subscription-id}/resourceGroups/{rg-name}/providers/Microsoft.Compute/virtualMachines/{vm-name}

This ID tells you everything: which subscription, which resource group, which provider, which resource. Azure uses these IDs internally for access control, policy evaluation, and billing. You'll rarely type one by hand, but understanding the structure explains why the hierarchy matters — it's literally encoded into every resource's identity.

Azure Resource Manager: The Control Plane

Every time you create, update, or delete anything in Azure — whether through the portal, the command line, PowerShell, or an API — your request goes through Azure Resource Manager (ARM). ARM is the deployment and management layer for Azure. Think of it as air traffic control: every takeoff and landing goes through the tower, no exceptions.

ARM does several jobs at once:

Consistent management layer. Before ARM, Azure had a "classic" deployment model where each service had its own API and its own quirks. ARM unified everything. One API, one authentication model, one way to check "did this deploy succeed?" Whether you're creating a VM or a database, the request flows through ARM.

Access control. ARM is where role-based access control (RBAC) is enforced. When you try to delete a VM, ARM checks: does this user have permission? At what scope — the resource, the resource group, the subscription, the management group? Permissions granted at a higher scope flow down (a subscription-level admin can manage everything in every resource group beneath it).

RBAC scopes deserve a moment because they mirror the management hierarchy exactly — and the exam exploits that symmetry. A role assignment always has three parts: who (the security principal — a user, group, or service), what they can do (the role — Owner, Contributor, Reader, or a custom role), and where (the scope). Assign the Contributor role to a developer at the resource-group scope, and she can manage everything in that group but nothing outside it. Assign Reader at the subscription scope, and he can view everything in the subscription but change nothing.

The inheritance rule is simple and absolute: permissions flow downward, never upward. A subscription-level Owner controls every resource group and resource beneath that subscription — but has zero access to a neighboring subscription. This is why scope selection is a security decision: grant the narrowest scope that lets someone do their job. The exam's RBAC questions almost always hinge on scope — "a user needs to manage VMs in one resource group but must not see other groups" points to a role assignment at the resource-group scope.

Policy enforcement. ARM is where Azure Policy runs. Policies are rules like "all storage accounts must use private endpoints" or "no VMs larger than D4s_v3." When you try to create a resource that violates a policy, ARM blocks it — or flags it as non-compliant, depending on the policy's effect.

Tagging. ARM lets you attach tags — name/value pairs like Environment: Production or CostCenter: Finance — to resources and resource groups. Tags flow into billing reports, so you can slice costs by department, project, or environment even within a single subscription.

Good tagging discipline is one of those things that separates mature cloud operations from chaos. Consider a subscription shared by three project teams. Without tags, the monthly bill is a single inscrutable number. With consistent tags — every resource tagged Project: Atlas, Project: Beacon, or Project: Citadel — the finance team can allocate costs precisely. Tags also drive automation: a script can find every resource tagged Environment: Dev and shut them down at 7 PM to save money, or find everything tagged PatchWindow: Sunday and schedule updates accordingly. The exam treats tags primarily as a cost-organization tool, but understanding their operational uses deepens your grasp of why they matter.

Template-based deployment. This is ARM's most powerful feature for the AZ-900: infrastructure as code. Instead of clicking through the portal 50 times, you describe your infrastructure in a file, and ARM deploys it.

ARM Templates and Bicep: Infrastructure as Code

ARM templates are JSON files that describe what you want to deploy: the resources, their configurations, their dependencies, and their parameters. You write the template once, then deploy it to any environment. ARM reads the template and creates everything in the correct order — it figures out that the virtual network must exist before the VM that connects to it.

Here's what a tiny fragment looks like conceptually:

{
  "resources": [
    { "type": "Microsoft.Storage/storageAccounts", "name": "mystorageacct" },
    { "type": "Microsoft.Compute/virtualMachines", "name": "myvm",
      "dependsOn": ["mystorageacct"] }
  ]
}

The key concept is declarative: you describe the desired end state, not the steps to get there. You say "I want a VM and a storage account," and ARM works out the how. Run the same template twice, and the second run changes nothing — the infrastructure already matches the description. This property is called idempotency, and it's what makes templates safe to reuse.

Bicep is Microsoft's newer, simpler language for the same job. It compiles down to ARM templates but reads like actual code instead of verbose JSON. The exam only expects you to know that Bicep exists as a simpler alternative to ARM templates — you won't write any.

Locks: Preventing Accidents

One more ARM feature worth knowing: resource locks. A delete lock (CanNotDelete) prevents anyone from deleting a resource, even an administrator — you must remove the lock first. A read-only lock (ReadOnly) prevents any modification. Organizations put delete locks on production databases so nobody accidentally wipes them during a late-night cleanup.

Putting It Together: A Real-World Scenario

Let's tie the whole chapter together with a scenario the exam might dress up as a case study.

Fabrikam Industries is moving to Azure. They have three departments (Sales, Manufacturing, R&D), operate in the US and Europe, and run a critical order-processing application that cannot go down.

Here's how the architecture maps:

1. Regions: They deploy to East US (near US customers) and West Europe (near European customers). Each region's data stays in its geography for compliance.
2. Region pairs: East US pairs with West US; West Europe pairs with North Europe. The order-processing database is geo-replicated to the paired region for disaster recovery.
3. Availability zones: The order-processing VMs are spread across three zones in East US, giving 99.99% SLA. A datacenter fire doesn't stop orders.
4. Management groups: A root management group enforces company-wide policies — encryption required, no public storage accounts.
5. Subscriptions: Separate subscriptions for Sales, Manufacturing, and R&D — separate bills, separate access, separate blast radius. Production and development are in different subscriptions.
6. Resource groups: The order-processing app's VM, database, network, and storage live in orders-prod-rg. When they build a test copy, it goes in orders-test-rg, which can be deleted in one click.
7. ARM templates: The entire order-processing infrastructure is defined in a Bicep file. Dev, test, and production are deployed from the same template — no configuration drift.
8. Locks: The production database has a delete lock. Nobody wipes it by accident.

Every concept in this chapter appears in this one scenario. That's not a coincidence — the exam's case studies work the same way, layering multiple concepts into a single story. When you read a scenario question, map each requirement to a layer: geography → regions/pairs, reliability → zones/sets, governance → management groups/policy, billing → subscriptions, lifecycle → resource groups, consistency → templates.

Chapter Summary

• Regions are geographic areas containing datacenters; choose them based on user proximity and compliance needs. Some regions (Government, China) are restricted.
• Region pairs (at least 300 miles apart, sequential platform updates, data residency) are the foundation of disaster recovery planning.
• Availability zones protect against datacenter failure (99.99% SLA for VMs); availability sets protect against rack failure via fault domains and maintenance reboots via update domains (99.95% SLA).
• The management hierarchy nests as management groups → subscriptions → resource groups → resources, with policies and permissions flowing downward.
• Subscriptions are the billing and access boundary; resource groups are lifecycle containers (deleting the group deletes everything in it); resources can span regions regardless of their group's location.
• Azure Resource Manager (ARM) is the unified control plane: consistent API, RBAC enforcement, policy evaluation, tagging, and template deployment.
• ARM templates (JSON) and Bicep (simpler syntax) enable declarative infrastructure as code — describe the desired state, deploy repeatably.
• Resource locks (delete and read-only) prevent accidental changes to critical resources.

End-of-Chapter Test

1. A company needs to deploy virtual machines that remain available even if an entire Azure datacenter loses power. Which availability option should they choose? A. Availability sets B. Availability zones C. Region pairs D. Fault domains alone

2. Every Azure region is paired with another region. Which of the following is NOT a property of region pairs? A. Paired regions are at least 300 miles apart B. Platform updates are applied to both regions simultaneously C. Data residency is maintained within the same geography for certain services D. Each region is paired with exactly one other region

3. Contoso has 40 Azure subscriptions and needs to enforce a policy requiring encryption on all storage accounts across every subscription. What should Contoso use? A. Apply the policy to each resource group individually B. Create a management group containing all subscriptions and assign the policy there C. Create a new subscription with the policy and move all resources into it D. Use Azure Resource Manager locks on each storage account

4. A developer creates 60 resources for testing and wants to remove all of them quickly when testing is complete. What is the most efficient approach? A. Delete each resource individually through the Azure portal B. Delete the resource group containing the resources C. Remove the subscription D. Apply a read-only lock and wait for automatic cleanup

5. An administrator accidentally deleted a production SQL database. Which Azure feature would have prevented this deletion? A. Azure Policy B. A delete lock (CanNotDelete) on the database C. An availability zone deployment D. A backup policy

6. A resource group is created in the East US region. Which statement is true? A. All resources in the group must be deployed in East US B. Resources in the group can be deployed in any region; the group's location only determines where its metadata is stored C. The resource group cannot contain resources from other subscriptions D. The resource group automatically replicates its resources to the paired region

7. A company wants to deploy the same infrastructure — virtual network, VMs, and database — identically to development, test, and production environments. Which approach best achieves this? A. Manually recreate the resources in each environment through the portal B. Use an ARM template or Bicep file to declaratively define and deploy the infrastructure C. Copy the resource group between subscriptions D. Use availability sets across the three environments

8. Which SLA applies to virtual machines deployed across availability zones? A. 99.9% B. 99.95% C. 99.99% D. 99.999%

9. A company wants separate monthly invoices for its Finance, HR, and Engineering departments' Azure usage. What should it implement? A. Separate resource groups for each department B. Separate subscriptions for each department C. Separate management groups for each department D. Separate tags for each department without changing the subscription structure

10. All requests to create, update, or delete Azure resources flow through which service? A. Azure Active Directory B. Azure Resource Manager (ARM) C. Azure Policy D. Azure Monitor

---

Answer Key

1. B — Availability zones are physically separate datacenters within a region; spreading VMs across zones protects against datacenter-level failure. Availability sets only protect against rack-level failure.
2. B — Platform updates are applied sequentially, never simultaneously, so a bad update cannot affect both regions of a pair at once.
3. B — Management groups allow policies to be applied once across many subscriptions; everything beneath inherits them.
4. B — Deleting a resource group deletes all resources inside it, making it the fastest cleanup method.
5. B — A CanNotDelete lock prevents deletion (even by administrators) until the lock is removed. Backups aid recovery but don't prevent deletion.
6. B — The resource group location controls only metadata storage; resources within it may live in any region.
7. B — ARM templates/Bicep provide declarative infrastructure as code: define the desired state once, deploy it repeatably to any environment.
8. C — VMs across availability zones carry a 99.99% SLA (sets: 99.95%; single VM with premium storage: 99.9%).
9. B — The subscription is the billing boundary; separate subscriptions produce separate invoices. Tags help analyze costs but don't split billing.
10. B — Azure Resource Manager is the unified deployment and management layer through which all resource operations flow.