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."
Continue reading — free sign-up
You're reading the free preview. Sign up free to read this section in full, plus every chapter (including 4+) and all questions.