Cloud Computing Fundamentals
IaaS vs. PaaS vs. SaaS
The full responsibility split across all 3 service models side by side, the keyword cues that identify each one in a scenario, and the classic trap that catches learners who assume moving up the stack always means an upgrade.
- Compare the full responsibility split across IaaS, PaaS, and SaaS, layer by layer
- Apply keyword cues to identify the correct service model in a scenario
- Explain why moving up the stack trades control for convenience rather than simply improving
- Evaluate a scenario against its constraints to select the service model that fits
Naming them is easy. Telling them apart is the actual skill
You can now define IaaS, PaaS, and SaaS individually. That is not, on its own, a useful skill: almost nobody hands you a service and asks "what is this?" in isolation. What actually gets tested, on an exam and on the job, is a scenario with constraints, a team, a deadline, a compliance requirement, and the question of which of the 3 models fits it. That is where this lesson spends its effort.
The full stack, side by side
| Layer | IaaS | PaaS | SaaS |
|---|---|---|---|
| Networking, servers, virtualization | Provider | Provider | Provider |
| Operating system | You | Provider | Provider |
| Runtime and middleware | You | Provider | Provider |
| Application code | You | You | Provider |
| Data and your own configuration | You | You | You |
Read the table by column instead of by row and the pattern is obvious: each step from IaaS to SaaS moves exactly one more layer from "you" to "provider." Data and your own configuration are the only row that never moves, no matter which model you pick.
The trap: this is a tradeoff, not a ranking
It is tempting to read that table left to right and conclude SaaS is simply the best model, since the provider does the most work. That conclusion is wrong, and it is exactly the trap an exam question sets. What SaaS gains in convenience, it spends in control. You cannot install a custom library on Gmail's servers, run your own code on Salesforce's infrastructure, or choose a different kernel version for Microsoft 365. IaaS gives you all of that control back, at the cost of doing the OS, runtime, and application management yourself. Neither end of the table is "better." Each one fits a different set of constraints.
Keyword cues for scenarios
Exam scenarios rarely say "IaaS" or "PaaS" directly. They describe a constraint, and the constraint points at the model.
| The scenario says... | Points to |
|---|---|
| "Full control of the operating system," "specific kernel version," "root access" | IaaS |
| "Just deploy the code," "no server management," "focus on the application" | PaaS |
| "No installation," "use it out of the box," "no developers on staff" | SaaS |
Worked example: 2 scenarios, 2 answers
A 12-person sales team needs a working CRM by next week and has no developers on staff to build one. Nothing about this scenario mentions code, infrastructure, or customization beyond configuration. That absence is the cue: this is a SaaS scenario, and a tool like Salesforce is the fit, not something a team builds from scratch.
Now change the constraint. A fintech company operates under a regulation that requires it to control the exact OS patch level running on every server, down to the kernel version, and to apply security patches on its own schedule rather than a vendor's. PaaS and SaaS both take the operating system out of the customer's hands, which is precisely the control this regulation demands. That single requirement rules out both, and leaves IaaS as the only model that fits.
Same underlying question in both cases: how far up the stack does this scenario require you to reach. The sales team's answer is "not at all." The fintech company's answer is "all the way down to the kernel."
The connection to shared responsibility
This same layer-by-layer split is the foundation of the shared responsibility model, covered in full in this course's Security and Reliability domain. What you are learning here, which layer belongs to you and which belongs to the provider, is the exact question that model answers for security specifically. You are not learning a new idea there. You are applying this one to a new question.
Where this leaves you
One question separates these 3 models in any scenario: how far up the stack does the situation require the provider to go. Root access and kernel control pull you toward IaaS. A focus on shipping code with no server management pulls you toward PaaS. No installation and no in-house developers pulls you toward SaaS. The next topic in this domain leaves the service models behind and moves to the building blocks every one of them runs on: regions, compute, storage, databases, and networking.