Domain 1 of 3 · Chapter 3 of 3

Cloud Service Types

The three cloud service types as a layered stack

An app always runs on a runtime, an operating system, and hardware, and the only thing that changes across Azure's three service types is how far up that stack the provider takes over for you. Those three types, Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS), describe exactly how much of the stack the provider runs for you. Picture a stack of layers: physical hardware, virtualization, operating system, runtime/middleware, the application, and finally the data. The service type you choose draws a line through that stack: everything below the line is the provider's job, and everything at or above the line is yours.

With IaaS[1], the provider runs the physical hosts, storage, and networking; you supply and manage the operating system, any runtimes, the application, and the data. With PaaS[1], the provider also runs the operating system and the application-hosting platform, leaving you responsible for just your application code and its data. With SaaS[1], the provider runs the entire stack including the finished software, and you manage only your data, your user accounts, and your access settings.

The core trade-off to remember for the exam: as you move from IaaS to PaaS to SaaS you trade control for convenience. IaaS gives you the most control and the most management work; SaaS gives you the least control but almost no management overhead. There is no single 'best' type: the right choice depends on how much control a scenario actually needs.

IaaSPaaSSaaSthe datathe applicationruntime/middlewareoperating systemvirtualizationphysical hardwareYouYouYouYouProviderProviderYouYouProviderProviderProviderProviderYouProviderProviderProviderProviderProviderYou manageProvider managesresponsibility line
In each service type a line splits the stack: below it is the provider's job, at or above it is yours; the line rises from SaaS to IaaS. Based on the Microsoft shared responsibility model diagram.

Who manages what, and the canonical Azure examples

The fastest way to answer an AZ-900 service-type question is to know where the 'you manage' line sits and to recognize each tier's flagship Azure service.

Responsibility by service type

Layer IaaS PaaS SaaS
Data You You You
Application You You Provider
Runtime / middleware You Provider Provider
Operating system You Provider Provider
Virtualization, hosts, network Provider Provider Provider

Canonical Azure examples

The diagram below groups each service type with its flagship Azure services, the mapping the exam asks you to recognize.

Notice the constant across all three columns: your data is always yours to manage, no matter how high up the stack the provider goes. That data-always-yours rule is the first of a fixed set the customer keeps in every service type, detailed in the shared-responsibility section below.

IaaSPaaSSaaSAzure Virtual MachinesAzure Virtual NetworkAzure App ServiceAzure SQL DatabaseAzure FunctionsMicrosoft 365Dynamics 365
Flagship Azure services per type: Virtual Machines, Virtual Network (IaaS); App Service, SQL Database, Functions (PaaS); Microsoft 365, Dynamics 365 (SaaS).

How service type connects to the shared responsibility model

The cloud service types are inseparable from the shared responsibility model[1], which states that security and operational duties are split between the customer and the cloud provider, and that the split moves with the service type you choose.

What shifts and what stays

  • Moving from on-premises to IaaS hands the physical datacenter, hosts, and network hardware to Microsoft, but you keep the OS, applications, network controls, and identity configuration.
  • Moving from IaaS to PaaS additionally hands the operating system and the platform runtime to Microsoft, so you focus on the application and data.
  • Moving from PaaS to SaaS hands the application itself to Microsoft, leaving you almost nothing to operate.

Responsibilities you always retain

The data is always yours point from Who manages what above is the start of a fixed set: regardless of service type, the customer always keeps their data, plus their endpoints/devices, user accounts, and access management (identities and permissions). Microsoft is always responsible for the physical datacenter, physical network, and physical hosts. The middle layers (OS, network controls, applications) shift based on the service model. The diagram below sorts every responsibility into one of those three bands. This is exactly why AZ-900 questions pair 'who is responsible for X?' with a given service type: the answer changes depending on whether the scenario says IaaS, PaaS, or SaaS.

Always the customer's responsibilityDataEndpoints / devicesUser accountsAccess managementShifts with the service typeOperating systemNetwork controlsApplicationsAlways Microsoft's responsibilityPhysical datacenterPhysical networkPhysical hosts
Three bands: always the customer's (data, endpoints, accounts, access), shifting by service type (OS, network, apps), and always Microsoft's (physical layer).

Recognizing service-type questions on the exam

AZ-900 tests service types in a few predictable patterns. Learning to spot the stem wording lets you answer quickly.

Pattern 1: 'Which service type for this scenario?'

The stem describes a need and you map it to IaaS, PaaS, or SaaS:

Stem clue Correct answer Why
"full control of the operating system" / "lift-and-shift existing VMs" IaaS Only IaaS exposes the OS for you to manage.
"developers deploy code without managing servers/OS" PaaS PaaS abstracts the OS and runtime away.
"ready-to-use application accessed over the internet" / "email and collaboration" SaaS SaaS is finished software you just consume.

Pattern 2: 'Identify the example'

The stem names a product and asks for its type: Azure Virtual Machines → IaaS; Azure App Service, Azure SQL Database, or Azure Functions → PaaS; Microsoft 365 or Dynamics 365 → SaaS.

Pattern 3: 'Who is responsible?'

The stem gives a service type plus a task (e.g., patching the OS, securing the data). Apply the responsibility table: in IaaS the customer patches the OS; in PaaS Microsoft patches the OS; data is always the customer's responsibility.

Why distractors fail

A common trap offers 'IaaS' when the scenario explicitly says the team does not want to manage servers: that points to PaaS, not IaaS. Another trap offers 'PaaS' for a scenario describing a finished, off-the-shelf product like Microsoft 365: that is SaaS. Anchor on the verb in the stem: manage the OS → IaaS, deploy only code → PaaS, just use it → SaaS.

IaaS vs PaaS vs SaaS at a glance

AspectIaaSPaaSSaaS
You manageOS, runtime, apps, dataApps and data onlyData and access settings only
Provider managesPhysical hosts, virtualization, networkHosts, OS, runtime, scalingEverything incl. apps and OS
Control vs convenienceMost control, most upkeepBalancedLeast control, least upkeep
Azure exampleAzure Virtual MachinesAzure App Service, Azure SQL Database, Azure FunctionsMicrosoft 365, Dynamics 365
Best use caseLift-and-shift, OS-level controlBuild custom apps, no server managementReady-to-use software, fast adoption

Decision tree

Need OS-level control? Yes IaaS Azure Virtual Machines No Want to deploy code without managing servers? Yes PaaS Azure App Service No Want ready-to-use software you just consume? Yes SaaS Microsoft 365 No Reassess the need most workloads fit one of the three Control decreases and management overhead drops as you move IaaS → PaaS → SaaS; data stays your responsibility in all three.
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 services come in three types: IaaS, PaaS, SaaS

Cloud offerings fall into three service models (Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS)) distinguished by how much of the stack the provider manages versus you. IaaS is essentially renting datacenter hardware, PaaS adds a managed runtime platform on top, and SaaS is a finished application you simply use.

1 question tests this
Control drops, convenience rises moving IaaS to SaaS

Across IaaS → PaaS → SaaS you trade control for convenience: IaaS is the most flexible with maximum control and the largest operational responsibility, while SaaS is the least flexible but easiest to stand up and needs the least technical expertise. PaaS sits in the middle, splitting duties roughly evenly between you and the provider.

Trap Assuming SaaS gives the most control because the provider manages the most, when in fact SaaS gives the customer the least control and IaaS the most.

6 questions test this
IaaS: provider runs the hardware, you run the OS upward

Under IaaS the provider maintains only the physical hardware, internet connectivity, and physical security; you own everything else: operating-system install/config/patching, network configuration, and database/storage setup. You're essentially renting cloud hardware and what you do on it is up to you, which is why IaaS carries the heaviest operational load.

Trap Assuming the provider patches the guest operating system under IaaS, when OS install, configuration, and patching stay with the customer.

67 questions test this
PaaS: provider also runs the OS, middleware, and runtime

Under PaaS the provider maintains the physical infrastructure plus the operating systems, middleware, development tools, and managed runtimes, so you never handle OS or database licensing and patching. You focus only on your application code, data, and access controls: a complete development platform without maintaining the underlying infrastructure.

Trap Treating OS and runtime patching as the customer's job under PaaS, when the provider owns the operating system, middleware, and runtime there.

72 questions test this
SaaS: provider runs almost the whole stack

Under SaaS the provider manages almost the entire stack (infrastructure, platform, and the application itself, including updates and patching) giving customers the lowest operational overhead. You manage only your data, identity and access settings, and which devices may connect; you're essentially using a fully developed application.

Trap Assuming the customer has nothing to manage under SaaS, when the customer still owns their data, identities and access, and the devices allowed to connect.

9 questions test this
Azure Virtual Machines is the canonical IaaS example

Azure Virtual Machines and Azure Virtual Network are IaaS: you pick the VM image and size, then patch the guest OS and deploy your app yourself. This is the model for lift-and-shift migrations and for software with specific OS or driver dependencies that need operating-system-level control.

16 questions test this
App Service, SQL Database, and Functions are PaaS

Azure App Service (web apps and APIs), Azure SQL Database (managed relational database), and Azure Functions (serverless code) are PaaS: you supply code or schema and Microsoft handles the OS, runtime, patching, and scaling. App Service runs web apps "without worrying about managing the underlying infrastructure," and Functions runs your code without you deploying or maintaining servers.

Trap Classifying Azure App Service or Functions as IaaS because they run your code, when Microsoft owns the OS, runtime, and scaling, making them PaaS.

20 questions test this
Microsoft 365 and Dynamics 365 are SaaS

Microsoft 365 (email and productivity) and Dynamics 365 (CRM/ERP) are SaaS: fully developed applications you sign in to and consume over the internet, with no infrastructure or platform to maintain. Email, messaging, and finance/productivity apps are the classic SaaS scenarios.

2 questions test this
Choose IaaS for OS-level control or lift-and-shift

Pick IaaS when the scenario needs operating-system control, a lift-and-shift migration of existing servers with minimal change, or rapid spin-up/tear-down of dev-and-test environments while keeping full control. It's also the fit for software with specific OS or driver dependencies that a managed platform can't accommodate.

Trap Reaching for PaaS for a lift-and-shift migration of existing servers, when minimal-change migration and OS-level control point to IaaS.

19 questions test this
Choose PaaS to ship code without managing servers

Pick PaaS when developers want to build and deploy custom applications without patching, scaling, or otherwise managing the underlying servers: the provider supplies the development framework, and cloud features like scalability and high availability come built in. Analytics and business-intelligence tooling delivered as a service is the other classic PaaS use case.

Trap Picking IaaS when developers want to deploy custom code without managing servers, when avoiding server management points to PaaS.

25 questions test this
Choose SaaS for ready-to-use, off-the-shelf software

Pick SaaS when a finished, subscription-based product (email, CRM, office productivity) already meets the need and you want the fastest time to value with the least technical effort. There's nothing to build or maintain; you just sign in and use it.

Trap Reaching for PaaS to build an application when a finished off-the-shelf product like email or CRM already meets the need, which is the SaaS case.

5 questions test this
Service type sets where the shared-responsibility line falls

The shared responsibility model divides duties between customer and provider, and the dividing line shifts with the service type: IaaS places the most on you, SaaS the most on the provider, and PaaS distributes them roughly evenly. Identifying the service type in a question is what tells you who owns a given task.

3 questions test this
Data, identities, and devices are always the customer's

Regardless of IaaS, PaaS, or SaaS, the customer always owns the information and data stored in the cloud, the accounts and identities, and the devices allowed to connect. The provider always owns the physical datacenter, physical network, and physical hosts; only the layers in between shift by service type.

Trap Assuming the provider owns your data and identities under SaaS because it runs the application, when data, identities, and devices stay the customer's at every service type.

4 questions test this
OS patching ownership flips between IaaS and PaaS

OS patching ownership depends on the service type: in IaaS the customer patches the guest operating system, while in PaaS Microsoft handles OS (and database) patching and licensing. The identical task therefore has a different owner depending on which service type the question names.

Trap Assuming the provider patches the guest OS in IaaS the same way it does in PaaS, when OS patching is the customer's job under IaaS.

42 questions test this
Map the stem verb to the service type

Map the action in the question stem to the service type: "manage/control the OS" points to IaaS, "just deploy code" or "no servers to manage" points to PaaS, and "use ready-made software" points to SaaS. The verb describing how much the team wants to manage is the fastest tell.

2 questions test this
"No server management" rules out IaaS as the answer

When a scenario explicitly says the team does NOT want to manage servers, the OS, or patching, IaaS is the tempting wrong answer because it's the most familiar model, but the correct choice is PaaS (deploy your own code) or SaaS (use off-the-shelf software). IaaS always keeps OS management with the customer.

Trap Choosing IaaS when the scenario says the team does not want to manage servers or the OS, when avoiding that management rules IaaS out in favor of PaaS or SaaS.

3 questions test this
Azure SQL Database is PaaS, not IaaS

Azure SQL Database is a fully managed relational database-as-a-service in the PaaS category: Microsoft owns the host, patching, upgrades, and built-in high availability. That's distinct from running SQL Server yourself on an IaaS VM (SQL Server on Azure VMs), where you keep OS-level access and manage updates and HA.

Trap Treating Azure SQL Database as IaaS because it's a database: it's a managed PaaS service; only SQL Server installed on a VM is IaaS.

31 questions test this

Also tested in

References

  1. https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility
  2. https://learn.microsoft.com/en-us/azure/virtual-machines/overview
  3. https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-overview
  4. https://learn.microsoft.com/en-us/azure/app-service/overview
  5. https://learn.microsoft.com/en-us/azure/azure-sql/database/sql-database-paas-overview
  6. https://learn.microsoft.com/en-us/azure/azure-functions/functions-overview
  7. https://learn.microsoft.com/en-us/microsoft-365/enterprise/microsoft-365-overview
  8. https://learn.microsoft.com/en-us/dynamics365/get-started/intro-crossapp-index