Cloud computing means delivering IT resources over the internet on demand. Those resources include compute, storage, networking, and related services. Instead of buying and running all of your own servers up front, you consume capacity from a cloud provider and typically pay for what you use.

This is shown in the diagram. You are on one side. Over the internet, you reach a cloud provider that offers compute, storage, and networking as on-demand services.

For AZ-900, remember three traits. Resources are available over the network, meaning you reach them remotely rather than only inside your building. They are elastic, meaning you can scale capacity up when demand rises and down when demand falls. They are metered, meaning usage is measured so you can be billed for what you consume.

Look at this diagram of the three traits. Over the network means remote access. Elastic means capacity can grow and shrink with demand. Metered means usage is measured for billing.

This next diagram separates two ideas that often get mixed up. On the left, elastic means capacity follows demand from low to peak and back down. On the right, metered means usage is measured so you pay for what you consume.

On-premises means the hardware lives in your own datacenter or office. You get full control, but you also own the hard parts: buying servers, patching, capacity planning, and physical security.

This comparison diagram puts on-premises and cloud side by side. On-premises means you own the servers, you patch and secure them, and you usually pay upfront capital cost. Cloud means the provider owns the hosts, duties are shared, and you typically pay as you go.

The cloud moves many of those operational burdens to the provider. You still choose how much control to keep, depending on the service model. Exam questions often contrast owning and running servers yourself with consuming metered cloud services.

This diagram spells out that shift. On the left, you own buying hardware, patching, capacity planning, and physical security. On the right, the provider takes more of the hosts and fabric, while you still keep duties like identity and data.

In the cloud, security and management duties are split between you and the provider. The provider always owns the physical datacenter, hosts, and underlying fabric.

This stack diagram shows the split. At the top, apps and data stay with you. In the middle, the OS and runtime depend on whether you chose IaaS, PaaS, or SaaS. At the bottom, physical hosts and the facility belong to the provider.

What you manage depends on the service model. With IaaS, you still patch guest operating systems and applications. With PaaS and SaaS, the provider takes more of the stack. AZ-900 expects you to know this clearly: moving to the cloud does not mean the customer has zero responsibility.

This diagram walks IaaS, PaaS, and SaaS. IaaS leaves you the most duty, including the OS and apps. PaaS lets the provider manage the platform so you focus on code and data. SaaS means the provider manages the app, and you mainly manage users and data.

A public cloud is owned and operated by a provider, such as Microsoft Azure, and shared across many customers over the public internet. You rent capacity from a shared pool. Tenants are isolated from each other, but they still share the provider’s underlying infrastructure.

In this diagram, many tenants sit in one shared provider pool. Tenant A, Tenant B, Tenant C, and you are isolated from each other, but you still share the same underlying fabric. Azure is the classic AZ-900 example.

Public cloud usually gives the most elasticity and the least hardware management for the customer. That is why many AZ-900 scenarios default to Azure as a public cloud example.

This diagram calls out why public cloud shows up so often on the exam: highest elasticity, least hardware work for you, and global reach.

A private cloud gives cloud-like capabilities to one organization only. It may run in your datacenter or be hosted by a third party, but the resources are not shared with other customers.

This diagram shows a fenced environment for your organization only. The capacity is dedicated, and it is not a multi-tenant public pool.

Teams choose private cloud when they need stricter control, isolation, or regulatory boundaries. The tradeoff is usually higher cost and more operational ownership than public cloud.

Look at this tradeoff diagram. You gain control, isolation, and a better compliance fit. You pay for that with higher spend and more operational ownership.

Hybrid cloud connects an on-premises or private environment with a public cloud so workloads and data can span both. Some systems stay local for compliance, latency, or gradual migration. Other workloads burst to the public cloud for scale or newer services.

This diagram shows on-premises or private on one side and public cloud on the other, linked by a bridge such as VPN or ExpressRoute. Some workloads stay local. Others burst to the public cloud to modernize or scale.

On the exam, wording like “combine on-premises with Azure” almost always points to hybrid.

This diagram lists common hybrid reasons: keep data local for compliance, meet latency needs, migrate gradually, or burst out when you need scale.

Choose public cloud when you want elasticity, global reach, and minimal hardware ownership. Choose private cloud when exclusive control or strict isolation is the priority. Choose hybrid when some workloads must stay local while others use the public cloud.

This diagram maps the three choices. Public for elasticity and global reach. Private for strict control or isolation. Hybrid when some work stays local and some uses the public cloud.

AZ-900 scenarios usually name one constraint, such as control, compliance, or needing both worlds. Map that constraint to public, private, or hybrid.

Use this decision diagram on exam questions. Need max elasticity? Public. Need exclusive control? Private. Need both worlds? Hybrid.

A consumption-based model means you pay for the cloud resources you actually use, instead of buying a fixed pile of hardware up front. When demand rises, you can add capacity. When demand falls, you can remove it and stop paying for idle servers.

This chart shows usage rising to a peak and then scaling back in. You pay for what you use as demand grows and shrinks.

This is why cloud spending behaves differently from traditional datacenter purchasing. It also connects directly to the idea that cloud resources are metered.

This comparison makes the contrast clear. A fixed buy means you purchase for peak and waste money on idle capacity. Consumption means you add when busy and remove when quiet.

CapEx, or capital expense, is upfront spending on owned assets, such as servers you buy and depreciate over time. OpEx, or operating expense, is ongoing spending for services you consume, such as a monthly Azure bill.

This money diagram contrasts the two. CapEx is a big upfront buy. OpEx is a stream of smaller ongoing payments, like a monthly cloud bill.

Moving from purchasing servers to pay-as-you-go cloud usage is primarily a shift from CapEx to OpEx. That contrast shows up often on AZ-900.

This shift diagram is the exam pattern: buy servers as CapEx on the left, then move to paying monthly as OpEx on the right.

Cloud pricing usually offers a tradeoff between flexibility and discount. Pay-as-you-go costs more per unit, but you can start and stop freely. Reserved capacity or savings plans cost less when you commit for longer. Spot or interruptible capacity can be cheapest, but the provider may reclaim it.

This diagram lays out three pricing ideas. Pay-as-you-go gives maximum flexibility at a higher unit cost. Reserved or savings plans trade a longer commitment for a lower unit cost. Spot or interruptible capacity can be deeply discounted, but it can be reclaimed.

You do not need every SKU detail for AZ-900. You do need the pattern: more commitment usually means lower unit cost, and more flexibility usually means higher unit cost.

Remember this spectrum diagram. Toward the flexible end is pay-as-you-go. Toward deeper discount are reserved and spot options. Keep the pattern, not every SKU name.