Book TOC · Previous · Chapter 7 of 7

Chapter 7: Master Look-Alike Tool Comparison & Decision Playbook

Chapter Focus: Side-by-side comparison of look-alike PCSE services, a 5-Step Architecture Decision Framework, cross-domain production patterns, and the Top 25 Golden Rules.

1. The PCSE Look-Alike Service Disambiguation Matrix

In complex Google Cloud Certified Professional Cloud Security Engineer architectures, multiple Google Cloud services often appear to solve similar problems. Use the matrix below to distinguish between closely related services based on latency, scale, security boundaries, and operational overhead.

2. The 5-Step Architecture Decision Framework

When evaluating a multi-service Google Cloud design, apply this structured 5-step architectural review:

1. Step 1 — Pinpoint Core Workload & Non-Functional Requirements: Identify the primary workload driver (e.g., sub-10ms OLTP vs. petabyte OLAP, synchronous REST vs. asynchronous event streaming, strict regional data residency vs. global active-active availability).
2. Step 2 — Prefer Managed, Cloud-Native Services First: Default to fully managed, serverless, or Google-curated services before introducing self-managed VMs, custom glue scripts, or unscalable manual operations.
3. Step 3 — Enforce Zero-Trust Identity & Keyless Authentication: Replace static credentials, long-lived service account JSON keys, and broad basic roles (Owner/Editor) with Workload Identity Federation, attached service accounts, and predefined IAM roles.
4. Step 4 — Verify Network Isolation & Data Perimeter Guardrails: Combine private connectivity (Private Service Connect, Private Google Access, IAP TCP forwarding) with VPC Service Controls and Organization Policy constraints.
5. Step 5 — Optimize for Cost, Observability, and Day-2 Reliability: Validate autoscaling boundaries, SLO burn-rate alerting, sink-level log filtering, and automated rollback pipelines before production rollout.

3. Review: Architecture Decision List

1. In a PaaS environment like App Engine Standard, the cloud provider manages the underlying infrastructure and runtime.
2. Google is responsible for patching the operating system and managed language runtimes in App Engine Standard.
3. Users are responsible for securing their own application code and data.
4. Confidential Computing encrypts data in use (in memory).
5. Organization Policies are preventative controls used to enforce resource configuration compliance.
6. IAM manages permissions (who), while Organization Policy manages configurations (what).
7. Always prefer preventative controls (blocking creation) over reactive controls (detect and delete) for security compliance.
8. VPC Service Controls protect services from external access.
9. VPC Accessible Services limits which protected APIs are reachable from within the perimeter.
10. Firewall rules are ineffective for filtering specific Google APIs because they share IP ranges.
11. Always follow the principle of least privilege by whitelisting only necessary APIs.
12. Admin Activity logs track configuration changes and are enabled by default.
13. Data Access logs track data reads/writes and are disabled by default for most services (except BigQuery) due to volume.
14. To audit data theft or unauthorized reads, you must explicitly enable DATA_READ logs.
15. Logging Sinks only export logs that are already generated; they do not enable log generation.
16. Software Protection Level: Suitable for standard use cases; FIPS 140-2 Level 1 compliant.
17. HSM Protection Level: Required for regulatory mandates needing hardware-backed keys; FIPS 140-2 Level 3 compliant.
18. External Key Manager (EKM): Used when keys must be stored outside of Google Cloud completely.
19. Always match the regulatory compliance level (Level 1 vs Level 3) to the protection level chosen during key creation.
20. Use Google Cloud Directory Sync (GCDS) to automate the synchronization of users and groups from Active Directory to Cloud Identity.
21. Manage access by assigning IAM policies to groups, not individual users.
22. Avoid manual directory management to reduce administrative overhead and security risks.
23. Ensure a single source of truth (Active Directory) for identity management.
24. IAM Deny policies always override IAM Allow policies.
25. Project Owners have broad permissions that can only be restricted by higher-level guardrails like IAM Deny policies or Organization Policies.
26. Use IAM Deny policies for negative permission logic (stopping an action) rather than trying to manage exclusions in Allow roles.
27. Applications should only be granted the roles/secretmanager.secretAccessor role to read secret payloads.
28. The roles/secretmanager.viewer role does not allow access to the secret value, only metadata.
29. Avoid using basic roles like Editor in production; strictly follow the principle of least privilege.
30. Separate duties by granting different roles to the application service account (runtime access) and the developers (management).
31. Private Google Access uses Google's shared public VIPs to access APIs.
32. Private Service Connect allows you to assign a specific internal IP from your VPC subnet to access Google APIs.
33. Private Service Connect endpoints for Google APIs target bundles like "all-apis".
34. Security policies often prohibit public IPs to minimize attack surfaces.
35. Vertex AI Workbench instances can be deployed with only internal IP addresses.
36. Private Google Access is required for private instances to reach Google APIs.
37. Internal IPs allow secure communication over Cloud VPN to on-premises networks.
38. Split-Horizon DNS allows the same domain name to resolve differently for internal and external users.
39. Private Managed Zones take precedence over public zones for resources within the attached VPC network.
40. Use Private Zones to hide internal environments while keeping consistent naming conventions.
41. Cloud KMS 'Software' protection level is FIPS 140-2 Level 1 compliant.
42. Cloud KMS 'Hardware' protection level uses Cloud HSM and is FIPS 140-2 Level 3 compliant.
43. Financial and government sectors often require Level 3 (HSM) for key storage.
44. Use Cloud Storage with the Archive class for the most cost-effective long-term data retention (compliance/auditing).
45. Use BigQuery when you need to perform complex analytics or SQL queries on your logs.
46. Use Pub/Sub for event-driven workflows or streaming logs to external SIEMs.
47. Cloud Logging buckets are convenient for immediate troubleshooting but are more expensive for very long-term cold storage.
48. Cloud Armor acts as a Web Application Firewall (WAF) for Google Cloud Load Balancers.
49. Pre-configured rules (based on OWASP CRS) are the standard way to block common attacks like SQLi and XSS with minimal effort.
50. Security policies are attached to the Backend Service of a load balancer.
51. VPC Firewalls are Layer 3/4 controls and cannot inspect Layer 7 payloads for web attacks.
52. Policy Controller helps secure GKE clusters by checking resources against constraints.
53. Use the dryrun enforcement action to audit resources and test policies safely without blocking deployments.
54. Drift detection identifies existing resources that violate new policies.
55. In an IaaS model (Compute Engine), the customer is always responsible for the Guest OS, including patching and configuration.
56. Google is responsible for the physical security of data centers and the underlying host infrastructure (hypervisor).
57. Auditors will require evidence from the customer for layers the customer controls (like the Guest OS).
58. HTTP 429 errors indicate rate limiting.
59. Do not retry immediately; this causes a "thundering herd."
60. Use truncated exponential backoff with jitter for robust API error handling.
61. Client-side logic is the primary fix for burst-related errors.
62. Use Software protection level for CMEK when you need low cost and low latency without specific hardware compliance needs.
63. Use Hardware (HSM) protection level only when regulatory standards (like FIPS 140-2 Level 3) explicitly require it.
64. Use Cloud EKM only when you must store keys outside of Google Cloud infrastructure.
65. Default encryption does not provide control over key lifecycle or rotation.
66. Aggregated Log Sinks allow you to export logs from an entire Organization or Folder to a centralized destination.
67. Using includeChildren: true ensures that all future projects are automatically included in the log export.
68. Centralizing logs is a critical pattern for security auditing and compliance.
69. User-managed service account keys must be rotated manually.
70. A service account can support multiple active keys simultaneously (up to a limit, usually 10).
71. Always create the new key and verify it works before deleting the old key to prevent downtime.
72. Avoid using service account keys if alternatives like Workload Identity Federation are possible, but know how to manage them if required.
73. Admin Activity logs capture configuration changes and are on by default.
74. Data Access logs capture data reads/writes and are off by default for most services.
75. You must explicitly enable Data Access logs to track operations like object.get (download) in Cloud Storage.
76. Always consider the cost and volume implications before enabling Data Access logs.
77. Containment over Destruction: Always prefer isolating a compromised resource (network quarantine) over deleting or stopping it, to preserve evidence.
78. Order of Volatility: Volatile data (RAM, cache) is lost first when a system is powered down. Collect it before stopping the instance.
79. Forensic Snapshots: Take snapshots of disks immediately after isolation to preserve the state of the file system.
80. Avoid Interaction: Do not log in or run commands on a compromised live system unless using forensic tools, as this alters timestamps and logs.
81. Policies in Google Cloud Identity are applied hierarchically through Organizational Units (OUs).
82. Configuration Groups are the preferred method for applying granular policy exceptions without changing the OU structure.
83. Group policies can override OU policies when configured correctly.
84. Avoid using user accounts for automated pipelines; however, if legacy constraints require it, secure them with precise exceptions rather than weakening global policies.
85. Identity-Aware Proxy (IAP) enables zero-trust access to applications accessed via HTTPS, SSH, and RDP without a VPN.
86. IAP requires an HTTPS Load Balancer when protecting web applications.
87. Access is controlled via IAM policies (Identity and Access Management), specifically the 'IAP-secured Web App User' role.
88. IAP shifts security from the network perimeter (firewalls/VPNs) to the application layer (identity).
89. Organization Policies are preventive guardrails that stop non-compliant resources from being created.
90. Use Custom Constraints when pre-built constraints do not meet specific requirements.
91. Custom Constraints use Common Expression Language (CEL) to define logic based on resource attributes like names.
92. Organization Policies provide centralized, preventive guardrails over resource configurations across the resource hierarchy.
93. Firewall rules control network traffic flow but do not prevent the provisioning of resources or configurations (like public IPs).
94. IAM controls access permissions (who can act), while Organization Policies control resource compliance (what can be created).
95. Always prefer preventive controls (blocking the creation) over reactive controls (detecting and deleting) for security governance.
96. Binary Authorization ensures only trusted, signed images are deployed to GKE.
97. The 'breakglass' mechanism allows bypassing enforcement in emergencies using a specific Pod annotation.
98. Breakglass events are automatically recorded in Cloud Audit Logs for visibility and compliance.
99. Single Sign-On (SSO) delegates authentication to a third party, introducing a dependency.
100. Super Admins have a special login path at admin.google.com to bypass SSO during outages.

Book TOC · Previous · Chapter 7 of 7