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 PCD services, a 5-Step Architecture Decision Framework, cross-domain production patterns, and the Top 25 Golden Rules.

1. The PCD Look-Alike Service Disambiguation Matrix

In complex Google Cloud Certified Professional Cloud Developer 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. Use Git tags to create immutable references for software releases.
2. Avoid deploying directly from moving branches (like main) to production to prevent untested code from leaking.
3. Ensure your CI/CD pipeline propagates the exact artifact or commit verified in staging to production.
4. Infrastructure as Code (IaC) should follow the same versioning strategies as application code.
5. Always follow the principle of least privilege when assigning roles.
6. Enabling APIs requires write access to the Service Usage configuration.
7. The Service Usage Admin role is the specific role for enabling/disabling APIs.
8. Avoid using Basic roles (Editor/Owner) for granular tasks.
9. Cloud Build executes builds using a dedicated Service Account.
10. PermissionDenied errors usually mean the service account lacks a specific IAM role.
11. Grant the principle of least privilege; only give the specific role needed (e.g., Datastore User) rather than broad roles (e.g., Editor).
12. Never download service account keys for use in Cloud Build; use the built-in identity.
13. App Engine natively supports traffic splitting for A/B testing and canary deployments.
14. Traffic splitting can be defined by Cookie or IP address.
15. Use IP address sharding when you need stickiness independent of browser state or for non-browser clients.
16. Use Cookie sharding for more precise user percentage allocation when browser cookies are reliable.
17. Use Cloud Workflows for low-latency, stateful orchestration of microservices.
18. Use Workflows when you need strict ordering, retries, and custom error handling (like rollbacks).
19. Use Cloud Pub/Sub for asynchronous, event-driven communication (choreography) where services are decoupled.
20. Use Cloud Tasks for distributed task queues and rate limiting.
21. Cloud Run services secured with 'Require authentication' reject unauthenticated requests at the infrastructure layer.
22. Service-to-service authentication in Google Cloud uses OIDC ID tokens.
23. The receiving service must grant the roles/run.invoker IAM role to the calling service account.
24. Avoid custom auth schemes (API keys, shared secrets) when platform-native IAM is available.
25. Cloud Run services requiring authentication expect an OIDC ID Token, not an OAuth Access Token.
26. The ID Token must contain an 'audience' (aud) claim that matches the URL of the receiving service.
27. Authentication tokens are passed in the 'Authorization: Bearer' HTTP header.
28. API Keys are for project quotas, not for service identity authentication.
29. Use Deployments for stateless applications (web servers, APIs) where pods are interchangeable.
30. Use StatefulSets for applications requiring stable network IDs and persistent storage (databases).
31. Use DaemonSets for cluster-wide system agents (logging, monitoring) running on every node.
32. Use Jobs or CronJobs for batch tasks that run to completion.
33. Eventarc enables event-driven architectures by routing events to Cloud Run.
34. Use the google.cloud.audit.log.v1.written event type to trigger services based on API calls recorded in Cloud Audit Logs.
35. Always filter Audit Log triggers by serviceName and methodName to ensure precision and reduce unnecessary invocations.
36. Use the filter parameter to narrow down which resources you want to find.
37. Use the fields parameter to restrict the API response to only the data attributes you actually need (Partial Response).
38. Optimizing response size helps prevent memory errors and reduces network latency.
39. Cloud Build performs actions using a Service Account.
40. "Permission Denied" errors during a build usually mean the Service Account lacks a specific IAM role.
41. Use the Artifact Registry Writer role to allow pushing container images.
42. Use the Artifact Registry Reader role to allow pulling container images.
43. Cloud Build workers are ephemeral; data is not saved locally between builds.
44. Caching dependencies reduces build time and network costs.
45. Kaniko is the recommended tool for caching Docker build layers in Cloud Build.
46. Never commit binary dependencies (like node_modules) to version control.
47. Metrics vs. Traces: Use metrics (Cloud Monitoring) for infrastructure health (CPU/RAM) and traces (Cloud Trace) for request latency and bottlenecks.
48. Profiler Use Case: Use Cloud Profiler when you need to optimize code that is consuming too many resources, not necessarily for network latency.
49. Microservices Visibility: In distributed systems, tracing is essential to see the 'full picture' of a request's journey.
50. VPC Service Controls perimeters block ingress and egress by default to prevent data exfiltration.
51. Use Egress Rules to allow internal resources to access external resources.
52. Target Egress Rules to specific identities (Service Accounts) and destination projects for least privilege security.
53. Google Cloud Client Libraries have built-in retry logic for transient errors.
54. Avoid writing manual while loops or time.sleep code for API retries.
55. Exponential backoff is the standard for retrying cloud API requests.
56. Always check library documentation for configuration options before implementing custom logic.
57. Secret Manager is the preferred tool for storing and managing sensitive configuration data like database passwords.
58. Rotation limits the lifespan of a secret, reducing the risk of unauthorized access if a key is leaked.
59. Secret Manager can automate rotation by triggering Cloud Functions to handle the update logic on external systems like databases.
60. Avoid storing secrets in environment variables or source code.
61. External HTTP(S) Load Balancers have a default backend service timeout (often 30 seconds).
62. Long-lived protocols like WebSockets require increasing this timeout to prevent premature disconnection during idle periods.
63. Session affinity directs traffic but does not manage connection duration.
64. HPA Default: Horizontal Pod Autoscaler defaults to scaling based on CPU and Memory usage.
65. External Metrics: For event-driven workloads (like Pub/Sub consumers), resource metrics are often insufficient. Use External Metrics to scale based on the source of the event (e.g., queue depth).
66. Autoscaler Roles: HPA scales pods (application count), VPA scales pod resources (application size), and Cluster Autoscaler scales nodes (infrastructure capacity).
67. App Engine defaults to shifting 100% traffic to new deployments.
68. Use the --no-promote flag to stage a deployment without traffic.
69. Traffic splitting is a separate step managed after verification.
70. app.yaml configures runtime settings, not traffic allocation.
71. API Gateway sits between clients and backend services to manage traffic, security, and monitoring.
72. Private Cloud Run services require authentication via IAM OIDC tokens.
73. Use a Service Account with the roles/run.invoker role for service-to-service authentication.
74. API Keys identify the client app, not the backend infrastructure.
75. Error Reporting is the dedicated tool for grouping crash logs and stack traces.
76. Cloud Logging is for searching and storing raw log data.
77. Cloud Monitoring is for tracking numerical metrics and alerting on thresholds.
78. Don't reinvent the wheel; if you need to group errors, check if the platform does it automatically before building custom queries.
79. Use Cloud Tasks when you need to control the rate of execution (throttling) or manage task retries individually.
80. Use Pub/Sub for high-throughput event ingestion where loose coupling is the priority, not rate limiting.
81. Minimize operational overhead by choosing managed service features (like queue configuration) over writing custom code on infrastructure (like VMs).
82. Object Versioning increases storage usage by keeping noncurrent versions of files.
83. Lifecycle Management automates object deletion or class transition based on rules.
84. Use the numNewerVersions condition to limit the number of noncurrent versions retained for an object.
85. The Age condition deletes objects based on their creation time, not the number of versions.
86. Cloud Trace helps visualize latency in distributed systems using traces and spans.
87. A Waterfall view displays spans hierarchically, showing where time is spent during a request.
88. If a child span (e.g., database call) consumes the majority of the parent span's duration, the optimization effort should focus on the child operation.
89. Scaling infrastructure does not fix latency issues caused by inefficient code or queries.
90. Use Standard storage for frequently accessed data.
91. Use Nearline storage for data accessed once a month.
92. Use Coldline storage for data accessed once a quarter.
93. Use Archive storage for long-term retention (over a year) where data is rarely accessed, offering the lowest storage cost.
94. Signed URLs grant temporary access to users without requiring them to have GCP credentials.
95. The validity of a Signed URL depends on the permissions of the account that signed it.
96. If a Signed URL returns a 403 error, check if the signing Service Account has the correct IAM role (e.g., Storage Object Viewer) on the bucket.
97. Service Directory stores information about registered services, including their network endpoints (IP address, port).
98. Cloud DNS can use a Service Directory private zone to resolve DNS queries to these dynamic endpoints.
99. This integration enables service discovery via standard DNS without requiring application code changes to call APIs.
100. This pattern works across VPCs and Shared VPCs seamlessly.

Book TOC · Previous · Chapter 7 of 7