1.3 Cloud Computing Models and Shared Responsibility

The Three Cloud Service Models

Cloud services fall on a spectrum of how much the provider manages for you:

• Infrastructure as a Service (IaaS) — provider delivers virtual machines (VMs), storage, networking; you manage the operating system (OS), middleware, apps, and data. Google Compute Engine is the canonical example.
• Platform as a Service (PaaS) — provider delivers a runtime, database, or framework; you manage apps and data. Cloud Run, App Engine, Cloud SQL, and BigQuery.
• Software as a Service (SaaS) — provider delivers a finished application; you just use it and manage your data. Gmail, Google Workspace, Salesforce.

The pattern: as you move IaaS to PaaS to SaaS, the provider manages more and you trade control for speed. The exam tests this tradeoff, not the buzzwords. A useful mental model is a slider: push it toward IaaS when you need maximum control over the runtime and OS, push it toward SaaS when the function is a commodity you would rather not operate at all. Most organizations end up using all three simultaneously — IaaS for legacy and specialized workloads, PaaS for new services and analytics, and SaaS for standard back-office functions such as email, HR, and customer relationship management (CRM). The skill the exam rewards is not memorizing definitions but matching a scenario to the right point on the slider and articulating which responsibility moves where.

Benefits and Tradeoffs of IaaS, PaaS, SaaS

Matching Business Scenarios to a Service Model

• Rehost a 15-year-old Java monolith unchanged → IaaS (lift-and-shift onto Compute Engine; refactor later).
• Build a new Go microservice with autoscaling and no patching worries → PaaS (Cloud Run).
• Need a managed relational database with backups and high availability built in → PaaS (Cloud SQL).
• Email and calendar for 5,000 employees → SaaS (Google Workspace).
• Run a specialized ML framework requiring kernel modules and custom CUDA drivers → IaaS (Compute Engine with GPUs).
• Customer support ticketing for a small startup → SaaS (no IT headcount to operate it).

The decision rule: ask "do we differentiate by operating this layer?" If yes, IaaS. If you differentiate by what runs on the layer but not the layer itself, PaaS. If the function is commodity, SaaS.

A second, equally important question is staffing. A team with deep sysadmin and DBA talent can extract value from IaaS by tuning the stack precisely; a team of pure developers gets more leverage from PaaS, which frees them to ship product. A small business with no IT headcount should default to SaaS for any commodity function, because operating that function in-house is pure overhead. Lock-in is the third lens: IaaS with portable stacks (Linux, standard runtimes, container images) keeps exit costs low; SaaS for a mission-critical workflow can create a strategic dependency worth negotiating carefully before adoption.

The Cloud Shared Responsibility Model

Responsibility for security is shared, but the split moves by model. The classic Google Cloud framing:

Two rows always stay with the customer: data and identity & access management. You can outsource the infrastructure, never the stewardship of your data and who can reach it. The exam repeatedly tests this — picking "the cloud provider secures my data" is the classic wrong answer.

Applying Shared Responsibility to Real Decisions

A retailer moving a custom Python e-commerce app from a colocation data center to Cloud Run (PaaS) keeps responsibility for: app code, dependency versions, data classification, IAM grants, and secrets. It hands to Google: facilities, host patching, runtime patching, autoscaling, and the network fabric. The CFO's question — "do we still need the on-call sysadmin?" — has a nuanced answer: the OS patch role shrinks, but app-security, IAM, and data-governance roles grow. Migration often reallocates security staff rather than eliminating them.