Microsoft AZ-900: Cloud Concepts — Study Guide

By Laurynas Brazys · 22 July 2026 · #microsoft #az-900 #certification #exam-prep #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.

Cloud computing delivers metered IT resources over the internet with rapid provisioning, global reach, and built‑in resilience. Moving from on‑premises infrastructure to Azure changes both technology choices and operating models: capacity planning gives way to elastic scaling, capital purchases shift to operational spend, and hardware maintenance becomes a platform responsibility. Understanding these concepts is essential to select the right services, architect for availability, and control cost.

Core cloud characteristics: scalability, elasticity, agility, and resilience

Scalability is the ability of a workload to handle increased demand by adding resources. In Azure this takes two forms: vertical scaling (scale up) by choosing larger VM sizes or higher App Service plans, and horizontal scaling (scale out) by adding more instances via Virtual Machine Scale Sets (VMSS), Azure Kubernetes Service (AKS) node pools, or App Service autoscale. Scaling in the opposite direction reduces capacity and cost when demand falls. Designing stateless tiers and externalizing state (for example to Azure Cache for Redis or Azure SQL Database) makes horizontal scaling predictable and fast. Elasticity is automated, policy‑driven scaling that continuously aligns capacity to load. Azure Monitor autoscale rules, AKS cluster autoscaler, and serverless options such as Azure Functions or Consumption/Elastic Premium plans expand and contract resources in near real time. Elastic architectures minimize idle capacity and are well suited to spiky or seasonal workloads, shifting spend precisely with usage. Agility is the speed at which teams deliver change. Azure resource deployment through Bicep or ARM templates, GitHub Actions or Azure DevOps pipelines, and resource abstractions like App Service or AKS allow frequent, low‑risk releases. Self‑service provisioning through RBAC and policy guardrails reduces wait times while maintaining governance. Agility is a product of both the platform and organizational practices; the more the platform abstracts undifferentiated heavy lifting, the faster teams can move. Fault tolerance and disaster recovery address different failure scopes. Fault tolerance mitigates component and datacenter failures inside a region using Availability Sets (spreading VMs across fault/update domains), Availability Zones (physically separate datacenters within a region), load balancers, and redundant data paths. Disaster recovery prepares for region‑level outages with cross‑region replication (GRS/RA‑GRS storage, Azure SQL active geo‑replication, Cosmos DB multi‑region writes) and recovery tooling like Azure Site Recovery. Define clear RTO/RPO targets and test failover to ensure the design meets business continuity objectives.

Service models and shared responsibility

Cloud service models determine what you manage versus what Azure manages. Infrastructure as a Service (IaaS) exposes raw compute, storage, and networking building blocks. You control the guest OS, runtime, and applications—ideal when you need custom images, specialized middleware, or full control. Platform as a Service (PaaS) abstracts the OS and much of the middleware, providing managed runtimes, databases, and integration services so teams can focus on code and data. Software as a Service (SaaS) delivers complete applications consumed via browser or API with minimal configuration and no application hosting obligations. The shared responsibility model clarifies operational boundaries. In IaaS, Azure manages the physical datacenter, hosts, and hypervisor; you handle OS patching, hardening, application updates, identity and access, and data governance. In PaaS, Azure also manages the OS and platform middleware; you manage application code, configuration, and data. In SaaS, Azure (or the SaaS provider) operates the entire stack; you manage users, access, data classification, and usage configuration. Across all models, customers retain accountability for identity, permissions, endpoint security, and data protection policies. Selecting the right model affects availability targets and cost. Deploying Azure virtual machines is an IaaS task; web APIs on Azure App Service or containers on AKS reflect PaaS; Microsoft 365 and Dynamics 365 are SaaS. Favor PaaS and SaaS when possible to accelerate delivery and reduce operational burden, reserving IaaS for workloads that require OS‑level control or legacy dependencies.

• IaaS
  • Typical Azure services: Azure Virtual Machines, VM Scale Sets, Azure Disks, Virtual Network
  • What you manage: Guest OS, patches, runtime, apps, data, backups, AV/EDR
  • When to choose: Full OS control, custom middleware, lift‑and‑shift
• PaaS
  • Typical Azure services: Azure App Service, Azure SQL Database/Managed Instance, AKS, Azure Functions, Azure Integration Services
  • What you manage: Code/config, schema, data, identity and access
  • When to choose: Faster delivery, built‑in scaling/HA, reduced ops
• SaaS
  • Typical Azure services: Microsoft 365, Dynamics 365, Power BI, Azure DevOps Services
  • What you manage: Users, roles, data usage/configuration
  • When to choose: Complete apps with minimal management

Deployment models and scope of scale

Public cloud deploys workloads into Microsoft‑owned datacenters shared across multiple tenants with logical isolation. It offers the broadest catalog, global reach, rapid provisioning, and a pure pay‑as‑you‑go model. Private cloud dedicates infrastructure to a single organization, often for regulatory or data‑sovereignty reasons, and may run on Azure‑validated stacks such as Azure Stack Hub or Azure Stack HCI. Hybrid cloud connects on‑premises and Azure with consistent identity, policy, and networking, enabling phased migrations and data locality while leveraging cloud elasticity where it makes sense. Global versus local scaling concerns the scope of availability and performance improvements. Local scaling keeps traffic inside a region, using Availability Zones, VM Scale Sets, Application Gateway, and Azure Load Balancer to add instances and isolate datacenter faults. Global scaling distributes traffic across regions using Azure Front Door (modern, anycast, layer 7 global load balancing with WAF), Azure Traffic Manager (DNS‑based load balancing), and Geo‑replicated data services like Azure SQL geo‑replication or Cosmos DB multi‑region distribution. Multi‑region active/active designs enhance latency and resilience but require careful data consistency and cost planning. Choosing a deployment model often starts with compliance and connectivity constraints and evolves with the application lifecycle. New greenfield web applications frequently land in public cloud PaaS for speed and scalability. Complex line‑of‑business systems with dependencies may begin hybrid—retaining certain services on‑premises while front‑ends and stateless tiers move to Azure—before completing the transition as dependencies are modernized.

• Public
  • Ownership/Location: Microsoft‑owned regions
  • Typical access: Internet/VPN/ExpressRoute
  • Use cases: Elastic scaling, global reach, rapid innovation
  • Azure examples: Most Azure services, Azure Front Door, Azure App Service
• Private
  • Ownership/Location: Customer‑dedicated infra (on‑prem or hosted)
  • Typical access: Private networks
  • Use cases: Sovereignty, isolated workloads, strict compliance
  • Azure examples: Azure Stack Hub, Azure Stack HCI, AKS on HCI
• Hybrid
  • Ownership/Location: Mix of on‑prem and Azure
  • Typical access: Site‑to‑site VPN or ExpressRoute
  • Use cases: Phased migration, data locality, legacy integration
  • Azure examples: Azure VPN Gateway, ExpressRoute, Azure Arc

Cost models: CapEx vs OpEx, consumption pricing, pay‑as‑you‑go and reserved capacity

On‑premises procurement is typically capital expenditure (CapEx): large upfront purchases of servers, storage, and networking depreciated over years. Azure flips this model to operational expenditure (OpEx): services are metered and billed based on actual consumption—CPU seconds, GB‑months, transactions—shifting spending to when value is realized. This consumption‑based pricing reduces over‑provisioning and ties cost to usage patterns. Pay‑as‑you‑go maximizes flexibility: start and stop resources at will with no term commitment. For steady‑state workloads, Azure offers reservation‑based discounts such as Reserved Virtual Machine Instances, Azure SQL Database reserved capacity, Cosmos DB RU/s reservations, and Storage reserved capacity. One‑year or three‑year commitments can yield significant savings while optionally enabling instance size flexibility and shared scope across subscriptions. Complementary options include Azure Savings Plans for Compute, which apply discounted rates across eligible compute services, and Spot VMs for interruptible, batch‑style workloads at deep discounts. Effective cost governance pairs the right commercial model with engineering controls. Autoscale reduces idle capacity; serverless tiers eliminate infrastructure when idle; Azure Hybrid Benefit applies existing Windows Server and SQL Server licenses; Dev/Test pricing lowers non‑production spend. Azure Cost Management + Billing provides budgets, anomaly detection, and cost allocation to continuously optimize.

• Pay‑as‑you‑go
  • Commitment: None
  • Typical discount vs PAYG: 0%
  • Flexibility: Max flexibility; start/stop anytime
  • Best for: Unpredictable or short‑lived workloads
• Reserved VM Instances / Reserved capacity
  • Commitment: 1‑year or 3‑year
  • Typical discount vs PAYG: Up to ~72% (with Azure Hybrid Benefit)
  • Flexibility: Scope can be shared; exchange allowed; early cancel fees
  • Best for: Steady 24x7 compute, databases, Cosmos DB
• Savings Plan for Compute
  • Commitment: 1‑year or 3‑year spend commitment
  • Typical discount vs PAYG: Up to ~65%
  • Flexibility: Applies across VMs, AKS, Functions Premium, App Service
  • Best for: Mixed compute with variable instance types
• Spot VMs
  • Commitment: None (capacity dependent)
  • Typical discount vs PAYG: Up to ~90%
  • Flexibility: Can be evicted; no SLA
  • Best for: Batch, stateless, CI, render jobs

Practical Problem: PeakGear Retail: seasonal scaling with cost control and resilience

Scenario: PeakGear Retail runs an e‑commerce site with predictable end‑of‑month and holiday traffic spikes. The company wants to move from on‑premises VMs to Azure, reduce capital expense, maintain a 99.99% availability target for the web tier, and implement a disaster recovery plan with a four‑hour RTO and 15‑minute RPO. Identity must integrate with existing users via Microsoft Entra ID.

Challenge: Design an Azure architecture and cost model that delivers elastic scaling for traffic surges, zone‑level fault tolerance, cross‑region disaster recovery, and operational simplicity while minimizing cost during non‑peak periods.

Recommended Approach:

1. Deploy the web API and storefront on Azure App Service (PaaS) using Premium v3 plans to gain built‑in autoscale, managed platform patching, and zone redundancy options.
2. Place two or more App Service instances behind Azure Front Door Standard/Premium for global anycast entry, SSL termination, WAF, and path‑based routing; enable health probes and session affinity as needed.
3. Use Azure SQL Database Business Critical with zone redundancy in the primary region; configure active geo‑replication to a paired secondary region targeting 15‑minute RPO.
4. Store static content in Azure Storage with RA‑GRS; front it with Azure CDN from Microsoft to offload bandwidth and improve latency.
5. Implement autoscale rules based on CPU, requests, and queue depth to scale out during spikes and scale in during quiet periods; for background jobs, use Azure Functions Consumption or Elastic Premium plans.
6. Achieve 99.99% web tier availability by enabling zone redundancy (multi‑zone) for the App Service plan or by distributing instances across Availability Zones where supported.
7. Adopt pay‑as‑you‑go initially for flexibility; for the steady baseline capacity identified after 30 days, purchase a 1‑year Reserved Instance for App Service plans (via Savings Plan for Compute covering App Service) and reserved capacity for SQL Database to reduce run‑rate cost.
8. Integrate Microsoft Entra ID for user and admin access; apply least privilege with built‑in roles and conditional access; protect secrets in Azure Key Vault referenced by App Service and deployment pipelines.
9. Define and test DR runbooks: failover SQL to secondary, update Front Door origin priorities to activate the secondary region, and validate application health within a four‑hour RTO.
10. Implement Azure Monitor and Log Analytics for centralized metrics, traces, and logs; configure alerts and dashboards; set Azure Cost Management budgets and anomaly alerts to continuously optimize spend.

Azure Rationale: PaaS services (App Service and Azure SQL Database) maximize agility and offload OS and platform maintenance under the shared responsibility model, while enabling autoscale for elasticity. Zone‑redundant deployment and multi‑region replication provide fault tolerance within a region and disaster recovery across regions that meet the stated RPO/RTO. Front Door supplies global ingress, health‑based routing, and WAF protection. Starting with pay‑as‑you‑go preserves flexibility during migration; committing to reserved capacity or a Savings Plan for the measured baseline reduces cost for steady usage, while autoscale trims spend during off‑peak periods. Microsoft Entra ID centralizes identity and access control, and Azure Monitor with Cost Management maintains operational and financial visibility.

All domains · Azure Architecture →

Practice these questions → · Timed practice on ExamRoll.io →

Browse Microsoft →