Cloud Computing

What cloud computing actually is

The whole of cloud computing comes down to one swap the exam keeps testing: instead of buying and running hardware you own, you rent it. Cloud computing is the delivery of computing services (servers, storage, databases, networking, software, and analytics) over the internet, billed as a metered utility rather than purchased as kit that sits in your own datacenter. Microsoft defines cloud computing^[1] as renting these resources on demand, where you provision what you need in minutes and release it when you are finished.

The core mental shift the exam tests is owning vs renting. Traditionally a company bought physical servers, racked them in its own datacenter, paid for power and cooling, and replaced them every few years. With the cloud, Microsoft Azure^[2] owns and operates that hardware in global datacenters, and you simply consume the capacity you need. The diagram below shows the same swap: on-premises you own the whole stack, while on Azure the provider owns the hardware and you bring only your workloads.

A few foundational terms appear throughout AZ-900:

Term	Meaning
Compute	Processing power to run applications (for example virtual machines, containers, functions).
Storage	Durable places to keep data (files, blobs, disks, databases).
Tenant	A dedicated instance of an organization's resources and identities in the cloud.
Elasticity	The ability to add or remove resources quickly as demand changes.

Azure is a public cloud, a cloud a provider owns and shares across many customers (tenants); the Cloud deployment models section below defines it in full. Because it is public, many tenants share the same physical infrastructure while staying logically isolated. You never see the other tenants, and Microsoft enforces the separation.

Owning vs renting: on-premises you own the whole stack; on Azure Microsoft owns the hardware and you bring only your operating system, applications, and data.

The shared responsibility model

Security in the cloud is a partnership. The shared responsibility model^[3] defines which security tasks belong to Microsoft (the cloud provider) and which belong to you (the customer). The boundary shifts depending on the service type (IaaS, PaaS, or SaaS (infrastructure-, platform-, and software-as-a-service), the three managed-service tiers covered in the Cloud service types subtopic), and the more managed the service, the more Microsoft handles.

Always the provider's responsibility (all service types):

Physical datacenters (locks, guards, building security)
Physical network (cabling, switches between racks)
Physical hosts (the server hardware itself)

Always the customer's responsibility (all service types, even SaaS):

The data you put in the cloud
Accounts and identities (the user objects)
Access management (who can do what)

The layers that shift with service type:

Responsibility	On-premises	IaaS	PaaS	SaaS
Operating system	Customer	Customer	Provider	Provider
Network controls	Customer	Customer	Shared	Provider
Applications	Customer	Customer	Shared	Shared
Identity & directory	Customer	Customer	Customer	Customer
Data	Customer	Customer	Customer	Customer

The single most testable rule: you, the customer, are always responsible for your data, your identities, and your access, no matter which cloud service model you use. Microsoft is always responsible for the physical layer. Everything in between depends on whether you chose IaaS, PaaS, or SaaS.

Shared responsibility model: the customer always owns data, accounts/identities, and access; Microsoft always owns the physical layer; the middle layers shift across IaaS, PaaS, SaaS.

Cloud deployment models: public, private, hybrid (and multicloud)

A deployment model describes where the cloud infrastructure lives and who owns it. AZ-900 expects you to know three, plus an awareness of multicloud. As the diagram shows, hybrid is not a fourth kind of cloud but a connection between a public and a private one.

Public cloud

Resources are owned and operated by a third-party provider (Microsoft) and shared across many organizations over the public internet. There is no capital expense: you pay only for what you use. Public cloud offers the highest scalability and lowest management burden, but the least direct control over the hardware. Azure is a public cloud.

Private cloud

Cloud infrastructure used exclusively by a single organization. It can sit in your own datacenter or be hosted by a third party, but it is not shared with other tenants. A private cloud gives the most control and can satisfy strict regulatory or data-residency requirements, but you (or a contracted provider) pay for and maintain the hardware, so it carries higher cost and less elasticity.

Hybrid cloud

A combination that connects a public cloud and a private cloud (or on-premises datacenter) so applications and data can move between them. Hybrid suits organizations that must keep some workloads on-premises (for compliance or latency) while bursting to the public cloud for extra capacity or modernizing gradually. Azure Arc^[4] and Azure VPN/ExpressRoute connectivity are commonly associated with hybrid scenarios.

Multicloud (awareness only)

Using more than one public cloud provider at the same time (for example Azure plus another vendor). Organizations adopt multicloud to avoid lock-in or to use the best service from each provider. Azure Arc^[4] can help manage resources across multiple clouds.

Use-case matching (a very common question style):

Scenario in the question	Best model
Startup wants no up-front hardware, instant scale	Public
Bank must keep customer records in its own datacenter	Private
Company migrating gradually, some data must stay on-prem	Hybrid
Seasonal retailer needs to burst capacity at holidays	Public (or hybrid burst)

Deployment models: public (provider-owned, shared) and private (one organization) are the two homes; hybrid connects them; multicloud uses more than one public provider.

CapEx vs OpEx and the consumption-based model

Cloud economics is a guaranteed AZ-900 topic, and it hinges on two accounting terms. The diagram contrasts them: an up-front asset purchase (CapEx) versus pay-as-you-go spending (OpEx), which is the cloud's consumption-based model.

Capital expenditure (CapEx)

A large up-front purchase of physical infrastructure (servers, storage arrays, networking gear) that is then depreciated over its useful life. CapEx is the traditional on-premises model: you spend money before you know exactly how much you will use, and you carry the asset on the books for years. It often leads to either over-provisioning (buying for peak demand and wasting idle capacity) or under-provisioning (running out at peak).

Operational expenditure (OpEx)

Ongoing, pay-as-you-go spending on services you consume, with no asset to depreciate. The cloud is an OpEx model: there is no up-front hardware cost, and you expense the bill as you go.

The consumption-based model

Azure bills on a consumption-based / pay-as-you-go model^[1]: you pay only for the resources you actually use, and you stop paying when you stop using them. This produces several advantages the exam loves:

No up-front cost: start with zero hardware investment.
No wasted capacity: scale down to stop paying for idle resources.
Pay for more only when you need more: scale up to meet demand.

Cloud pricing models you should recognize

Pricing model	What it is	When it wins
Pay-as-you-go (consumption)	Billed per unit consumed, no commitment	Variable or unknown demand
Reserved (reservations)	Commit to 1 or 3 years for a discount	Steady, predictable workloads
Spot	Use spare capacity at deep discount, can be reclaimed	Interruptible, fault-tolerant work

Exam shorthand: up-front purchase of servers = CapEx; pay-as-you-go cloud bill = OpEx. If a question says "no large initial investment" or "pay only for what you use," the answer is the consumption-based / OpEx cloud model.

CapEx vs OpEx: CapEx is an up-front asset purchase (on-premises); OpEx is pay-as-you-go consumption with no asset to depreciate (the cloud).

Serverless computing

Serverless is a cloud execution model where the platform fully manages the servers, and you focus only on your code or configuration. Despite the name, servers still exist: you simply never see, provision, or patch them. Azure Functions^[5] is Azure's flagship serverless compute service.

Three characteristics define serverless on the exam:

Abstracted infrastructure: no servers to manage; Azure provisions and maintains them for you.
Event-driven and automatically scaling: code runs in response to a trigger (an HTTP request, a timer, a queue message) and scales out to handle load, then back down to zero when idle.
Pay-per-execution: billing is based on the number of executions and the resources each consumes; when nothing runs, you pay nothing.

The diagram traces that lifecycle: a trigger arrives, Azure runs your code and scales out under load, then scales back to zero when idle so billing stops. Serverless is essentially the consumption-based model taken to its logical end. It is ideal for short, intermittent, or spiky workloads, for example processing a file when it is uploaded, or running a scheduled cleanup job. It is a poor fit for long-running, always-on, or latency-sensitive processes, where dedicated compute that you do not pay to cold-start is more appropriate.

Serverless lifecycle: a trigger arrives, Azure runs your code on managed infrastructure, scales out under load, then scales to zero when idle so you pay nothing.

Recognizing these questions on the exam

AZ-900 tests this subtopic with short scenario and definition questions. Knowing the trigger phrases lets you answer fast.

Shared responsibility patterns

"Who is responsible for patching the guest operating system on an Azure VM?" → the customer (IaaS keeps the OS with you).
"Who is responsible for physical security of the datacenter?" → Microsoft, always.
"Who is responsible for the data and user accounts in a SaaS app?" → the customer, always. This is the trap, because people assume SaaS means "Microsoft does everything."

Deployment-model patterns

"No capital expenditure, shared infrastructure, maximum scale" → public cloud.
"Single organization, full control, strict compliance" → private cloud.
"Keep some workloads on-premises while using the cloud for the rest" → hybrid cloud.
"Use two different cloud vendors at once" → multicloud.

Economics patterns

"Avoid large up-front investment / pay only for what you use" → OpEx / consumption-based (the cloud).
"Purchase and depreciate servers over time" → CapEx (on-premises).
"Predictable, steady, always-on workload, lowest cost" → reserved pricing, not pure pay-as-you-go.

Serverless patterns

"Run code without managing any servers, pay only when it executes" → serverless (Azure Functions).
"Event-driven function triggered by a file upload" → serverless.

Distractor watch-outs: answers that say Microsoft secures your data are wrong (you always own data). Answers that call a private cloud "no up-front cost" are wrong (private cloud is CapEx). Answers that pick serverless for a long-running, always-on service are wrong.

Public vs private vs hybrid cloud

Aspect	Public	Private	Hybrid
Ownership	Provider (Microsoft)	Single organization	Mix of both
Cost model	OpEx, pay-as-you-go	CapEx, you buy hardware	Blend of CapEx and OpEx
Control	Lowest (provider-managed)	Highest (you manage all)	Shared / configurable
Scalability	Near-unlimited, elastic	Limited to owned capacity	Burst to public on demand
Typical use case	Web apps, dev/test, bursty	Strict compliance, legacy	Gradual migration, data residency

Decision tree

Cheat sheet

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

Cloud computing rents IT resources over the internet

Cloud computing delivers compute, storage, networking, databases, and software as metered services over the internet, so you rent capacity and release it when you're done instead of buying and maintaining a datacenter. On Microsoft Azure you provision a resource in minutes and pay only for what you use, with the provider maintaining the underlying power, cooling, hardware, and networking.

2 questions test this

Azure is a multi-tenant public cloud

Azure is a public cloud where many customers (tenants) share the same physical infrastructure while staying logically isolated from one another. A tenant is a dedicated instance of a Microsoft Entra directory holding an organization's identities and resources, so isolation is logical, not a separate physical environment per customer.

Trap Assuming a public-cloud tenant gets its own dedicated physical hardware: multi-tenancy isolates customers logically while they share the same hosts.

1 question tests this

What is characteristic of using Azure Virtual Machines in a public cloud deployment model?

Shared responsibility model splits security by service type

The shared responsibility model defines which security tasks belong to Microsoft and which to the customer, and the boundary shifts with the service type. The more managed the service (IaaS → PaaS → SaaS), the more responsibility moves to Microsoft. In IaaS you still own the OS, applications, and network controls, while in SaaS Microsoft handles all but your data, identities, and access.

2 questions test this

Microsoft always owns the physical layer

Across IaaS, PaaS, and SaaS, Microsoft is always responsible for the physical datacenters, the physical network, and the physical hosts (plus the hypervisor). The customer never secures the hardware in a public cloud, no matter the service model.

Trap Assuming the customer secures the physical hosts or datacenter in IaaS, when Microsoft owns the physical layer at every service model.

18 questions test this

You always own data, identities, and access

Regardless of service model, even SaaS, the customer always retains responsibility for their data, accounts/identities, client endpoints, and access management. These four never transfer to Microsoft, which makes them the single most common shared-responsibility trap on the exam.

Trap Assuming a fully managed SaaS service makes Microsoft responsible for your data and user identities: those stay with the customer at every service tier.

17 questions test this

Public cloud is provider-owned and shared

A public cloud is built, controlled, and maintained by a third-party provider (Microsoft) and open to anyone who purchases its services, with no capital expenditure to scale up and pay-only-for-what-you-use billing. The tradeoff is that you don't have complete control over the resources and security the provider operates.

Trap Picking public cloud when the scenario demands complete control and data that is not collocated with other tenants, which points to private cloud.

2 questions test this

Private cloud is dedicated to one organization

A private cloud is used exclusively by a single organization and gives the most control over resources and security, with your data not collocated with other tenants'. You must purchase and maintain the hardware yourself, so it carries greater cost and fewer of the public cloud's elasticity benefits.

Trap Assuming a private cloud removes up-front hardware cost like public cloud, when you still buy and maintain the hardware yourself.

2 questions test this

Hybrid cloud connects public and private

A hybrid cloud links a public cloud with a private cloud or on-premises datacenter in one interconnected environment, letting a private cloud surge into public capacity for temporary demand. It gives the most flexibility: you choose which workloads run where to meet security, compliance, or legal requirements, e.g. keeping regulated data private while bursting elsewhere.

Trap Choosing multicloud for a scenario that keeps some workloads private or on-premises while using public cloud, which is hybrid, not multiple public providers.

1 question tests this

A company runs critical legacy applications on virtual machines in their on-premises datacenter while using Azure Virtual Machines to…

Multicloud uses more than one cloud provider

Multicloud means using two or more public cloud providers at once (often to use the best feature from each or while migrating between them) so you manage resources and security across both. Azure Arc can help manage resources spanning public, private, hybrid, and multicloud environments.

Trap Labeling a public-plus-on-premises setup as multicloud, when multicloud means two or more public cloud providers and that mix is hybrid.

Match the scenario to the deployment model

Map the scenario to its model: no up-front cost plus quick scale-up points to public cloud; complete control with data not collocated and strict requirements points to private cloud; keeping some workloads on-premises or private while using public cloud points to hybrid. Multiple public providers at once is multicloud.

Trap Confusing hybrid with multicloud, where hybrid mixes public with private or on-premises and multicloud uses two or more public providers.

3 questions test this

CapEx is an up-front hardware purchase

Capital expenditure (CapEx) is up-front spending on physical infrastructure (servers, network hardware, datacenter space) that is depreciated over years. It is the traditional on-premises model and forces capacity planning that risks over- or under-provisioning.

Trap Classifying pay-as-you-go cloud spending as CapEx, when CapEx is up-front depreciated hardware and consumption billing is OpEx.

1 question tests this

Which statement accurately describes a benefit of deploying Azure Virtual Machines in the public cloud compared to maintaining an…

OpEx is ongoing pay-as-you-go spending

Operational expenditure (OpEx) is ongoing spending on services as you consume them, with no physical asset to depreciate. Because you pay for cloud services as you use them, cloud computing is classified as an operating expense, not a capital one.

Trap Treating an up-front depreciated hardware purchase as OpEx, when that is CapEx and only consumed-as-you-go service spending is OpEx.

2 questions test this

Consumption-based billing means pay for what you use

Azure runs on a consumption-based, pay-as-you-go model: you pay only for the IT resources you use and release them, and stop paying, when you're done. This removes up-front hardware cost and the need to buy capacity that may sit idle, letting you scale out at peak and back in when demand drops.

21 questions test this

Reserved pricing rewards steady, predictable workloads

Azure Reservations commit to a one- or three-year term in exchange for a discount of up to 72% over pay-as-you-go, applied automatically to matching resources. They are the right pick for consistent, always-on base usage, not for bursty or short-lived workloads where consumption pricing fits better.

Trap Choosing reservations for bursty or short-lived workloads, when a one- or three-year commitment fits steady always-on usage and consumption pricing fits intermittent demand.

18 questions test this

Spot pricing uses reclaimable spare capacity

Azure Spot Virtual Machines run on Azure's unused capacity at a significant discount, but there is no SLA and Azure evicts them with only 30 seconds' notice whenever it needs the capacity back. They fit interruptible, fault-tolerant work (batch jobs, dev/test, large compute) not critical always-on services.

Trap Running a production always-on service on Spot to save money: a 30-second eviction with no SLA takes the node down whenever Azure reclaims capacity.

Serverless abstracts the servers away

Serverless computing has the platform provision, scale, and maintain the servers while you supply only code: you never deploy or patch the underlying infrastructure. Azure Functions is Azure's serverless compute service, letting you run code without managing the VMs it runs on.

12 questions test this

Serverless is event-driven and pay-per-execution

Serverless code runs in response to triggers (HTTP, timer, queue, blob change), scales automatically with the number of incoming events, and on the consumption plan bills only on executions, execution time, and memory used. When nothing runs you pay nothing for compute, making it ideal for spiky or intermittent workloads.

41 questions test this

Serverless is a poor fit for always-on workloads

Serverless suits short, stateless, intermittent tasks: on the Azure Functions consumption plan a function execution times out after a configurable maximum and idle instances incur cold starts. Long-running or always-on, latency-sensitive services are better on dedicated or premium (always-warm) compute that doesn't time out or cold-start.

Trap Reaching for the serverless consumption plan for a long-running, latency-sensitive service, when execution timeouts and cold starts make dedicated or premium compute the fit.

Reservations give a billing discount, up to 72%, applied per hour

Azure Reservations provide a billing discount of up to 72% over pay-as-you-go for a one- or three-year commitment, applied automatically to matching resources without changing their runtime state. A reservation covers only the compute capacity (additional software, Windows licensing, networking, and storage are billed separately), and the discount is applied on an hourly basis: any hour without a matching resource forfeits that hour's benefit.

Trap Assuming a reservation covers Windows licensing, networking, and storage too, when it discounts only the compute capacity and those are billed separately.

19 questions test this

What cloud computing actually is

The shared responsibility model

Cloud deployment models: public, private, hybrid (and multicloud)

Public cloud

Private cloud

Hybrid cloud

Multicloud (awareness only)

CapEx vs OpEx and the consumption-based model

Capital expenditure (CapEx)

Operational expenditure (OpEx)

The consumption-based model

Cloud pricing models you should recognize

Serverless computing

Recognizing these questions on the exam

Shared responsibility patterns

Deployment-model patterns

Economics patterns

Serverless patterns

Public vs private vs hybrid cloud

Decision tree

Cheat sheet

Also tested in

References