Book TOC · Chapter 0 of 7 · Next: Chapter 1

Chapter 0: The PCSE Reference Stack & 10 Core Principles

Chapter Focus: A visual guide to the Google Cloud Certified Professional Cloud Security Engineer (PCSE) architecture stack, how the core Google Cloud services fit together, and the 10 Core Architectural Principles that govern production design decisions.

1. The Master Architectural Map: The Google Cloud Security Stack

The official Google Cloud Professional Cloud Security Engineer (PCSE) Curriculum spans 5 Sections, 14 Subsections, and 70 Considerations. Rather than memorizing services in isolation, organize the entire Google Cloud security ecosystem across Five Integrated Defense-in-Depth Planes:

Complete Reference Table of In-Scope PCSE Security Services & Controls

2. The 10 Core Architectural Principles of the Architecture Stack

Before you tackle your first challenge in Chapter 1, internalize these 10 Core Architectural Principles. Whenever you are torn between two plausible-sounding options In Google Cloud architectures, these laws eliminate 80% of look-alike service comparisons immediately:

1. Principle 1 — Never Create Static Service Account Keys When Federation or Impersonation Exists: Any option proposing downloading a JSON key file, storing long-lived keys in GitHub Secrets/AWS Secrets Manager, or rotating static keys via cron jobs when a keyless path exists is a trap. Always choose Workload Identity Federation (external clouds/CI/CD), GKE Workload Identity (Pods), or Service Account Impersonation (roles/iam.serviceAccountTokenCreator)—and enforce constraints/iam.disableServiceAccountKeyCreation globally.
2. Principle 2 — Network Firewalls Cannot Stop API Data Exfiltration; Only VPC Service Controls Can: Standard VPC firewall rules inspect VM packet flows, not multi-tenant Google API calls (storage.googleapis.com, bigquery.googleapis.com). When a scenario asks how to prevent a malicious insider or compromised credential from copying data to an external personal Cloud Storage bucket or BigQuery dataset, the answer is always VPC Service Controls (VPC-SC) paired with restricted.googleapis.com (199.36.153.4/30).
3. Principle 3 — Match the De-Identification Transform to the Downstream Schema & Join Constraints:
4. Need to mask all but the last 4 digits for support tickets? → Character Masking.
5. Need to join two BigQuery tables on a de-identified column (referential integrity) without strict legacy column length limits? → Deterministic Encryption (CryptoDeterministicConfig / AES-SIV).
6. Legacy database column strictly requires a 16-digit numeric or 9-digit SSN format and length? → Format-Preserving Encryption (FPE-FFX).
7. Irreversible one-way analytics de-identification? → Cryptographic Hashing (CryptoHashConfig) or Redaction / Bucketing.
8. Principle 4 — Match the Key Management Solution to the Exact Regulatory Boundary:
9. Zero operational overhead, standard compliance → Google Default Encryption.
10. Customer control over rotation schedule, key destruction (crypto-shredding), and audit logs → CMEK (Cloud KMS Software Keys).
11. Strict FIPS 140-2 Level 3 hardware validation requirement → Cloud HSM.
12. Strict sovereignty rule that key material must never enter Google Cloud servers → Cloud External Key Manager (Cloud EKM).
13. Principle 5 — IAM Deny Overrides IAM Allow, and Organization Policies Restrict Resources (Not Principals): In IAM policy evaluation, an explicit IAM Deny policy always trumps any IAM Allow binding (even roles/owner)—use it when you must block a specific permission (e.g., iam.serviceAccountKeys.create) across principals. Conversely, Organization Policy constraints (constraints/compute.vmExternalIpAccess, constraints/gcp.resourceLocations) govern what resource configurations can exist, regardless of who calls the API.
14. Principle 6 — Isolate Duties Across the Resource Hierarchy & Shared VPC: Never grant developers Project Owner or Project Editor in production. Group projects into environment Folders (Prod, Non-Prod), manage users via synced Google Groups (never individual user bindings), and use Shared VPC so Network Admins control subnets/firewalls in the Host Project while developers deploy VMs in Service Projects using subnet-level roles/compute.networkUser.
15. Principle 7 — Match the Log Sink Destination to the Consumer Pattern:
16. Long-term multi-year compliance archival at lowest cost (7-year HIPAA/PCI retention) → Cloud Storage (Archive storage class) with Bucket Lock (WORM).
17. Retrospective SQL querying, relational joins, and forensic investigation → BigQuery (or Log Analytics linked dataset).
18. Real-time streaming to an external SIEM (Splunk, QRadar, Chronicle) → Cloud Pub/Sub.
19. Capture all current and future projects across the hierarchy → Aggregated Log Sink at the Organization/Folder node with includeChildren = true.
20. Principle 8 — Admin Activity Logs Are Always On (400 Days); Data Access Logs Must Be Explicitly Enabled (30 Days): If an auditor asks why storage.objects.get (DATA_READ) events are missing during a breach investigation, it is because Data Access audit logs are disabled by default (except for BigQuery) to prevent volume/cost spikes. Enable DATA_READ / DATA_WRITE in IAM Audit Config and use exemptedMembers only for trusted high-volume service accounts.
21. Principle 9 — Protect Data In-Use with Confidential Computing and Boot Integrity with Shielded VMs: Do not confuse Shielded VMs / Shielded GKE Nodes (which verify kernel/bootloader signatures at boot via Secure Boot and vTPM) with Confidential Computing (Confidential VM / Confidential GKE Nodes), which encrypts data in-use inside RAM using hardware memory encryption (AMD SEV / Intel TDX).
22. Principle 10 — Preserve Volatile Forensics First, Isolate via Network Second, Never Reboot: When responding to an active VM compromise (such as cryptomining detected by SCC Event Threat Detection), never stop, reboot, or delete the instance first (which destroys volatile RAM/process state). Instead: (1) Isolate the VM by applying deny-all ingress/egress firewall rules (quarantine tag/service account), (2) Snapshot the persistent disk for forensic analysis in a clean quarantine project, and (3) Terminate/replace the workload only after evidence is preserved.

Book TOC · Chapter 0 of 7 · Next: Chapter 1