Shared Responsibility Model

What Is the Shared Responsibility Model?

The shared responsibility model is the conceptual contract that defines exactly which security controls Google operates and which security controls the customer operates when running workloads on Google Cloud. For the Cloud Digital Leader (CDL) exam, the shared responsibility model is the lens through which every other security topic — IAM, encryption, compliance, network security — should be viewed. Without it, customers either over-trust the cloud provider (assuming Google secures their data by magic) or under-trust the cloud provider (re-implementing controls that Google already provides for free). Both extremes lead to wasted effort, slower projects, and real security gaps.

The shared responsibility model exists because the cloud is not a single thing. When a customer runs a Compute Engine virtual machine, they are renting raw infrastructure: hardware, hypervisor, and a clean operating system image. When the same customer runs a query in BigQuery, they are renting a fully managed analytics service that handles everything from disk encryption to query optimization. The division of security work between Google and the customer is fundamentally different in those two scenarios — yet both are "Google Cloud." The shared responsibility model gives leaders a structured way to reason about the difference.

CDL candidates are not expected to write cloud-security policies or audit a hardened image. Instead, they are expected to understand the business-leader framing: "If we adopt this Google Cloud service, what stays my company's problem and what becomes Google's problem?" The answer changes depending on whether the service is Infrastructure as a Service (IaaS), Platform as a Service (PaaS), or Software as a Service (SaaS) — and the CDL exam loves to test which controls sit on which side of the line.

The Two Halves of the Model

At its simplest, the shared responsibility model splits cloud security into two halves: security OF the cloud (Google's job) and security IN the cloud (the customer's job).

Security OF the Cloud — Google's Half

Google is responsible for the physical and foundational layers of Google Cloud, no matter which service the customer uses. This half never shifts to the customer. It includes:

• Physical security of data centers — biometric access, perimeter fencing, on-site guards, dual-vendor power, climate control.
• Hardware — custom Titan security chips, server lifecycle management, secure hardware decommissioning.
• Hypervisor and host operating system — the layer that isolates one tenant's workloads from another's.
• Global private network — Google's backbone, including encryption in transit between data centers.
• Default DDoS protection — Google Front End absorbs and filters volumetric attacks before they reach customer workloads.
• Operating-system patching for managed services — the customer never sees or patches the host OS underneath BigQuery, Cloud Run, or Cloud Functions.

Security IN the Cloud — The Customer's Half

The customer is responsible for what they put into Google Cloud and how they configure it. This half never shifts to Google. It includes:

• Data classification — deciding what is sensitive, what is regulated, and what is public.
• Identity and access management — who has which roles on which resources. See Identity and Access Management (IAM) for the principal-role-resource model.
• Application code security — eliminating SQL injection, fixing dependency vulnerabilities, validating inputs.
• Authentication choices — whether to require 2-step verification, whether to federate with an external identity provider, whether to use security keys.
• Configuration of cloud resources — making sure a Cloud Storage bucket is not accidentally public, that a firewall does not allow 0.0.0.0/0 on port 22.

白話文解釋（Plain English Explanation）

The shared responsibility model can feel abstract because the dividing line is invisible — there is no signpost in the Google Cloud console that says "Google's responsibility stops here." But the model is much easier to grasp through real-world parallels. The three analogies below each highlight a different face of shared responsibility.

Analogy 1 — Renting an Apartment vs Staying in a Hotel vs Booking a Bed-and-Breakfast

Imagine you are visiting Taipei for a month and you have three lodging options. Each option assigns the work of "running the place" differently between you and the host. This is exactly how IaaS, PaaS, and SaaS differ.

Option A — Renting an unfurnished apartment (IaaS, like Compute Engine). The landlord owns the building, fixes the elevator, pays property taxes, and keeps the front door locked at night. But you bring your own bed, your own dishes, your own internet router. If a pipe leaks inside your unit at 2 a.m., the landlord might cover the structural repair, but the wet laptop is your problem. On Compute Engine, Google handles the building (hardware, hypervisor, network), but you handle the furniture (OS patches, application code, firewall rules, software dependencies).

Option B — Staying in a hotel (PaaS, like GKE or Cloud Run). The hotel staff cleans the room daily, restocks the soap, fixes the TV when it breaks, and patches the WiFi router after a security update. You still decide what to put in the safe and whom to give the key card to. On Cloud Run, Google patches the underlying OS and container runtime; you decide which container image to deploy, which IAM roles the service account holds, and which endpoints are public.

Option C — Booking a serviced bed-and-breakfast (SaaS, like BigQuery or Cloud Functions). Breakfast is cooked for you, the bed is made, the bathroom is cleaned, the laundry is taken away. Almost everything is done for you. You only have to decide what to order and whom to share the breakfast table with. On BigQuery, Google handles compute scaling, storage replication, disk encryption, OS patching, query optimization, and hardware refresh. You only manage what data you load, who can query it, and which queries to run.

The CDL exam likes to ask "which controls are Google's responsibility on <service>?" — the apartment-hotel-B&B mental model gives you a quick answer.

Analogy 2 — Flight, Hotel, and Restaurant Safety on an Overseas Trip

When you take a trip overseas, your personal safety relies on a chain of providers — and each provider draws the responsibility line differently.

On the airplane (IaaS). The airline is responsible for the aircraft's airworthiness, the pilots' training, the air traffic control coordination, and the cabin pressure. You are responsible for not bringing prohibited items, fastening your seatbelt, and following crew instructions. The airline cannot stop you from packing a bottle of perfume that exceeds liquid limits — that decision is yours. On Compute Engine, Google ensures the underlying VM platform is sound, but cannot stop you from running an unpatched WordPress install that exposes a vulnerable PHP version.

At the hotel (PaaS). The hotel handles the building, the locks, the surveillance cameras, the staff background checks, and the housekeeping. You are responsible for using the safe correctly, not leaving valuables on the desk, and not propping the door open for strangers. On GKE Autopilot, Google manages the control plane, node pools, OS patching, and Kubernetes upgrades; you are responsible for container image vulnerabilities, workload identity bindings, and exposing only the services that actually need ingress.

At a restaurant (SaaS). The restaurant chooses suppliers, cooks the food, washes the plates, and complies with food-safety regulations. You are responsible for telling them about your allergies and choosing what you eat. On Cloud Functions, Google scales the runtime, patches the language version, isolates each invocation, and handles availability; you are only responsible for what your function code does and who is allowed to invoke it.

The further "down the menu" a service sits (closer to SaaS), the more Google is doing on your behalf — and the more important it becomes that you focus the scarce remaining responsibility (data and IAM) correctly.

Analogy 3 — The Construction Site and the General Contractor

A more enterprise-flavored analogy: imagine your company is building a new headquarters in Taichung. Several layers of contractors share responsibility for the final building.

The land developer (Google's foundational layer). They cleared the land, laid the foundations, ran the underground utilities, and built the perimeter fence. They guarantee the building will not collapse. This corresponds to Google's data center physical security, hardware, hypervisor, and global network — controls the customer never sees and cannot modify.

The general contractor (Google's managed-service layer). For PaaS services like Cloud SQL or GKE Autopilot, Google plays the general contractor role — they assemble the structure, install the elevator, wire the building, and certify that everything meets code. You specify the floor plan and the finishes (which container, which database engine version), but you do not personally lay bricks or pull cables.

The interior designer and tenant (the customer). Once the building is handed over, your company decides which rooms become offices, who gets keys to which floors, what valuables go into the safe, and which doors stay locked overnight. No matter how well the building is constructed, if your company hands the master key to a stranger or leaves the safe wide open, the building's structural quality cannot save you. This is why even on the most managed Google Cloud service — say, BigQuery — the customer is still 100% responsible for IAM and data classification. Google built a perfect vault. You decide who walks in.

For real customer projects, the same three layers stack up. Cloud Storage gives you S-class steel walls, but you set the door policy. Cloud SQL gives you a hardened database engine, but you decide who can run DROP TABLE. The shared responsibility model is just the formal version of "who-builds-what-on-this-construction-site."

How the Line Shifts Across IaaS, PaaS, and SaaS

The single most important CDL concept around shared responsibility is that the division of work shifts depending on the service tier. The further "up the stack" the customer moves — from IaaS to PaaS to SaaS — the more responsibility Google absorbs, and the less the customer has left.

Compute Engine (IaaS)

Compute Engine is the closest Google Cloud service to traditional on-premises infrastructure. The customer rents raw virtual machines and is responsible for almost everything inside the VM.

• Google handles: physical hardware, hypervisor isolation, host OS patching, regional power and networking, default DDoS protection, encryption of the persistent disk at rest.
• Customer handles: guest OS patching (the Linux or Windows inside the VM), firewall rules (VPC firewall configuration), application code, third-party software installed on the VM, vulnerability scanning of installed packages, OS-level user accounts on the VM, endpoint protection (if needed).

For the CDL exam, remember the phrase "on Compute Engine, the OS is the customer's problem." It is the most-tested IaaS distinction. See Google Cloud Compute Options for how Compute Engine compares to GKE and Cloud Run.

Google Kubernetes Engine and Cloud Run (PaaS-ish)

GKE Autopilot and Cloud Run are managed platforms. Google operates the underlying infrastructure and most of the runtime layer; the customer focuses on container images and application code.

• Google handles: hardware, hypervisor, host OS, Kubernetes control plane (for GKE), node OS patching (for GKE Autopilot), Cloud Run runtime, scaling, load balancing, network isolation.
• Customer handles: container image security (no unpatched base images, no known-vulnerable libraries), application code, IAM bindings on the service account, secrets management, which endpoints are public, business logic correctness.

The key shift from Compute Engine is that the OS no longer belongs to the customer. On GKE Autopilot, you do not SSH into a node — you cannot, because Google is managing it for you. Your responsibility starts at the container image.

BigQuery, Cloud Functions, Cloud SQL (SaaS-ish)

BigQuery, Cloud Functions, and Cloud SQL are fully managed services. The customer's responsibility shrinks dramatically — almost everything below the data layer is Google's job.

• Google handles: hardware, hypervisor, OS, service runtime, scaling, replication, backups (for Cloud SQL), encryption at rest and in transit, query engine optimization, software patching of the service itself.
• Customer handles: data classification, IAM on datasets / tables / database instances, query patterns and cost, schema design, function code (for Cloud Functions), input validation.

For the CDL exam: on a fully managed service, the customer's remaining job is roughly "data and access management." That is also why IAM and data classification are always the customer's responsibility, regardless of service tier — they are the irreducible core that Google cannot make decisions about on your behalf.

Controls That Are Always Google's

A handful of controls never become the customer's responsibility, no matter which Google Cloud service is used. The CDL exam often tests these as a "Google always handles X" list.

Physical Data Center Security

Google operates its own data centers with multi-layer physical security: tall perimeter fencing, vehicle access controls, biometric badge readers, mantraps, 24-hour patrols, video surveillance with retained recordings, and locked server cages. No customer — even a Fortune 100 enterprise — has physical access to Google's facilities. This is one of the strongest arguments for cloud adoption: most on-premises data centers cannot match Google's physical controls.

Custom Hardware (Titan)

Google designs its own server hardware and includes the Titan security chip in every host. Titan provides a cryptographically verified hardware root of trust — every machine boots only software signed by Google. This is invisible to customers but underpins the integrity of every Compute Engine VM, every BigQuery slot, and every Cloud Run container.

The Hypervisor

The hypervisor is the software layer that isolates one tenant's workload from another's on shared hardware. Google's hypervisor is hardened, audited, and continuously updated by Google's security team. Customers cannot configure it and do not need to.

Encryption of Data at Rest by Default

Every byte of customer data stored in Google Cloud is encrypted at rest by default. This applies to Cloud Storage, Persistent Disks, BigQuery storage, Cloud SQL databases, Spanner, Firestore, and any other storage service. The customer does not need to enable this; it cannot be turned off. See Data Encryption and Protection for the full key-management story, including customer-managed encryption keys (CMEK).

Global Network and DDoS Protection

Google's private fiber backbone connects data centers worldwide. Traffic between regions travels on this private network, not the public internet. The Google Front End also provides default DDoS protection — volumetric attacks are absorbed before reaching customer load balancers or VMs. Customers can layer Cloud Armor on top for application-level WAF protection, but the underlying network-layer DDoS shield is always present.

Controls That Are Always the Customer's

Conversely, a handful of controls never shift to Google. These are the irreducible core of customer responsibility.

Data Classification and Sensitivity Labeling

Google does not know whether the spreadsheet you uploaded to Cloud Storage contains marketing slogans or unencrypted credit-card numbers. The customer must classify their own data (Public / Internal / Confidential / Restricted) and apply appropriate controls. Tools like Sensitive Data Protection (formerly Cloud DLP) can help discover and label sensitive data, but the classification policy belongs to the customer.

Identity and Access Management Decisions

Google provides the IAM service, but which principals get which roles on which resources is entirely the customer's call. If you grant roles/owner on the production project to a vendor's service account and the vendor's GitHub leaks the key, that is not a Google security incident — it is a customer IAM mistake.

Application Code Security

If your Cloud Run service contains a SQL-injection vulnerability or your Cloud Functions handler logs credit-card numbers to Cloud Logging, that is a customer code problem. Google secures the runtime, not the code that runs inside it.

Choosing Authentication Posture

The customer decides whether to require 2-step verification, whether to enforce security keys for admins, whether to federate with Active Directory or Okta, and whether to enable Access Context Manager conditions like "only allow access from managed devices." Google provides every option; the customer chooses the posture.

Google's "Shared Fate" Extension

In 2021 Google introduced Shared Fate as an extension of the traditional shared responsibility model. The motivation: shared responsibility models in the industry have historically been "we drew the line, the rest is your problem." Customers often felt abandoned at the line. Shared Fate says: Google will go further than just drawing the line — Google will actively help customers succeed on their side of the line.

What Shared Fate Adds

Shared Fate provides three categories of help that go beyond the bare responsibility split:

1. Pre-built best practices and blueprints — Google publishes reference architectures, Terraform modules, and the Cloud Architecture Framework so customers do not have to invent secure patterns from scratch.
2. Built-in security tooling — services like Security Command Center, Sensitive Data Protection, Risk Manager, and Assured Workloads help customers monitor, classify, and constrain their environments without buying third-party tools.
3. Compliance evidence and attestations — Google publishes audit reports (SOC 2, ISO 27001, PCI DSS, FedRAMP, etc.) that customers can use as evidence for their own auditors. See Compliance and Privacy for the certificate ecosystem.

Security Command Center

Security Command Center (SCC) is Google Cloud's centralized security and risk-management platform. It scans for misconfigurations, vulnerable workloads, and active threats across an organization. SCC Premium adds threat detection (Event Threat Detection, Container Threat Detection), vulnerability scanning, and compliance dashboards. For CDL purposes, SCC is the flagship Shared Fate tool — Google is not just telling you "secure your stuff," they are giving you a dashboard that tells you what is currently insecure.

Assured Workloads

Assured Workloads is a Google Cloud feature that enforces regulatory controls at the resource level — for example, "only allow this workload to run in US regions and only allow personnel with US citizenship to operate it." Assured Workloads is used by customers in regulated industries (US government, healthcare, financial services) who need cryptographic proof that controls are enforced rather than just documented. It is another example of Shared Fate: Google is not just telling you what FedRAMP requires, they are wiring the controls directly into the platform.

Practical Examples: Mapping Real Services

The fastest way to internalize the shared responsibility model is to walk through specific services and identify the line.

Example 1 — Hosting an E-Commerce Site on Compute Engine

A retail company runs its e-commerce platform on a fleet of Compute Engine VMs.

• Google's job: hardware, hypervisor, region availability, DDoS protection at the network edge, default disk encryption.
• Customer's job: Linux OS patching on each VM, firewall rules to expose only port 443 to the public, application code security (no SQL injection), TLS certificate management, database password rotation, IAM on the service accounts used by the VMs.

If a customer skips Linux patching for six months and an attacker exploits an unpatched OpenSSL vulnerability, that is a customer failure, not a Google failure.

Example 2 — Running the Same Site on Cloud Run

The same e-commerce company migrates to Cloud Run.

• Google's job: all of the above PLUS OS patching, runtime patching, container scaling, regional failover.
• Customer's job: container image hygiene (use a current Distroless base image, scan with Artifact Registry vulnerability scanning), application code security, IAM on the Cloud Run service account, deciding whether the service is publicly invocable or requires authenticated invocation.

The customer's surface area is smaller on Cloud Run than on Compute Engine — Google has absorbed the OS-patching responsibility. But the irreducible core (IAM, application code) remains the customer's.

Example 3 — Running Analytics on BigQuery

The same company loads order data into BigQuery for analysis.

• Google's job: essentially everything except data and IAM. Storage replication, encryption, query engine maintenance, hardware refresh, OS patching, scaling, backups.
• Customer's job: which datasets exist, what IAM bindings each dataset has, what SQL queries are run, how much money the queries are allowed to cost, whether sensitive columns are masked.

If a customer grants roles/bigquery.dataOwner on a sensitive dataset to a service account that gets compromised, the resulting data leak is a customer-side IAM failure — not a BigQuery security failure.

Common Misconceptions

For the CDL exam, recognize these incorrect mental models when they appear in scenario questions:

1. "Google encrypts my data, so I do not need to worry about who can read it." False. Encryption protects against physical theft of disks. It does not protect against legitimate IAM principals reading data they should not have access to. Encryption and IAM solve different problems.
2. "I am using a SaaS service, so Google handles all security." False. Even on the most managed service, data classification and IAM remain the customer's responsibility.
3. "DDoS protection requires me to subscribe to a paid product." Partially false. Default network-layer DDoS protection is included for free through the Google Front End. Cloud Armor adds paid application-layer WAF features on top.
4. "Compute Engine is more secure than Cloud Run because I control the OS." False. Control is not the same as security. On Cloud Run, Google patches the OS faster and more consistently than most customers can. The right framing is: control vs convenience, not control vs security.
5. "Shared responsibility means Google and I split everything 50/50." False. The split is not symmetric and shifts by service tier. On Compute Engine, the customer does most of the OS-and-above work. On BigQuery, the customer does very little.

How the Model Connects to Other CDL Topics

The shared responsibility model is the framework that ties together every other Google Cloud security topic.

• Identity and Access Management — IAM is the customer's primary tool on their side of the line. See Identity and Access Management (IAM).
• Data Encryption and Protection — encryption-at-rest is on Google's side by default; key management (CMEK / CSEK) is a Shared Fate option for customers who want more control. See Data Encryption and Protection.
• Compliance and Privacy — Google's compliance attestations cover Google's half; the customer must still produce evidence for their own half. See Compliance and Privacy.
• Cloud Value Proposition — a clear shared responsibility model is part of why cloud is faster than on-premises: customers spend less time on hardware-and-hypervisor work and more time on business logic.

Frequently Asked Questions

What is the difference between shared responsibility and shared fate?

Shared responsibility is the static contract that defines who owns which security control between Google and the customer. Shared fate is Google's commitment to actively help the customer succeed on their side of the contract — providing blueprints, built-in tools like Security Command Center, and compliance evidence so the customer does not have to figure everything out alone. Shared responsibility says "here is the line." Shared fate says "and we will help you stand on your side of it."

Does Google take responsibility for misconfigured Cloud Storage buckets?

No. Google provides safe defaults (new buckets are private by default), tooling (the Security Command Center's misconfiguration findings), and warning prompts (the console warns before making a bucket public). But the decision to set a bucket's IAM policy to allUsers is the customer's, and the resulting data exposure is a customer-side failure. The CDL exam treats bucket misconfiguration as a customer responsibility every time.

If I use BigQuery, am I responsible for patching anything?

No. BigQuery is a fully managed service. Google handles all OS patching, runtime patching, storage layer maintenance, and engine upgrades. Your remaining responsibilities are data classification (what is in the tables), IAM (who can query the tables), and query patterns (cost and performance). You never SSH into a BigQuery host because there is no concept of a BigQuery host from the customer's perspective.

Who is responsible for protecting against DDoS attacks?

Google provides default network-layer DDoS protection through the Google Front End — this is automatic, free, and applies to every Google Cloud workload. The customer is responsible for application-layer protection if their workload needs WAF rules, rate limiting, or geo-blocking. Cloud Armor is the paid Google Cloud product for application-layer DDoS and WAF protection. The CDL exam often tests this split: network-layer DDoS is Google's responsibility by default; application-layer WAF is a customer-configured Cloud Armor feature.

Does the shared responsibility model change if I move from Compute Engine to GKE Autopilot?

Yes — significantly. On Compute Engine, the customer owns OS patching, package management, and host-level vulnerability remediation. On GKE Autopilot, Google takes over node OS patching, Kubernetes control plane operation, and node lifecycle management. The customer's responsibility shrinks to container image hygiene, workload identity bindings, network policies, and the application code itself. CDL candidates should recognize this as the canonical example of "moving up the stack shifts more responsibility to Google."

Does Google read my data to provide the cloud service?

No. Google's terms commit to not using customer data for advertising or for training general AI models without consent. Google personnel cannot read customer data in transit or at rest under normal operations — all data is encrypted, and personnel access is gated by audited admin actions logged in Access Transparency. Customers who want stronger guarantees can enable Access Approval, which requires explicit customer authorization before Google support personnel can access customer data even during legitimate troubleshooting. See Compliance and Privacy for the privacy commitments in detail.

Summary: The Shared Responsibility Model as the Security Foundation

For the Cloud Digital Leader exam, the shared responsibility model is the foundational mental model that every other security topic builds on. Remember the two halves — Google secures OF the cloud (physical, hardware, hypervisor, global network, default encryption, OS-for-managed-services), and the customer secures IN the cloud (data classification, IAM, application code, authentication posture). Remember that the line shifts by service tier — on Compute Engine (IaaS), the customer owns the OS; on GKE Autopilot or Cloud Run (PaaS-ish), Google owns the OS; on BigQuery or Cloud Functions (SaaS-ish), Google owns nearly everything below the data layer. And remember that IAM and data classification are always the customer's job, regardless of how managed the service is.

Finally, recognize Shared Fate as Google's extension beyond the static contract — tools like Security Command Center, Assured Workloads, Sensitive Data Protection, and the Cloud Architecture Framework exist so customers do not have to operate their half alone. A CDL who can explain shared responsibility in business language — "Google handles the building and the elevators; we handle who gets the office keys and what we put in the safe" — is ready to advise stakeholders on which Google Cloud services fit which risk profile, and where the organization needs to invest in its own security capabilities.