1.1.2. The Shared Responsibility Model
💡 First Principle: In any cloud service model, security and operational responsibility split at a line — and that line moves depending on which service model you chose in 1.1.1. Knowing where the line sits tells you whether a security or reliability gap is Google's problem to fix or yours.
Google always owns the physical layer: data center security, hardware maintenance, the underlying network fabric, and the hypervisor. From there, the split moves up the stack as you move from IaaS to SaaS. On Compute Engine, you're responsible for OS patching, firewall configuration, and application-level security — Google secures the rack, you secure everything running on it. On a fully managed service like BigQuery, Google manages patching and infrastructure security, and your responsibility narrows to data access controls (IAM) and the queries and data you put in.
This isn't just a security concept — it directly explains why IAM configuration appears throughout every other exam domain regardless of which service is being discussed. No matter how much of the stack Google manages for you, controlling who can access it always remains your responsibility, in every service model, without exception.
⚠️ Exam Trap: A common exam pattern presents an incident (a leaked credential, an overly permissive bucket) and asks "whose responsibility was this?" The answer is almost always yours if it involves identity, access control, or data configuration — Google's share of the model never covers how you configured access to your own resources.
Reflection Question: If a BigQuery dataset is exposed to unauthorized users because of a misconfigured IAM policy, is that a Google Cloud platform failure or a customer responsibility failure — and would the answer change if the same dataset were instead running as a self-managed database on a Compute Engine VM?
