IaaS Explained: Cloud Service Models and Who Patches What

Infrastructure as a Service (IaaS) is the cloud model where a provider rents you virtualized computing resources — servers, storage, and networking — and everything above that layer is yours to manage. You choose and install the operating system, apply its patches, and run your own applications, while the provider keeps the physical hardware, hypervisor, and data center running. Think of it as leasing an empty server that happens to live in someone else’s building: maximum control, maximum responsibility.

What IaaS actually gives you

When you spin up an IaaS resource, you are provisioning virtual machines (VMs), block or object storage, virtual networks, firewalls, and load balancers — cloud counterparts of the physical routers, switches, and access points an on-premises network needs — from a shared pool of physical hardware. The provider’s hypervisor slices its real servers — datacenter-grade machines with redundant hot-swap power supplies — into isolated virtual ones and hands you the keys.

Two characteristics define the model on the 220-1201 exam:

• You manage the OS and everything above it. You pick the operating system image, harden it, patch it, and install whatever software the workload needs. The provider never touches your guest OS.
• You pay for what you consume. IaaS billing is metered — per hour or second of compute, per gigabyte of storage, per unit of data transferred. There is no need to buy hardware up front, and capacity can scale up or down on demand.

That combination — rented virtual infrastructure plus customer-managed operating systems, on a pay-as-you-go meter — is the fingerprint that identifies IaaS in any scenario question.

The three service models compared

Cloud service models differ by where the line of responsibility sits between you and the provider. Platform as a Service (PaaS) moves that line up: the provider manages the OS and runtime so developers just deploy code. Software as a Service (SaaS) moves it to the top: the provider runs the entire application and you simply log in and use it.

	IaaS	PaaS	SaaS
Provider manages	Hardware, hypervisor, physical network	Hardware + OS, runtime, middleware	Everything, including the application
You manage	OS, patches, middleware, apps, data	Your application code and data	Your data, user accounts, settings
Who patches the OS	You	Provider	Provider
Typical example	Rented VMs running your servers	Managed database or app-hosting platform	Web-based email or office suite
Control level	Highest	Medium	Lowest

A useful memory hook: the “aaS” letters tell you what arrives ready-made. In IaaS only the infrastructure is ready; in PaaS the whole platform (OS included) is ready; in SaaS the finished software is ready.

The shared responsibility model: who patches what

Patching is where exam questions get specific, because responsibility genuinely splits differently per model.

In IaaS, the provider patches what it owns: hypervisor software, host firmware, and the physical network gear. The customer patches the guest operating system, any middleware, and every application installed on the VM. If a Windows Server VM in the cloud misses a critical update, that miss belongs to the customer — the provider has no visibility into, or duty toward, your guest OS.

In SaaS, the provider patches the entire stack — infrastructure, OS, and the application itself. Customers of a SaaS email platform never install an update; their responsibilities shrink to managing their own data, credentials, and access policies.

So when one company runs a workload on IaaS VMs and also subscribes to SaaS email from the same provider, the audit answer is: the company patches the OS and applications on its IaaS VMs, while the provider handles all patching for the SaaS service. Same vendor, two different responsibility splits — the model, not the provider, determines who patches.

When IaaS is the only correct answer

Some requirements can only be met with full OS control, and the exam loves testing this discrimination:

• Custom kernel modules or drivers. Installing a kernel module means modifying the operating system itself. That is impossible when the provider owns the OS (PaaS/SaaS), so any compliance or technical requirement demanding kernel-level changes forces IaaS.
• Unsupported or legacy operating systems. If an application needs an OS version no managed platform offers, IaaS lets you install exactly what you need.
• Full-stack security hardening. Organizations that must apply their own OS baselines, agents, and audit tooling need the root/administrator access only IaaS grants.

The flip side is worth remembering: choosing IaaS for its control means accepting its operational burden. Backups of the guest OS, patch schedules, antivirus, and configuration management are all customer jobs.

Recognizing IaaS in scenario language

Real deployments rarely announce their service model, so learn the phrasing that signals it. “The company rents virtual machines and installs its own operating system” is IaaS. “The team configures, patches, and secures the servers itself while the provider supplies only compute, storage, and network” is IaaS. Contrast that with “developers deploy code without managing servers” (PaaS) and “users access the application through a browser with no installation” (SaaS).

Cloud deployment models — public, private, hybrid, community — are a separate axis entirely. A private cloud can serve IaaS; a public cloud can serve all three. Don’t let a question about where the cloud lives distract you from what layer of service it delivers. For the broader picture of how cloud topics fit into the exam, see the 220-1201 study guide. Cloud questions are the cheapest points on the exam once the phrasing is familiar, and A+ Core 1 practice questions build that familiarity fast.

How the 220-1201 exam tests this

• Definition match: a description of “virtualized servers, storage, and networking where the customer manages the OS and applications” and four model names as options. The customer-managed OS clause is the giveaway — answer IaaS.
• Scenario identification: a business “rents VMs and installs its own OS, patches, and applications,” or runs a backend it “configures, patches, and secures itself” on provider-supplied compute. Both describe IaaS; the distractors are PaaS, SaaS, and sometimes DaaS.
• Forced-choice by requirement: a team must install a custom kernel module, boot a specific OS build, or meet a compliance rule requiring OS control. Only IaaS satisfies it, because every other model puts the OS in the provider’s hands.
• Responsibility split: a company uses IaaS for one workload and SaaS for another and asks who patches what. Correct answer pattern: customer patches OS/apps on IaaS; provider patches everything in SaaS. Any option claiming the provider patches an IaaS guest OS, or that the customer patches a SaaS application, is wrong.

Quick reference

• IaaS = provider supplies virtual servers, storage, and networking; customer supplies and manages the OS and applications.
• Hallmark IaaS traits: customer-controlled operating system and metered, pay-as-you-go scalable resources.
• IaaS patching split: provider patches hardware and hypervisor; customer patches guest OS, middleware, and apps.
• SaaS patching: provider patches the whole stack; customer manages only data, accounts, and settings.
• PaaS sits between: provider manages the OS and runtime; customer manages code and data.
• Kernel modules, custom OS builds, or OS-level compliance controls → IaaS is mandatory.
• Scenario keywords for IaaS: “rents virtual machines,” “installs its own OS,” “patches and secures the servers itself.”
• Service model (IaaS/PaaS/SaaS) and deployment model (public/private/hybrid) are independent questions — don’t conflate them.