What's changed: Created Professional Cloud Security Engineer Chapter 5 (Domain 5 "Compliance": determining technical needs, shared responsibility model, scoping, mapping requirements to services/controls, Access Transparency/Access Approval; Assured Workloads, organization policies (pre-built/custom), regionalization of data and services (resource location constraint), network/access segmentation, audit-log coverage).
5.1Regulatory requirements and the shared responsibility model
Understand determining technical needs for compute/data/network/storage, evaluating the shared responsibility model, identifying the Google Cloud environment in scope for regulatory compliance, and mapping compliance requirements to Google Cloud services and security controls (network/access segmentation, audit-log coverage).
Compliance starts with correctly delineating "what is your responsibility and which environment is in scope," then translating requirements into concrete Google Cloud controls.
5.1.1Shared responsibility model and scope
Cloud security is split by the shared responsibility model: Google owns physical infra and the hypervisor; the customer owns data/identity/config/access control—and the line shifts across IaaS/PaaS/SaaS (more managed = less customer responsibility). For sovereignty, Access Transparency shows records of Google operational access, and Access Approval requires your pre-approval for Google access. For compliance, first identify the scope (the in-scope Google Cloud environment—projects/folders/data) and organize technical needs (compute/data/network/storage). Map "see Google access = Access Transparency" and "require approval for Google access = Access Approval."
5.1.2Mapping requirements
Map compliance requirements to concrete Google Cloud services and security controls. E.g., data isolation→VPC Service Controls/network segmentation, access isolation→IAM/least privilege/separation of duties, audit trail→Cloud Audit Logs coverage (incl. Data Access logs), encryption→CMEK/EKM, sensitive data→Sensitive Data Protection. For each requirement, map "which control is the evidence" so it can be shown in an audit. "Network/access segmentation + audit-log coverage" is the standard mapping axis.
Common: requirement → means. E.g., "see records of Google support accessing data" = Access Transparency; "require pre-approval for Google access" = Access Approval; "understand the responsibility line" = shared responsibility model (shifts across IaaS/PaaS/SaaS); "evidence of data isolation" = VPC Service Controls; "access trail" = Cloud Audit Logs (incl. Data Access).
Watch the mix-ups: (1) Access Transparency (visibility of Google access) vs Access Approval (require pre-approval) play different roles. (2) The responsibility line shifts by service model—SaaS reduces but never zeroes customer responsibility. (3) Over-broad scope increases audit burden—delineate correctly.
5.1.3Section summary
- Split by shared responsibility (line shifts IaaS/PaaS/SaaS); sovereignty via Access Transparency/Access Approval
- First identify the in-scope environment; organize technical needs (compute/data/network/storage)
- Map requirements to services/controls (VPC Service Controls/IAM/Cloud Audit Logs/CMEK/SDP)
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. To gain visibility into records of Google support/operations accessing your data, which is best?
Q2. For compliance, to require explicit approval before Google accesses your data, which is best?
Q3. Which best describes the cloud shared responsibility model?
Q4. When starting a compliance effort, what should you do first?
Q5. Which Google Cloud control satisfies a compliance requirement to "record all access to sensitive data"?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.