Book TOC · Previous · Chapter 8 of 8

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

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

1. The ACE Look-Alike Service Disambiguation Matrix

In complex Google Cloud Certified Associate Cloud 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. Be familiar with using the console (web interface) and the cli tools (gcloud, bq).
2. Scope Identification: Consider words like "Internal," "Private," or "Inside the cluster" in your question analysis.
3. Hierarchy of Exposure: ClusterIP: Internal Only.
4. * NodePort: External via Node IP/Port.
5. * LoadBalancer: External via Public Cloud IP.
6. Understanding the scope of a resource - where it is available, resides is important for system architecture.
7. Watch for constraints like "fewest steps" - prefer in-built options in such cases.
8. Standard Storage is for frequent access.
9. Nearline Storage is for monthly access (30-day minimum).
10. Coldline Storage is for quarterly access (90-day minimum).
11. Archive Storage is for annual access (365-day minimum) and offers the lowest storage rates.
12. Cloud Armor is the primary tool for securing Google Cloud Load Balancers against web attacks and unwanted traffic.
13. Use Security Policies in Cloud Armor to define Allow or Deny rules.
14. Geo-blocking is best handled by Cloud Armor using region codes, not by manually managing firewall IP lists.
15. Cloud Armor rules are attached to the Backend Service of the Load Balancer.
16. Prefer in-built solutions instead of custom ones, such as lifecycle management.
17. Prefer auto-scaling when users at a time are unpredictable.
18. Resources should ideally be closest to where the users are.
19. Learn storage solutions thoroughly w.r.t.:
20. size limitations
21. scaling abillity
22. type of storage - sql/nosql/object/files
23. purpose - analytics or transactional
24. location - zonal/regional/multi-regional
25. Tool Distinction: Remember: gcloud = Nodes/Infrastructure; kubectl = Pods/Software
26. Thoroughly know your storage options, their performance characteristics, and possible locations.
27. Narrow down architectures choices by comparing keywords in the question, e.g. relational, transactional, global.
28. bq = BigQuery.
29. gsutil = Cloud Storage.
30. gcloud = Compute, Networking, Projects.
31. Prefer in-built solutions where available.
32. It is recommended to scale resources to load, as it goes up or down.
33. Use Logging Sinks to export logs for retention beyond the default Cloud Logging limits.
34. Cloud Storage is the most cost-effective destination for long-term compliance archival.
35. BigQuery is for analytics; Pub/Sub is for streaming.
36. Select the Archive storage class for data accessed less than once a year to minimize costs.
37. Google Cloud encrypts all data at rest by default using AES-256.
38. Default encryption requires no configuration or action from the user.
39. Customer-Managed Encryption Keys (CMEK) are used when you need control over key rotation and location, but they add overhead.
40. Always choose the solution with the least operational overhead unless specific advanced requirements dictate otherwise.
41. Global External Application Load Balancers provide a single global Anycast IP address.
42. Global LBs automatically route traffic to the region closest to the user (lowest latency) that has capacity.
43. Web applications (HTTP/S) typically require Layer 7 Application Load Balancers.
44. Regional Load Balancers require separate IP addresses for each region.
45. Roles and commands are intuitively named. You can guess the effect.
46. Eliminate groups of options.
47. Use common sense: in this question, two options were the same and both can’t be right.
48. Know how permissions are inherited on the resource hierarchy. Privileges granted at a higher level cannot be revoked at a lower level.
49. Cloud Run defaults to routing 100% of traffic to the newest revision immediately.
50. Use the --no-traffic flag during deployment to stage a new revision without routing traffic to it.
51. Use gcloud run services update-traffic to define custom traffic splits (canary or blue/green deployments).
52. Proactive vs. Reactive: Identify whether the requirement is proactive, where you are informed and then act, or reactive, where you discover on your own and act.
53. Native options: If GCP provides a built-in feature that tackles the problem, it is often a recommended solution.
54. Rollbacks: In the cloud, a "rollback" is rarely "undoing" an installation; it is usually just shifting traffic back to a version that was never deleted.
55. Availability: Any answer that involves "deleting," "overwriting," or "maintenance windows" is usually unacceptable if "no impact to users" is a requirement.
56. When scale is a consideration, figure out ways that are autonomous. E.g. groups for IAM, autoscaler for GKE, Cloud Run for compute, etc.
57. Look for common patterns in questions.
58. Compare similarities and differences in the options.
59. Hands-on: get experience with the gcloud tool.
60. An impossible or fake option like bq generate is unlikely to appear in Google Cloud architectures - the options will be technically possible.
61. Recommended practices: Google recommends checking if a combination of predefined roles meets the need before creating a custom one, as custom roles require manual maintenance.
62. Resource Inheritance: Roles created at the Organization level are inherited by all Projects, but roles created at the Project level stay within that Project.
63. Custom Role Caveat: Remember that custom roles are NOT automatically updated by Google. If BigQuery adds a new feature, you must manually update your custom role.
64. Always prefer attaching service accounts to compute resources over using downloaded JSON key files.
65. Use Google Cloud Client Libraries to leverage Application Default Credentials (ADC) for automatic authentication.
66. Avoid hardcoding credentials or tokens in your application code.
67. Do not use personal user credentials for production workloads.
68. Prefer self-help tools when available.
69. Generally Google prefers to provide tools that help users independently perform tasks.
70. Hands-on: try out the pricing calculator. See references.
71. The gcloud CLI uses a configuration system to store default settings like project, region, and zone.
72. Use gcloud config set project [PROJECT_ID] to switch the target project for your current session.
73. Configurations allow you to execute scripts across different environments without hardcoding project IDs.
74. Autoscaling ensures the infrastructure remains cost-effective by reducing resources when traffic is low.
75. When end users are spiky (changes over time - day/week/etc.) or unpredictable, prefer autoscaling of resources.
76. Shared VPC allows multiple projects to share a single VPC network managed by a central project.
77. The project owning the network is the Host Project.
78. Projects using the network are Service Projects.
79. You must enable Shared VPC in the Host Project before attaching Service Projects.
80. Role names like Viewer, Editor, Admin are clearly indicative of their permissions and you can make a strong guess about their intent in Google Cloud architectures.
81. There are 1000s of roles; there's no point to review or remember them. Get a general understanding of what the name implies and indicates.
82. AppEngine is not recommended by Google nowadays, and it is unlikely to appear in th architectures
83. If you replace AppEngine with any other product, the principles for the roles still apply.
84. Setting default configurations streamlines your gcloud command execution by reducing the need to specify common parameters.
85. You can have multiple configurations for different projects.
86. IAM Conditions allow for conditional access based on attributes like time, IP address, and resource name.
87. Use request.time for specific, non-recurring date/time ranges (temporary access).
88. Use request.day_of_week or time of day for recurring access windows (e.g., business hours only).
89. Avoid building custom scripts for access revocation when native policy features exist.
90. The Organization node is the root of the hierarchy and centralizes control.
91. Folders organize projects by business unit (Department) or environment (Dev/Prod).
92. IAM policies inherit downwards: Organization -> Folder -> Project -> Resource.
93. Projects are the hard boundary for billing, quotas, and permissions isolation.
94. Organization Policies are inherited down the resource hierarchy (Organization → Folder → Project).
95. Child resources can override parent policies to create specific exceptions using the 'Customize' option.
96. IAM permissions (Who) and Organization Policies (What) are separate layers of security; IAM cannot bypass Organization Policies.
97. Manage policies at the highest level possible for consistency, and use overrides only for necessary exceptions.
98. Permissions set at a parent level (Organization or Folder) are inherited by all child resources (Projects).
99. Use Folders to group projects with similar access requirements to simplify administration.
100. Avoid granting permissions at the Organization level unless the user truly needs access to absolutely everything.

Book TOC · Previous · Chapter 8 of 8