The ability to add or remove resources to match workload demand.
Scalability is the ability of a system to handle increased demand by adjusting its resources, and Azure supports two strategies. Vertical scaling (scaling up) increases the capacity of an existing resource, such as moving a virtual machine to a larger size with more CPU and RAM. Horizontal scaling (scaling out) adds more instances, like deploying additional VMs behind a load balancer. Distinguish scalability from elasticity: scalability is the capability to scale, while elasticity is the automatic scaling in response to demand. Virtual Machine Scale Sets and App Service support both, but the terms are tested separately.
Automatically scaling resources up and down in response to real-time demand.
Elasticity is the cloud’s ability to automatically add or remove resources in direct response to real-time changes in workload demand. In Azure, this is delivered through features like autoscale on Virtual Machine Scale Sets and App Service, which monitor metrics such as CPU utilization and adjust instance counts without manual intervention. The key exam distinction is between elasticity and scalability. Scalability means a system can handle increased load, but that growth may require deliberate, planned action. Elasticity specifically implies automatic, dynamic adjustment in both directions: scaling out when demand spikes and scaling back in when it drops, keeping costs aligned with actual usage.
The ability to deploy and reconfigure resources quickly as business needs change.
Agility in cloud computing means an organization can provision, configure, and decommission resources in minutes rather than waiting weeks for hardware procurement. On Azure this is tangible through services like Virtual Machines, Azure Kubernetes Service, and App Service, all deployable on demand via the portal, CLI, or infrastructure-as-code. The AZ-900 exam often pairs agility with scalability, but they differ: scalability is about handling more load on existing workloads, while agility is how quickly you respond to new business needs — launching a product, entering a market, or standing up disaster recovery.
Designing systems to stay operational with minimal downtime, even when components fail.
High availability (HA) means designing a system to keep operating when individual components fail, usually expressed as a percentage uptime target in a Service Level Agreement. Azure delivers HA through redundancy: Availability Zones are physically separate datacenters within a region, while Availability Sets spread virtual machines across fault domains and update domains within a single datacenter. A common exam trap is confusing HA with disaster recovery: HA keeps a workload running during routine failures in the same region, whereas disaster recovery handles full-region outages by failing over to a second region. Azure Load Balancer and Traffic Manager route traffic away from unhealthy instances.
The ability to restore service and data after a major outage or catastrophic event.
Disaster recovery (DR) restores systems, data, and operations after a major outage from hardware failure, natural disaster, cyberattack, or human error. It is driven by two metrics: Recovery Time Objective (RTO), the maximum tolerable downtime, and Recovery Point Objective (RPO), the maximum acceptable data loss measured in time. Azure Site Recovery replicates on-premises or Azure workloads to a secondary region to meet these goals. Do not confuse DR with high availability: high availability uses redundancy to keep a service running, whereas DR restores service after a failure has already occurred. Azure paired regions provide geographically distant replication targets that help meet RPO during regional disasters.
Buying datacentre hardware up front as a capital asset versus consuming Azure services as a monthly operating expense.
Capital expenditure (CapEx) means paying upfront for physical infrastructure — servers, data centers, networking hardware — that depreciates over time and sits on the balance sheet as an asset. Operational expenditure (OpEx) means paying for resources as consumed, which is how Azure services are billed through subscriptions and pay-as-you-go pricing. The AZ-900 exam tests this as a cloud benefit: moving to Azure shifts spending from CapEx to OpEx, improving cash-flow predictability and eliminating over-provisioning risk. A common confusion equates OpEx with “cheap” — the real advantage is flexibility and no idle-capacity waste, not necessarily lower total spend.
A system's ability to keep running correctly even when some components fail.
Fault tolerance is a system’s ability to keep operating correctly even when one or more components fail. Azure achieves it through redundancy at multiple layers: duplicate power and network hardware within a datacenter, data replication across Availability Zones in a region, and geo-redundant storage that copies data to a paired region hundreds of miles away. The key exam distinction is from high availability: high availability minimizes downtime and targets an uptime percentage, while fault tolerance goes further, aiming for zero perceptible disruption when a failure occurs. It is closely tied to eliminating single points of failure.
A system's ability to recover from failures and continue to function.
Reliability describes a cloud system’s capacity to recover from failures and continue operating as expected. In Azure’s context it encompasses two distinct properties: resiliency, the ability to detect, respond to, and recover from failures, and availability, the percentage of time a service remains accessible. Azure supports reliability through features such as Availability Zones, geo-redundant replication, and automatic failover in services like Azure SQL Database and Azure Storage. On the AZ-900 exam, reliability is one of the five pillars of the Azure Well-Architected Framework. A common confusion is equating reliability solely with uptime: availability is only one dimension, and a system that recovers quickly from an outage is still reliable. Watch for questions that distinguish reliability (recovery-focused design) from fault tolerance (designing so failures cause zero impact).