Service Models & Shared Responsibility

One stack, three places to draw the line

Picture renting computing instead of owning a data center, then ask the question this whole topic turns on: how much of the machine do you still run yourself? IaaS, PaaS, and SaaS are just three answers to it, three points where Google takes over the lower layers and leaves the rest to you, and naming what each one hands off is most of what the exam wants here.

Every application runs on a stack of layers. From the bottom up: the physical hardware (servers, disks, power), the networking that connects it, the virtualization that slices one machine into many, the operating system (OS) (the base software that manages the machine), the runtime and middleware (the language and frameworks your code needs to run), the application itself, and finally your data. If you run everything on-premises (in your own data center), you own all of those layers.

The three cloud service models are simply three different points at which the provider takes over the lower layers and leaves the rest to you. Infrastructure as a Service (IaaS)^[1] hands off the bottom of the stack; Platform as a Service (PaaS)^[1] hands off everything up to where your code begins; Software as a Service (SaaS)^[1] hands off the entire stack and delivers a finished application. Google describes all three as "cloud service models" that differ in "the degree of management you're responsible for in your cloud environments."

Two consequences fall out of this one idea, and they run in opposite directions. The more layers you hand off, the less operational work and fewer specialist staff you need, but also the less control and customization you keep over the layers the provider now owns. Hold that single trade-off in mind; the rest of this page is just its details. The figure above stacks those layers and marks where each model draws its line: above the line stays yours, below it becomes Google's. (You may also meet Containers as a Service (CaaS) and Function as a Service (FaaS), which slot between IaaS and PaaS; the Cloud Digital Leader exam focuses on IaaS, PaaS, and SaaS.)

The application stack as one column; each model draws its hand-off line at a different layer, with everything above the line staying customer-managed.

The four points on the line, with a house analogy

This section walks each model from most to least customer-managed. Google's own teaching analogy is housing, which makes the hand-off concrete, so we use it throughout. The figure above lines up all four: the yellow customer band shrinks and the green Google band grows as you move from On-premises to SaaS.

On-premises: build the house yourself. You source the materials and tools and assemble everything. In IT terms you own the stack end to end, "from the hardware to your applications and scaling." Maximum control, maximum work.

IaaS: hire a contractor to build it. You rent the hardware to run your application on, "but you are responsible for managing the OS, runtime, scale, and all the data." This is the model with the highest level of control over infrastructure, which is why it suits teams that need a specific OS or are lift-and-shifting a legacy app. Google's example is Compute Engine^[1], its virtual-machine service.

PaaS: rent a furnished house. PaaS "lets you bring your own code and deploy it but leaves the server management and scaling up to the cloud provider." You still write the code and manage your data and apps; the provider patches and scales the platform beneath them. Google's examples are App Engine and Cloud Run^[1]. The trade is real: the platform stack can be limited and customization reduced.

SaaS: move into a finished house. SaaS "provides the entire application stack, delivering an entire cloud-based application that customers can access and use," complete with "all updates, bug fixes, and overall maintenance," usually through a web browser. You are still responsible "for taking care of your own data." Google's example is Google Workspace^[1]. Easiest to adopt, least control.

A few clarifications the exam rewards. First, the models are not mutually exclusive: Google notes you can "use a mix of all three along with more traditional IT infrastructure." Second, the cost shape is consistent: every cloud model replaces the up-front capital expense (CapEx) of buying hardware with an operating expense (OpEx) you pay as you go or by subscription, but lower total cost of ownership (TCO) also comes from needing fewer staff to operate the layers you handed off. Third, vendor lock-in is a stated risk of PaaS and SaaS, because provider-specific platforms and apps can be hard to leave.

Four points on the hand-off line; the customer-managed band shrinks and Google's grows from On-premises to SaaS, with Google's housing analogy beneath each.

Shared responsibility and shared fate

This section explains who secures what. Read it as the security view of the same hand-off line from the previous sections: wherever the provider stops managing a layer, you start securing it.

The cloud shared responsibility model divides security duties between Google and you, and the division depends on the service model. Two parts of the division never move, and they anchor every exam question on this topic: per Google, "the cloud provider always remains responsible for the underlying network and infrastructure, and customers always remain responsible for their access policies and data." In other words, Google always secures the physical hardware, data centers, and network; you always own your data and your access/identity policies (who may sign in and what they may do), no matter which model you choose.

What shifts is the middle of the stack. Under IaaS, "the bulk of the security responsibilities are yours, and our responsibilities are focused on the underlying infrastructure and physical security": you patch and secure the OS, runtime, and middleware. Under SaaS the split reverses: "we own the bulk of the security responsibilities. You remain responsible for your access controls and the data that you choose to store in the application." PaaS sits between the two. The diagram above shows this as the customer-responsibility band shrinking from top-to-bottom as you move IaaS → PaaS → SaaS, while the data and access band stays yours throughout. Google maps its products onto this line: IaaS examples are Compute Engine, Cloud Storage, and networking services such as Cloud VPN^[2]; PaaS examples are App Engine, Google Kubernetes Engine (GKE), and BigQuery^[2]; SaaS examples are Google Workspace and Google Security Operations^[2].

Google extends this with shared fate. As the doc puts it, "instead of shared responsibility, we believe in shared fate": Google takes "a more active role" by "building and operating a trusted cloud platform for your workloads." In practice that means secure-by-default resources and landing-zone blueprints, governance tooling, and a Risk Protection Program^[2] that pairs customers with cyber-insurance partners. The shift to remember is one of posture: shared responsibility draws a line and hands you your side; shared fate is Google partnering across that line to help you secure your side, rather than leaving you to it.

The customer-managed band shrinks toward SaaS; data and access stay customer-owned in every model. Based on Google Cloud's shared responsibility framework.

Exam-pattern recognition

This section names the question shapes the Cloud Digital Leader exam uses for this topic and the reasoning that picks the right answer.

Pattern 1: "who manages X?" A stem describes a layer ("the operating system," "the physical servers," "customer data") and a model, and asks who is responsible. Resolve it with the fixed anchors: hardware and network are always Google; data and access policies are always the customer. Only the middle (OS/runtime/middleware) depends on the model: customer under IaaS, Google under SaaS. A frequent distractor claims Google secures your data under SaaS; it does not, you always own your data.

Pattern 2: "pick the model for this scenario." Map the scenario's keywords to the hand-off line. "Need full control of the OS" or "migrate a legacy/specialized app as-is" -> IaaS (Compute Engine). "Developers want to deploy code without managing servers/scaling" -> PaaS (App Engine, Cloud Run). "Need a ready-to-use application, no infrastructure to manage" -> SaaS (Google Workspace). The decisive clue is how much of the stack the scenario says the customer wants to avoid managing.

Pattern 3: "least operational overhead / fewest staff." When the business goal is minimizing management effort or specialist headcount, the answer trends toward SaaS, then PaaS, because handing off more layers removes operational toil. Watch the inverse trap: if the requirement is maximum control or customization, the same logic points the other way, to IaaS.

Pattern 4: CapEx vs OpEx and TCO. A stem about "avoiding large up-front hardware purchases" or "shifting to a pay-as-you-go model" tests the CapEx-to-OpEx shift, which applies to all cloud models. If it adds "and reduce the staff needed to run it," lean toward the more managed models, since TCO includes operational staffing, not just the bill.

Pattern 5: shared responsibility vs shared fate wording. If the stem stresses Google taking "a more active role," secure-by-default blueprints, or a Risk Protection / cyber-insurance partnership, the intended term is shared fate. If it stresses a clean division of duties between provider and customer, the term is shared responsibility. They are related, not interchangeable: shared fate is Google's partnership posture layered on top of the shared responsibility division.

On-premises vs IaaS vs PaaS vs SaaS: management, responsibility, and tradeoffs

Dimension	On-premises	IaaS	PaaS	SaaS
Housing analogy	Build the house yourself	Hire a contractor to build it	Rent a furnished house	Move into a finished house
Provider manages	Nothing	Hardware, networking, virtualization	Hardware + the app dev/run platform	The entire application stack
You manage	Everything	OS, runtime, scaling, apps, data	Your code, apps, and data	Your data and user accounts
Google example	Your own data center	Compute Engine	App Engine, Cloud Run	Google Workspace
Control / customization	Total	High	Medium	Low
Operational burden / staffing	Highest	High	Lower	Lowest
Cost model	CapEx (buy hardware)	OpEx, pay-as-you-go	OpEx, pay-as-you-go	OpEx, subscription

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.

The three cloud service models differ by how much of the stack you hand off

IaaS, PaaS, and SaaS are not separate products but three points where the provider takes over the lower layers of a computing stack and leaves the rest to you. The single question behind all three is how much of the stack you want to manage yourself, which is why Google describes them as differing in "the degree of management you're responsible for."

Control and operational effort move in opposite directions across the models

As you move from IaaS toward SaaS you hand off more layers, so you do less operational work and need fewer specialist staff, but you also lose control and customization over the layers the provider now owns. IaaS gives the highest control over infrastructure at the cost of hands-on management; SaaS is the fastest to adopt but offers little to no control.

Trap Assuming a more-managed model like SaaS is strictly better, when the requirement is maximum control or customization of the OS or runtime, which points to IaaS instead.

3 questions test this

IaaS rents you the infrastructure but leaves you the OS and up

Infrastructure as a Service delivers on-demand compute, storage, networking, and virtualization, so you no longer run a data center, but you remain responsible for the operating system, runtime, scaling, and all data and apps. It suits teams that need a specific OS or are lift-and-shifting a legacy or specialized application. Google's example is Compute Engine.

13 questions test this

PaaS manages the platform so you only bring your code

Platform as a Service delivers and manages all the hardware and software needed to develop and run applications, so developers deploy their own code while the provider handles server management, patching, and scaling. You still write the code and manage your data and apps. Google's examples are App Engine and Cloud Run.

29 questions test this

SaaS delivers a finished application, you only manage your data

Software as a Service provides the entire application stack as a ready-to-use, fully managed application, including all updates, bug fixes, and maintenance, usually reached through a web browser with nothing to install. The customer's remaining job is taking care of their own data and user accounts. Google's example is Google Workspace.

6 questions test this

Match the model to how much the customer wants to avoid managing

Pick the model by the layers the scenario says the customer does not want to manage: needing OS or runtime control, or migrating a legacy app as-is, points to IaaS; wanting to deploy code without managing servers or scaling points to PaaS; needing a ready-to-use app with no infrastructure to manage points to SaaS.

Trap Choosing SaaS when the scenario requires running a specialized or legacy app that needs OS-level control, which only IaaS provides.

24 questions test this

All cloud models shift spending from CapEx to OpEx

Every cloud service model replaces the up-front capital expense (CapEx) of buying and refreshing data-center hardware with an operating expense (OpEx) paid as pay-as-you-go or subscription. This shift applies across IaaS, PaaS, and SaaS alike, so a stem about avoiding large up-front hardware purchases is testing the model category in general, not one specific model.

3 questions test this

TCO includes staffing, not just the cloud bill

Total cost of ownership counts the people needed to operate each layer, not only the invoice, so the more layers you hand off the lower the operational staffing cost. A goal of minimizing management effort or specialist headcount trends toward the more managed models (SaaS, then PaaS), because the provider absorbs the patching and operations toil.

Trap Reading "lowest cost" as "cheapest hourly rate" and picking IaaS, when a goal of fewest staff and least operational overhead favors a more managed model.

1 question tests this

A startup wants to minimize both its total cost of ownership and the technical staffing required to run an internal web application, while…

PaaS and SaaS carry a real vendor lock-in risk

Because PaaS and SaaS run on provider-specific platforms and applications, moving away later can be hard, which Google lists as a stated disadvantage of both. PaaS can also constrain you with a limited application stack and reduced customization. IaaS keeps more portability at the cost of more hands-on management.

The models are not mutually exclusive

An organization can combine IaaS, PaaS, and SaaS, and mix them with traditional on-premises IT, rather than committing to a single model. A scenario describing different workloads on different models is therefore normal, not a mistake to correct.

The shared responsibility model splits security at the management line

The cloud shared responsibility model divides security duties between the provider and the customer, and the split follows the same line as management: wherever the provider stops managing a layer, the customer becomes responsible for securing it. The exact division therefore depends on which service model is in use.

6 questions test this

Google always secures the hardware and network, no matter the model

Across every service model the cloud provider always remains responsible for the underlying network and physical infrastructure, including data centers and hardware. This part of the split never shifts, so any answer claiming the customer secures the physical servers or the provider network is wrong.

1 question tests this

A financial services company is evaluating container platforms and is concerned about security responsibilities. In the GKE shared…

You always own your data and access policies

In every service model the customer always remains responsible for their own data and their access and identity policies, meaning who can sign in and what they can do. Even under SaaS, where Google manages the whole application, your data and access controls stay yours.

Trap Believing the provider secures your data under SaaS because it manages the application; data protection and access control are always the customer's responsibility.

13 questions test this

The OS and runtime layer is what actually shifts between IaaS and SaaS

The middle of the stack, the OS, runtime, and middleware, is the part of the security split that moves with the model: it is the customer's responsibility under IaaS but the provider's under SaaS, with PaaS in between. Under IaaS the bulk of security responsibilities are the customer's; under SaaS they reverse to the provider.

9 questions test this

Shared fate is Google partnering across the responsibility line, not redrawing it

Shared fate is Google's posture of taking a more active role in helping customers secure their side of the shared responsibility split, through secure-by-default blueprints, governance tooling, and a Risk Protection Program that connects customers with cyber-insurance partners. It does not remove the customer's responsibilities; it adds provider partnership on top of the existing division.

Trap Treating shared fate as moving all security responsibility to Google; it is a partnership layered on top of shared responsibility, not a replacement for it.

FaaS (Cloud Functions) runs single-purpose event-driven code with no servers to manage

Function as a Service runs small, single-purpose pieces of code in response to events such as a Pub/Sub message or a file landing in Cloud Storage, with zero server or runtime management. Cloud Functions is Google's FaaS: it provisions and scales the infrastructure automatically, scales to zero when idle, and bills only while your code runs, so you pay nothing during quiet periods.

Trap App Engine is PaaS for whole apps; FaaS/Cloud Functions is the answer specifically for single-purpose, event-triggered code.

16 questions test this

Container orchestration (GKE) automates deploying, scaling, and managing containers

Container orchestration automatically deploys, scales, and manages containerized applications, which is what makes breaking a monolith into independently deployable microservices practical. Google Kubernetes Engine provides this managed Kubernetes, with Google running the control plane; GKE Autopilot goes further and fully manages the nodes too (provisioning, scaling, maintenance, and security patches) so teams without deep Kubernetes expertise can run containers at scale.

Trap Autopilot mode (not Standard) is the pick when the scenario stresses minimal operational burden and no in-house Kubernetes expertise.

8 questions test this

Google provides the capability, but the customer must configure and enable it

Across the shared responsibility model the customer is responsible for configuring the services they use: enabling high availability and disaster recovery on Cloud SQL, setting VPC firewall rules, and securing application code and container images on services like Cloud Run. Google supplies and secures the underlying capability and infrastructure, but turning it on and configuring it correctly is the customer's job.

Trap "Google provides it" does not mean Google enables it for you: features like Cloud SQL HA or firewall rules stay off until the customer configures them.

7 questions test this

Service Models & Shared Responsibility

One stack, three places to draw the line

The four points on the line, with a house analogy

Shared responsibility and shared fate

Exam-pattern recognition

On-premises vs IaaS vs PaaS vs SaaS: management, responsibility, and tradeoffs

Decision tree

Cheat sheet

Also tested in

References