The 5 Essential Characteristics of Cloud Computing (AZ-900)

Cloud computing is usually described through five defining traits: on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service. A platform only counts as “cloud” if it delivers all five together — a data center that requires a phone call to provision a server, for example, is missing on-demand self-service and doesn’t qualify no matter how much virtualization it uses internally. AZ-900 leans on this list constantly, usually by describing a situation and asking which single trait it illustrates.

Why these five traits, and not something else

Plenty of technologies feel “cloud-like” without being cloud computing — a virtualized on-premises server farm, a hosted email inbox, a colocation facility. What separates true cloud computing from those neighbors is that all five characteristics apply at once. Miss even one and the service reverts to something else: a private data center with excellent automation might have rapid elasticity and measured service internally, but if a customer still needs to file a ticket and wait for IT to provision it, on-demand self-service is absent, and the whole model breaks. AZ-900 questions frequently isolate exactly one trait per scenario, so the skill worth building is recognizing which of the five a given sentence is describing — not just being able to recite the list.

The five characteristics at a glance

Characteristic	What it means	Signal that gives it away in a question
On-demand self-service	A customer provisions resources through a portal, CLI, or API with zero interaction with provider staff	”Without contacting support,” “provisions it immediately,” “no human involved”
Broad network access	Services are reachable over standard networks from a wide range of devices — laptops, tablets, phones	Multiple device types, remote access, “from anywhere”
Resource pooling	Multiple customers share the same physical infrastructure through multi-tenancy, with capacity assigned dynamically	”Shared physical servers,” “no control over exact physical location,” multi-tenant
Rapid elasticity	Capacity can be added or removed quickly, often automatically, to match demand	”Scales out during a spike, back in afterward”
Measured service	Usage is automatically tracked and billed based on consumption	”Itemized bill,” “billed by the hour/gigabyte,” metered usage

On-demand self-service, in practice

On-demand self-service means a customer can request compute, storage, or networking resources and receive them immediately, without a human at the cloud provider approving or configuring anything manually. In Azure, this is the experience of opening the Azure portal, Azure CLI, or an API and deploying a virtual machine in minutes. Nothing about the speed of deployment defines this trait by itself — plenty of on-premises automation tools deploy fast too. What matters is the absence of a human gatekeeper on the provider’s side. If a developer has to email an account team to get a new database provisioned, that’s not on-demand self-service, regardless of how quickly the email gets answered. This holds true across service models too — see IaaS vs PaaS vs SaaS for how much self-service control a customer keeps as more of the stack shifts to the provider.

Broad network access and why device variety matters

Broad network access means cloud resources are reachable over standard network protocols by a wide range of client platforms: desktop browsers, mobile apps, thin clients, and everything in between. When a scenario mentions a worker connecting from a laptop, a tablet, and a phone — often from a hotel, an airport, or a home office — that’s broad network access being tested, not on-demand self-service and not elasticity. The trait is about reach and device diversity, not about who provisioned the resource or how fast it scaled.

Resource pooling and multi-tenancy

Resource pooling describes how a cloud provider serves many customers from a shared pool of physical compute, storage, and network hardware, dynamically assigning capacity as demand shifts. Customers typically have no visibility into, or control over, the exact physical machine or rack their workload runs on — they know their data lives in a given region, but not which specific server. This is a multi-tenant model: your virtual machine may sit on the same physical host as another customer’s, isolated by the hypervisor rather than by dedicated hardware. That multi-tenancy is also why the shared responsibility model exists — Microsoft secures the shared physical layer while the customer secures what runs on top of it. Watch for stems that emphasize shared infrastructure and lack of physical location control — that combination points to resource pooling, not high availability or measured service.

Rapid elasticity: scaling to match demand

Rapid elasticity is the ability to add or remove capacity quickly — often automatically — so that resources roughly track actual demand instead of sitting provisioned for a peak that rarely occurs. A retailer that scales out for a two-week holiday surge and scales back in afterward is exercising rapid elasticity. It’s closely related to, but distinct from, general scalability; the scalability versus elasticity article draws that line precisely, including how elasticity typically implies automation while scalability can be manual. For AZ-900 purposes, if a stem talks about capacity increasing and then decreasing again in response to a temporary spike, elasticity is almost always the intended answer.

Measured service and metered billing

Measured service means the cloud platform automatically monitors, controls, and reports resource usage, and that reporting is what makes consumption-based billing possible. When a finance team sees an itemized invoice broken down by virtual machine hours, gigabytes stored, and gigabytes transferred, that granularity exists because the underlying platform metered every one of those dimensions. Measured service is the mechanism; consumption-based pricing is the billing model it enables — the two show up together constantly, and understanding how CapEx and OpEx shift under that billing model is covered in depth in CapEx vs OpEx cloud economics.

How the AZ-900 exam tests this

• A scenario names a single action — provisioning without contacting support, connecting from multiple device types, seeing an itemized usage bill — and asks which characteristic it demonstrates. The trap answers are the other four characteristics, each plausible-sounding but describing a different mechanic entirely.
• A “choose two” or “choose three” question lists genuine characteristics mixed with contradictions of cloud computing itself (mandatory multi-year contracts, fixed capacity that can’t change, requiring hardware ownership up front). Anything that describes rigidity or ownership is disqualified immediately.
• A scenario blends elasticity and scalability language — for example, a system that scales out during a short event and back in afterward — and expects you to identify elasticity specifically, not “scalability” as a generic catch-all.
• A distractor swaps in an unrelated cloud concept, like data residency or vendor lock-in, as the answer to a characteristics question. Those are real AZ-900 topics, just not among the five essential characteristics, so they’re always wrong here.

Quick reference

• Five characteristics: on-demand self-service, broad network access, resource pooling, rapid elasticity, measured service.
• On-demand self-service = no human interaction with the provider needed to provision.
• Broad network access = reachable from many device types over standard networks.
• Resource pooling = multi-tenant, dynamically assigned, customer doesn’t control physical location.
• Rapid elasticity = capacity scales up and down quickly to match demand, often automatically.
• Measured service = usage is metered automatically, which is what enables itemized, consumption-based billing.
• All five must apply together for something to genuinely be “cloud computing.”
• These five traits are the foundation for the rest of the exam’s “Describe Cloud Concepts” material — see the full AZ-900 study guide for how this fits into all three exam domains.
• Ready to test your recall against real exam phrasing? Practice AZ-900 questions built around exactly these scenario patterns.