Microsoft AZ-900: Azure Architecture & Global Infrastructure — Study Guide
Part of the Microsoft Azure AZ-900 — Study Guide. Practice with verified answers in the Microsoft exam hub, or take timed practice tests on ExamRoll.io.
Azure’s global architecture is designed to deliver resilient, performant, and compliant cloud services at scale. Understanding the physical layout of geographies, regions, and availability zones, along with the logical hierarchy of management groups, subscriptions, resource groups, and resources, underpins reliable design and governance. The control plane provided by Azure Resource Manager, combined with declarative templates, enables consistent, repeatable deployments that align with organizational policy and security requirements. Design decisions in this domain directly influence availability targets, data residency obligations, and user experience worldwide. Selecting the right redundancy model, calculating composite SLAs, and choosing global routing services such as Azure Front Door, Traffic Manager, and Azure CDN are core to meeting business continuity, compliance, and performance goals.
Geographies, Regions, Availability Zones, and Region Pairs
Azure geographies are defined sets of regions that preserve data residency and compliance boundaries. Examples include United States, Europe, United Kingdom, Australia, and Canada, as well as sovereign clouds with distinct compliance and connectivity models. Workloads that must remain within a given jurisdiction should be deployed into regions that belong to the target geography to ensure regulatory alignment and data residency. A region is a set of datacenters deployed within a latency-defined perimeter and connected through a dedicated, low-latency network. Not all services or features are available in every region, so capacity and feature availability should be validated early in planning. Regions that support Availability Zones provide three or more physically separate datacenter zones with independent power, cooling, and networking. Zone-redundant services (ZRS) and architecting across zones protect against datacenter-level failures while maintaining low-latency access within the region. Every Azure region is paired with another region within the same geography to form a region pair (for example, North Europe with West Europe, East US with West US). Region pairs enable prioritized recovery during broad outages, staggered platform updates, and data replication for certain services. Azure Storage’s geo-redundant options (GRS/GZRS) replicate data asynchronously to the paired region; when read access to the secondary is required, use RA-GRS or RA-GZRS to allow reads from the secondary endpoint during an outage or planned failover. For mission-critical workloads requiring both in-region high availability and cross-region disaster recovery, combine zone redundancy with region pair replication. Balancing latency, resiliency, and compliance leads to a common pattern: deploy active workloads across zones in a primary region and protect against regional disasters by replicating data and providing failover paths to the paired region. Validate failover runbooks and DNS or front-end routing behavior regularly to ensure recovery objectives are met.
- Geography
- Scope: Multi-region boundary
- Key Benefit: Data residency and compliance
- Typical Use: Regulatory alignment (e.g., EU data)
- Region
- Scope: Single metropolitan area
- Key Benefit: Low-latency access to services
- Typical Use: Primary deployment location
- Availability Zone
- Scope: Distinct datacenters within a region
- Key Benefit: Datacenter-level fault isolation
- Typical Use: In-region high availability
- Region Pair
- Scope: Two regions in same geography
- Key Benefit: Coordinated recovery and updates
- Typical Use: Cross-region disaster recovery
Resource Organization and Governance: Management Groups, Subscriptions, Resource Groups, and Resources
Azure’s management hierarchy enables policy, access, and cost control at scale. Management groups sit above subscriptions and allow you to apply Azure Policy and role-based access control (RBAC) centrally, with inheritance cascading to child management groups and subscriptions. This is the right construct for segmenting by company divisions, environment tiers (production, non-production), or regulatory boundaries, while maintaining uniform guardrails. Subscriptions are the administrative, billing, and quota boundary. They are well-suited to isolating cost and access for business units, environments, or applications. Use a consistent subscription design to separate production from non-production and to enforce limits and budgets. For organizations with multiple divisions and decentralized administration, assign each division one or more subscriptions and place them under division-specific management groups for clean policy and RBAC inheritance. Resource groups are logical containers for resources that share a lifecycle. They enable atomic deployments, consistent tagging, and lifecycle operations like deletion or locking. Group resources that are deployed, updated, and retired together, such as a web tier and its monitoring components. Use tags to drive chargeback/showback, ownership, environment, and compliance attributes across resources and groups. Locks (ReadOnly, CanNotDelete) add accidental-deletion protection at resource or group scope. Resources are the deployed service instances (VMs, App Service plans, storage accounts). RBAC scopes (management group, subscription, resource group, resource) allow granting least-privileged access precisely where needed. For multi-division deployments, keep a single Microsoft Entra ID tenant unless there is a strong compliance or autonomy requirement for multiple tenants; subscriptions and management groups typically provide sufficient separation with far less administrative overhead.
- Management Group
- Primary Purpose: Org-wide governance
- Controls Applied: RBAC, Policy, Blueprints (via Policy + templates)
- Common Patterns: Division/regulatory segmentation
- Subscription
- Primary Purpose: Billing and quota boundary
- Controls Applied: Budgets, RBAC, Policy
- Common Patterns: Per BU or per environment isolation
- Resource Group
- Primary Purpose: Lifecycle boundary
- Controls Applied: Locks, Tags, RBAC
- Common Patterns: Per application or workload unit
- Resource
- Primary Purpose: Service instance
- Controls Applied: Instance-level RBAC, Tags
- Common Patterns: Individual service components
Azure Resource Manager and Templates
Azure Resource Manager (ARM) is the control plane for deploying, updating, and deleting Azure resources through a consistent API and role-based model. ARM provides idempotent operations, dependency management, tagging, and policy enforcement at deployment time, enabling platform governance to be embedded in every change. Declarative ARM templates describe the desired state of your environment in JSON and support parameters, variables, conditions, and modular linked templates. They enable repeatable, version-controlled deployments across environments and subscriptions. For a streamlined authoring experience, Bicep offers a concise syntax that transpiles to ARM templates while retaining the same deployment engine and benefits. Store templates in source control, package them as template specs for sharing, and integrate them into CI/CD pipelines to ensure drift-free, auditable infrastructure changes. Sensitive values such as administrator passwords or connection strings should never be embedded in templates. Use secureString/secureObject parameters with Key Vault references so ARM retrieves secrets at deployment time without exposing them in logs. Combine templates with managed identities to eliminate hardcoded credentials in automation. This approach reduces risk while preserving full automation for large-scale, multi-subscription deployments.
- Idempotent deployments
- ARM/Template Support: Yes
- Outcome: Safe, repeatable changes
- Policy enforcement at deploy
- ARM/Template Support: Yes
- Outcome: Guardrails baked into pipelines
- Modular composition
- ARM/Template Support: Linked modules / Bicep modules
- Outcome: Reusability and standardization
- Secret handling
- ARM/Template Support: Key Vault references
- Outcome: No secrets in code or logs
Availability, SLAs, Composite SLAs, and Service Lifecycle
Azure publishes financially backed service-level agreements (SLAs) for generally available (GA) services. For virtual machines, availability depends on deployment topology: a single VM with Premium SSD storage has a 99.9% SLA; two or more VMs in an availability set have a 99.95% SLA; and two or more VMs deployed across availability zones achieve a 99.99% SLA. Platform services (for example, Azure SQL Database or App Service) have their own SLAs, which may vary by tier or redundancy option. Align the architecture to the target SLA by selecting the appropriate redundancy model and service tiers. When a solution depends on multiple services, the composite SLA is the product of individual SLAs if all components are required for the app to function. For example, if a web app (99.95%) depends on a database (99.99%), the composite availability is approximately 0.9995 × 0.9999 = 99.94%. Increasing redundancy at any layer—such as deploying across zones, adding multiple instances behind a load balancer, or using geo-redundant data stores—improves the effective availability. Conversely, adding serial dependencies lowers the composite SLA and should be justified by clear functional value. Service lifecycle status affects reliability guarantees. Public preview features are offered to gather feedback and may be limited to certain regions or have feature gaps; they typically do not carry an SLA and are not recommended for production-critical paths. GA (general availability) features are production-ready and covered by an SLA. Roadmaps and region rollout schedules should be tracked to avoid inadvertent reliance on preview features in production designs, especially in compliance-sensitive environments. Disaster recovery targets such as RPO and RTO complement SLAs and guide design choices like cross-zone or cross-region replication, backup frequency, and failover orchestration. Validate failover procedures regularly to ensure that the measured recovery performance aligns with business objectives and that DNS, certificates, and identity dependencies also recover as expected.
- Single VM (Premium SSD)
- Indicative SLA: 99.9%
- Notes: Use for non-critical workloads or tolerant apps
- 2+ VMs in Availability Set
- Indicative SLA: 99.95%
- Notes: Protects against rack/fault domain failures
- 2+ VMs across Availability Zones
- Indicative SLA: 99.99%
- Notes: Protects against datacenter-level failures
- Public Preview feature
- Indicative SLA: No financial SLA
- Notes: Evaluate; avoid on critical paths
- GA feature (service-tier dependent)
- Indicative SLA: SLA-backed
- Notes: Check tier- and region-specific SLAs
Global Routing and Content Delivery: Azure Front Door, Traffic Manager, and Azure CDN
Global user experience depends on intelligent routing, proximity to content, and rapid failover. Azure Front Door is a global, anycast Layer 7 reverse proxy with Web Application Firewall (WAF), TLS termination, URL/path-based routing, session affinity, and health probes from the edge. It accelerates dynamic content via split-TCP and protocol optimizations and provides near-instant failover among origins. Front Door is ideal for active-active or active-passive multi-region web applications and APIs where you need both performance and centralized security at the edge. Azure Traffic Manager is a DNS-based traffic distribution service that directs clients to the best endpoint using policies such as priority, weighted, performance (latency), geographic, subnet, or multivalue. Because it operates at DNS, it supports non-HTTP endpoints (e.g., TCP services) and hybrid scenarios, but failover speed is bounded by DNS TTL and client caching. Traffic Manager does not proxy traffic or accelerate content; it simply answers DNS with the chosen endpoint. Azure CDN caches static content at edge points of presence to reduce latency and offload origins. It is well-suited for large static assets like images, videos, scripts, and downloads. While CDN reduces round trips for cacheable content, it is not a health-aware global load balancer for dynamic origins; combine it with Front Door or Traffic Manager for multi-origin failover or for dynamic routing logic. Many architectures place CDN for static asset caching and Front Door for dynamic traffic and security in front of the same application.
- Azure Front Door (Std/Prm)
- Layer/Mechanism: Layer 7 anycast proxy
- Primary Use Cases: Global load balancing, edge security, acceleration
- Routing Methods: Priority, weighted; path/host-based rules
- Health Probing: Edge POP probes
- Failover Speed: Seconds (near-instant)
- Dynamic Acceleration: Yes
- Static Caching: Yes (rules-based)
- WAF Available: Yes (integrated)
- Typical Pattern: Front Door in front of multi-region web apps/APIs
- Azure Traffic Manager
- Layer/Mechanism: DNS-based policy
- Primary Use Cases: Cross-region DNS routing; non-HTTP endpoints
- Routing Methods: Priority, weighted, performance, geographic, subnet, multivalue
- Health Probing: Global endpoint probes
- Failover Speed: TTL-bound (tens of seconds to minutes)
- Dynamic Acceleration: No
- Static Caching: No
- WAF Available: N/A
- Typical Pattern: DNS steering for HTTP and non-HTTP services
- Azure CDN
- Layer/Mechanism: Edge caching network
- Primary Use Cases: Static content offload and latency reduction
- Routing Methods: N/A (cache rules)
- Health Probing: N/A (optional origin group failover)
- Failover Speed: N/A (cache-based)
- Dynamic Acceleration: No (beyond cache)
- Static Caching: Yes
- WAF Available: Via Front Door Premium or separate WAF
- Typical Pattern: CDN for assets + Front Door/Traffic Manager for origins
Practical Problem: Designing a Highly Available, Compliant, and Globally Performant Web Platform for IronPeak Manufacturing
Scenario: IronPeak Manufacturing operates in Europe and North America and is consolidating customer and partner portals onto Azure. The platform must meet 99.99% availability for the web tier, keep EU customer data within the EU, provide rapid failover across regions, and deliver fast page loads worldwide. The team wants fully automated deployments with no plaintext secrets in code or logs.
Challenge: Achieve in-region high availability and cross-region disaster recovery with data residency in the EU, global acceleration and failover for dynamic traffic, and repeatable, secure deployments across subscriptions.
Recommended Approach:
- Select the Europe geography and deploy the primary workload in a region with Availability Zones (for example, West Europe) using two or more VM scale set instances or App Service instances distributed across zones.
- Enable cross-region disaster recovery to the paired region (North Europe) using services’ native replication: use RA-GZRS for Storage and geo-replication for databases where available; configure automated failover runbooks.
- Front the application with Azure Front Door Standard/Premium for global HTTPS termination, WAF, edge health probes, priority-based failover between West Europe (primary) and North Europe (secondary), and rules for path-based routing.
- Cache static assets (images, scripts, downloads) using Azure CDN integrated with the same origins to reduce latency and offload traffic; validate cache rules and TTLs.
- Define management groups for EU and NA divisions; place production and non-production subscriptions under each, applying Azure Policy for data residency, tagging, and allowed locations.
- Implement ARM/Bicep templates stored in source control and published as template specs; parameterize regions, SKUs, and scaling; reference secrets from Azure Key Vault using managed identities for deployments.
- Set SLAs and test composite availability: two zone-distributed instances behind Front Door target 99.99% for the app tier; validate end-to-end failover drills, DNS, certificates, and identity dependencies quarterly.
- Instrument the platform with Application Insights and Azure Monitor; configure Front Door health probes and alerting; tune autoscale and caching policies based on telemetry.
Azure Rationale: This design keeps EU data within the Europe geography while providing in-region fault isolation via Availability Zones and cross-region disaster recovery to the paired region. Azure Front Door delivers global acceleration and health-aware failover for dynamic traffic, while Azure CDN offloads static content for performance. ARM/Bicep templates with Key Vault references provide repeatable, secure deployments across subscriptions and regions. The chosen topologies align to published SLAs to meet the 99.99% target for the web tier, and policy at the management group and subscription levels enforces governance with minimal operational overhead.
← Cloud Concepts · All domains · Compute →
Practice these questions → · Timed practice on ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Pass your exam →