ExamFinch.com My Study

Study guide

1.3 Cloud Computing Models and Shared Responsibility

Practice this exam

Google Cloud Digital Leader Exam

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 How to Prepare & Use This Guide 1.3 What Changed in the August 12, 2026 Exam Update

2 Digital Transformation with Google Cloud

1.1 Why Cloud Technology Is Transforming Business 1.2 Fundamental Cloud Concepts 1.3 Cloud Computing Models and Shared Responsibility 1.4 Agentic AI, Open Standards, and Google Cloud's Differentiators

3 Exploring Data Transformation with Google Cloud

2.1 The Value of Data 2.2 Google Cloud Data Management Solutions 2.3 Making Data Useful and Accessible 2.4 Data Types, the Data Supply Chain, and Interoperability

4 Innovating with Google Cloud Artificial Intelligence

3.1 AI and ML Fundamentals 3.2 Google Cloud's AI and ML Solutions 3.3 Building and Using Google Cloud AI and ML Solutions 3.4 Gemini, the Agent Platform, and the AI Hypercomputer

5 Modernize Infrastructure and Applications with Google Cloud — Part 1

4.1 Cloud Modernization and Migration 4.2 Computing in the Cloud 4.3 Serverless Computing

6 Modernize Infrastructure and Applications with Google Cloud — Part 2

4.4 Containers in the Cloud 4.5 The Value of APIs 4.6 Hybrid and Multi-Cloud

7 Trust and Security with Google Cloud

5.1 Trust and Security in the Cloud 5.2 Google's Trusted Infrastructure 5.3 Google Cloud's Trust Principles and Compliance 5.4 Google Threat Intelligence, Security Command Center, and Google SecOps 5.5 Securing the AI Stack: AI Protection, Model Armor, and Zero Trust

8 Scaling with Google Cloud Operations

6.1 Financial Governance and Managing Cloud Costs 6.2 Operational Excellence and Reliability at Scale 6.3 Sustainability with Google Cloud 6.4 Cloud Observability, SLIs, SLOs, and the Four Golden Signals

1.3 Cloud Computing Models and Shared Responsibility

Key Takeaways Explain This Topic AI

IaaS, PaaS, and SaaS sit on a spectrum: as the provider manages more, the customer trades control for speed

TCO, flexibility, management level, staffing, and lock-in all move predictably along the IaaS-to-SaaS spectrum

Matching a scenario to a model asks one question: do we differentiate by operating this layer? If yes, IaaS; if by what runs on it, PaaS; if the function is commodity, SaaS

Under the shared responsibility model, data and identity and access management always stay with the customer regardless of service model

Migration often reallocates security staff rather than eliminating them — OS patch roles shrink while app-security, IAM, and data-governance roles grow

Last updated: August 2026

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

Dimension IaaS PaaS SaaS

TCO Highest customer burden; lowest provider abstraction Lower; no OS or middleware staffing Lowest; no infra or platform staffing

Flexibility Highest — pick OS, library, anything Moderate — constrained to platform's runtimes Lowest — feature set fixed by vendor

Management level OS up Apps and data only Users and data only

Staffing / expertise Needs sysadmins, DBAs, patch cadence Devs focus on code; no OS patching Business admins; minimal IT

  • Speed to production Days to weeks Hours to days Minutes
  • Lock-in Lower (portable stacks) Higher (platform APIs) Highest (proprietary app)

Best fit Legacy lift-and-shift, custom runtime, regulated workloads needing OS control New apps, microservices, managed analytics, APIs Commodity business functions: email, CRM, HR

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:

  • Responsibility On-premises IaaS PaaS SaaS
  • Facilities (power, cooling) Customer Provider Provider Provider
  • Physical security Customer Provider Provider Provider
  • Hosts / hardware Customer Provider Provider Provider
  • Networking (physical) Customer Provider Provider Provider
  • Operating system Customer Customer Provider Provider
  • Middleware / runtime Customer Customer Provider Provider
  • Applications Customer Customer Customer Provider
  • Data Customer Customer Customer Customer
  • Identity & access management Customer Customer Customer Customer

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.