This chapter covers the Shared Responsibility Model (SRM) on Google Cloud Platform (GCP), a foundational concept for the Google Cloud Digital Leader (GCDL) exam. The SRM defines which security responsibilities belong to Google and which belong to the customer, varying by service type (IaaS, PaaS, SaaS). Approximately 10-15% of GCDL exam questions touch this topic, often in scenarios about compliance, data protection, or incident response. Mastering the SRM helps you answer questions about who is accountable for what, especially in multi-cloud or hybrid environments.
Jump to a section
Imagine you lease office space in a commercial building. The landlord owns the building structure, common areas, and external security like locks on the main doors and fire suppression systems. You, as the tenant, are responsible for securing your own office suite — locking your internal doors, setting up your own alarm system, controlling who has keys to your specific rooms, and managing access to the data and equipment inside. If there is a break-in, the landlord ensures the building perimeter is intact, but they cannot be blamed if you left your office door unlocked. Similarly, in cloud computing, the cloud provider (like GCP) secures the physical infrastructure, network, and hypervisor, while the customer secures their data, identities, and access configurations. If a customer misconfigures a firewall rule or leaves a bucket publicly accessible, it is their responsibility, not the provider's. The shared responsibility model formalizes this division: the provider is responsible for security OF the cloud, and the customer is responsible for security IN the cloud. Understanding this boundary is critical for compliance, auditing, and incident response.
What Is the Shared Responsibility Model?
The Shared Responsibility Model (SRM) is a security framework that delineates the security obligations of the cloud service provider (CSP) and the customer. For GCP, Google is responsible for the security OF the cloud, meaning the physical infrastructure, networking, hypervisor, and underlying services. The customer is responsible for security IN the cloud, meaning their data, identities, access policies, and configurations. The exact split depends on the service model: Infrastructure as a Service (IaaS), Platform as a Service (PaaS), or Software as a Service (SaaS).
Why Does the SRM Exist?
Before cloud computing, an organization owned and operated its entire stack — from physical servers to application code. In the cloud, the provider takes over parts of that stack. The SRM clarifies boundaries to avoid security gaps where neither party acts. For example, if a data breach occurs due to an unpatched operating system vulnerability, who is at fault? In IaaS, the customer patches the OS; in PaaS, Google patches the OS. The SRM assigns these responsibilities explicitly.
How Google Implements the SRM
Google's infrastructure is built on a custom-designed, multi-layer security model. The physical security of data centers (e.g., biometric access, 24/7 guards) is Google's responsibility. The network security — including firewalls, DDoS protection, and encryption in transit — is also Google's domain. The hypervisor (Google's proprietary, stripped-down Linux kernel) isolates virtual machines. For customer data, encryption at rest is offered by Google (using AES-256 with key management options), but managing encryption keys, bucket policies, and IAM roles falls to the customer.
Responsibility by Service Type
- IaaS (e.g., Compute Engine VM): Google secures the physical host, network, and hypervisor. The customer secures the guest OS, applications, data, firewall rules (VPC firewall), and IAM policies. The customer must patch the OS, configure firewalls, and manage SSH keys. - PaaS (e.g., Cloud SQL, App Engine): Google secures the runtime environment, OS, and middleware. The customer secures the application code, data, IAM roles, and network configurations (e.g., private IP, authorized networks). For Cloud SQL, Google manages database patching, but the customer must set strong passwords and manage user access. - SaaS (e.g., Google Workspace, Cloud Identity): Google secures the entire application stack. The customer secures user accounts, data classification, and sharing settings. For example, in Google Workspace, Google ensures the application is secure, but the customer must enable 2FA and manage sharing permissions.
Key Components and Defaults
- IAM (Identity and Access Management): Customers define who (user) has what access (role) to which resource. Default: no access is granted; all access must be explicitly granted. - VPC Firewall Rules: Customers control ingress and egress traffic to VMs. Default: default VPC has implicit allow rules for internal traffic and an explicit deny for all inbound traffic from outside. - Cloud KMS (Key Management Service): Customers manage encryption keys. Google offers default encryption at rest using Google-managed keys, but customers can use customer-managed keys (CMEK) or customer-supplied keys (CSEK). - Cloud Audit Logs: Google logs admin activity by default (retained for 400 days). Customers must enable data access logs separately.
Configuration and Verification
To verify responsibilities, use the Google Cloud console or gcloud commands. For example, to list IAM policies:
gcloud projects get-iam-policy [PROJECT_ID]To check firewall rules:
gcloud compute firewall-rules listTo view audit logs:
gcloud logging read "logName=projects/[PROJECT_ID]/logs/cloudaudit.googleapis.com%2Factivity"Interaction with Compliance
The SRM directly impacts compliance certifications (e.g., SOC 2, ISO 27001, PCI DSS). Google provides a shared responsibility matrix for each certification. For example, under PCI DSS, Google is responsible for the security of the underlying infrastructure, but the customer must ensure their applications and data handling comply with cardholder data protection requirements. Google's compliance reports (e.g., SOC 2 Type II) cover only the provider's portion; customers must audit their own controls.
Common Misunderstandings
- Myth: Google is responsible for all security in the cloud. Reality: Google is responsible for security OF the cloud; the customer is responsible for security IN the cloud. - Myth: In PaaS, the customer doesn't need to worry about security. Reality: The customer still manages data, access, and application-level security. - Myth: The SRM is static. Reality: It varies by service, deployment model (public, private, hybrid), and even by specific features (e.g., Cloud Run vs. Compute Engine).
Identify Service Model Type
Determine whether the service is IaaS, PaaS, or SaaS. This dictates the baseline split of responsibilities. For example, a Compute Engine VM (IaaS) means the customer patches the OS, while Cloud SQL (PaaS) means Google patches the database engine. Use the service documentation to confirm the model.
Assess Customer Data Sensitivity
Classify the data that will be stored or processed. If it is sensitive (e.g., PII, PHI), the customer must implement additional controls like encryption with customer-managed keys, data loss prevention (DLP), and access transparency. Google provides tools like Cloud DLP and Cloud KMS, but the customer must configure and use them.
Configure IAM and Access Policies
Define who can do what. Use the principle of least privilege. Create custom roles if predefined roles are too permissive. For example, a service account for a Compute Engine VM should have only the permissions needed (e.g., `roles/storage.objectViewer` to read from a bucket). Verify with `gcloud projects get-iam-policy`.
Set Up Network Security
Configure VPC firewall rules and Cloud Armor for DDoS protection. For example, allow only specific source IP ranges to SSH into VMs. Use private Google access to avoid exposing resources to the internet. Verify with `gcloud compute firewall-rules list`.
Enable Logging and Monitoring
Turn on audit logs for data access (admin activity is logged by default). Use Cloud Monitoring to set alerts for suspicious activity. For example, create a metric-based alert for excessive failed login attempts. Verify logs in the Logs Explorer.
Consider a healthcare organization deploying a HIPAA-compliant application on GCP. They use Compute Engine VMs (IaaS) to run their application and Cloud SQL (PaaS) for patient records. Under the SRM, Google is responsible for the physical security of data centers, network infrastructure, and hypervisor isolation. The customer must secure the guest OS (patching, hardening), manage firewall rules to restrict access to the database, and encrypt data at rest using CMEK (customer-managed encryption keys) stored in Cloud KMS. They also enable data access audit logs to track who reads patient records. A common mistake is assuming Google automatically encrypts all data with customer-managed keys; in reality, default encryption uses Google-managed keys, and the customer must explicitly create and assign a CMEK for the Cloud SQL instance. If the customer fails to restrict the VPC firewall, the database may be exposed to the internet, leading to a breach — a customer responsibility.
Another scenario: A startup uses Google Workspace (SaaS) for email and collaboration. Google secures the application, servers, and network. The startup must manage user accounts, enable 2FA, and control sharing settings. A misconfiguration like allowing external sharing of sensitive documents is the startup's fault. In a SOC 2 audit, the startup must demonstrate controls over user access and data sharing; Google provides a SOC 2 report for its portion, but the startup must have its own controls.
A third scenario: A financial services company uses BigQuery (PaaS) for analytics. Google secures the infrastructure, but the customer must manage IAM roles (e.g., who can query datasets), set up VPC Service Controls to prevent data exfiltration, and use Cloud DLP to mask sensitive data. If a customer grants roles/bigquery.dataViewer to a broad group, they risk unauthorized data access. Performance considerations include query costs and slot management, but security misconfigurations are the primary risk.
The GCDL exam tests the Shared Responsibility Model under objective 2.5 (Infrastructure: Identify the security responsibilities of the customer vs. Google Cloud). Expect 2-3 questions where you must determine who is responsible for a specific security task. The most common wrong answer is choosing 'Google' for tasks that are actually customer responsibilities, such as patching the guest OS in a Compute Engine VM, configuring firewall rules, managing encryption keys, or setting IAM policies. Candidates often confuse default encryption (Google-managed) with customer-managed encryption. Another trap: assuming that in PaaS (e.g., App Engine), Google manages all security — but the customer still manages application code, data, and access. Also, remember that for SaaS (e.g., Google Workspace), the customer manages user accounts and sharing, not the underlying infrastructure.
Key numbers: Google retains admin audit logs for 400 days by default; data access logs must be enabled. Default encryption at rest uses AES-256 with Google-managed keys. The SRM is documented in the Google Cloud Security Foundations Guide. Edge cases: For hybrid cloud (e.g., Anthos), the customer is responsible for the on-premises portion, including hardware and networking. For third-party software on Google Cloud (e.g., a marketplace VM), the customer is responsible for the software's security. The exam may also ask about compliance: Google's responsibility is to maintain certifications for its infrastructure; the customer must maintain compliance for their use of the services.
To eliminate wrong answers, ask: 'Is this about physical infrastructure, network, or hypervisor?' If yes, it's Google. If it's about data, access, or configuration, it's the customer. For managed services, think about what the customer can actually control in the console — if they can configure it, it's their responsibility.
Google is responsible for security OF the cloud (physical, network, hypervisor).
Customer is responsible for security IN the cloud (data, access, configurations).
Responsibility split varies by service model: IaaS, PaaS, SaaS.
Default encryption at rest uses Google-managed keys (AES-256).
Admin activity logs are enabled by default (retained 400 days); data access logs must be enabled.
Customers must configure IAM, VPC firewall rules, and encryption keys.
Compliance certifications (e.g., SOC 2) cover only Google's portion; customers must audit their own controls.
These come up on the exam all the time. Here's how to tell them apart.
IaaS (e.g., Compute Engine)
Customer patches guest OS and middleware.
Customer manages firewall rules for VMs.
Customer configures encryption for boot disks.
Google secures hypervisor and physical host.
Customer must manage SSH keys and user accounts on VMs.
PaaS (e.g., Cloud SQL)
Google patches the database engine and OS.
Customer manages authorized networks and IAM.
Customer can use CMEK for database encryption.
Google secures runtime environment and infrastructure.
Customer manages database user accounts and passwords.
Mistake
Google is responsible for all security in the cloud.
Correct
Google is responsible for security OF the cloud. The customer is responsible for security IN the cloud, including data, access, and configurations.
Mistake
In PaaS, the customer doesn't need to manage security.
Correct
The customer still manages application security, data access, IAM policies, and encryption keys. Google manages the runtime and OS.
Mistake
Default encryption at rest uses customer-managed keys.
Correct
Default encryption uses Google-managed keys. Customers must explicitly use CMEK or CSEK for customer-managed keys.
Mistake
Audit logs are automatically enabled for all activities.
Correct
Admin activity logs are enabled by default; data access logs must be manually enabled and incur additional costs.
Mistake
The SRM is the same for all services.
Correct
It varies by service model (IaaS, PaaS, SaaS) and even by specific service features (e.g., Cloud Run vs. GKE).
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The customer is responsible. Compute Engine is an IaaS service; the customer manages the guest OS, including applying security patches. Google patches the hypervisor and physical host. Use OS Patch Management or custom scripts to automate patching.
Yes, by default, Google Cloud Storage encrypts all data at rest using AES-256 with Google-managed keys. Customers can optionally use customer-managed encryption keys (CMEK) or customer-supplied keys (CSEK) for additional control.
Admin activity logs record operations that modify configurations or metadata (e.g., creating a VM). They are enabled by default and retained for 400 days. Data access logs record reads and writes of customer data (e.g., reading a Cloud Storage object). They must be enabled separately and may incur additional costs.
The customer is responsible for managing user accounts, authentication methods (e.g., enabling 2FA), data classification, sharing settings, and compliance with data protection regulations. Google secures the application infrastructure.
Google provides a shared responsibility matrix for each certification. Google is responsible for the security of its infrastructure and provides compliance attestations (e.g., SOC 2, ISO 27001). The customer must implement and audit their own controls over data, access, and configurations to achieve compliance.
That is a customer responsibility. Google provides the tools (VPC firewall rules) but does not enforce security policies. The customer must correctly configure rules to restrict access. A misconfiguration can lead to data exposure or unauthorized access.
Yes, certain areas are shared, such as encryption (Google provides infrastructure for encryption, customer manages keys) and access control (Google provides IAM, customer defines policies). However, the ultimate accountability for data security lies with the customer.
You've just covered Shared Responsibility Model on GCP — now see how well it sticks with free GCDL practice questions. Full explanations included, no account needed.
Done with this chapter?