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

Chapter 0: The ACE Reference Stack & 10 Core Principles

Chapter Focus: A visual guide to the Google Cloud Certified Associate Cloud Engineer (ACE) 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: All In-Scope Services of the Architecture Stack

The updated Google Cloud Associate Cloud Engineer Curriculum spans 4 Sections, 12 Subsections, and 94 Considerations, integrating foundational cloud infrastructure with modern 2026 platform capabilities—including Cloud NGFW, Google Cloud Hyperdisk, Agent Runtime on Gemini Enterprise Agent Platform, Gemini Cloud Assist, Google Antigravity, Fabric FAST, Database Center, and Cloud Hub.

Rather than memorizing services in isolation, organize the entire ACE stack across Six Logical Architectural Planes:

Complete Reference Table of In-Scope Google Cloud Services & Tooling

2. The 10 Core Architectural Principles of the Architecture Stack

1. Principle 1 — Never Export Static Service Account JSON Keys When a Keyless Alternative Exists: Any option that instructs you to run gcloud iam service-accounts keys create key.json and copy it into a VM, container image, GitHub repository, or developer laptop is almost certainly a trap. Use Attached Service Accounts on GCP compute, Workload Identity Federation for GKE Pods and external clouds/CI pipelines, Workforce Identity Federation for external human IdPs, and Service Account Impersonation (--impersonate-service-account) for local developer testing.
2. Principle 2 — Assign IAM Roles to Google Groups at the Highest Shared Hierarchy Node: Never grant IAM roles to dozens of individual user: emails one by one. Put users into Cloud Identity / Google Groups (group:devops@example.com) and bind the narrowest Predefined Role (never Basic roles like Owner or Editor) at the Folder or Project level where all target resources share access requirements. Remember: IAM allow policies are strictly additive down the hierarchy (Organization → Folder → Project → Resource), whereas Organization Policies enforce preventive guardrails that restrict what even an Owner can do.
3. Principle 3 — Match the Compute Platform to Operational Overhead and Scaling Physics:
4. Stateless HTTP container or webhook that must scale to zero when idle → Cloud Run (or Cloud Run functions for lightweight event snippets).
5. Production AI agent requiring managed session state and serverless execution → Agent Runtime on Gemini Enterprise Agent Platform.
6. Complex microservices orchestration with minimum operational overhead → GKE Autopilot.
7. Custom OS kernel modules, privileged DaemonSets, or direct host-level GPU/machine tuning → GKE Standard or Compute Engine VMs.
8. Fault-tolerant, stateless batch job needing maximum cost reduction → Spot VMs (never use Spot VMs for stateful quorum databases or latency-critical single-instance web servers).
9. Principle 4 — Match the Data & Storage Service to Data Structure, Scale, and Latency:
10. Unstructured blobs, backups, static assets, or data lake files → Cloud Storage (Standard for hot, Nearline ≥ 30d, Coldline ≥ 90d, Archive ≥ 365d).
11. Shared POSIX NFS filesystem mounted across multiple Linux VMs or GKE Pods (ReadWriteMany) → Filestore (or NetApp Volumes for enterprise SMB/NFS + ONTAP snapshots; Managed Lustre for massive parallel HPC/AI clusters).
12. Regional relational OLTP → Cloud SQL (MySQL/PostgreSQL/SQL Server) or AlloyDB (high-throughput enterprise PostgreSQL).
13. Global relational OLTP with horizontal write scaling and 99.999% SLA → Cloud Spanner.
14. Serverless NoSQL document database for web/mobile real-time sync → Firestore.
15. High-throughput wide-column NoSQL for time-series/IoT at petabyte scale → Cloud Bigtable.
16. Serverless petabyte-scale analytical SQL data warehouse → BigQuery.
17. Principle 5 — Private VMs Use Private Google Access for Google APIs and Cloud NAT for the Public Internet: If a VM has no external IP address, enable Private Google Access on its VPC subnet so it can reach Cloud Storage, BigQuery, and Artifact Registry over Google's internal network at zero NAT cost. Enable Cloud NAT when that private VM needs to download OS patches or reach third-party external internet endpoints—remembering that Cloud NAT is strictly for outbound-initiated connections and never allows unsolicited inbound traffic.
18. Principle 6 — Use Shared VPC for Centralized Enterprise Governance and VPC Peering for Decentralized Direct Peering: When multiple projects within the same Organization need to share subnets centrally managed by a network security team, choose Shared VPC (Host Project + Service Projects). Use VPC Network Peering when connecting independent VPCs (even across organizations), keeping in mind that VPC Peering is non-transitive ($A \leftrightarrow Band @@CODE₃@@ ↔ C does not allow $A \leftrightarrow C$) and requires non-overlapping CIDR ranges.
19. Principle 7 — Prefer Secure Tags in Cloud NGFW Policies Over Legacy Network Tags: Traditional Compute Engine network tags are plain strings that any user with VM edit permissions can attach to bypass firewall intent. When a workload scenario requires cryptographically governed, IAM-controlled firewall targeting across a hierarchy or VPC, use Cloud NGFW Policies with Secure Tags (bound via IAM tag bindings) or Service Accounts.
20. Principle 8 — Budgets Alone Never Stop Spending; Pair Budget Pub/Sub Alerts with Cloud Run Functions for Hard Caps: Creating a Cloud Billing budget alert only sends notification emails by default—your VMs and BigQuery queries will continue running past 100%. To enforce an automated cost cap, configure the budget to publish notifications to a Pub/Sub topic that triggers a Cloud Run function to stop non-production VMs or unlink the project's billing account.
21. Principle 9 — Route Logs Before They Expire via Log Router Sinks: Cloud Logging retains _Required audit logs (Admin Activity, System Event) for 400 days and _Default logs for 30 days. To retain logs for years at minimal cost, create a Log Router Sink with an inclusion filter targeting a Cloud Storage Archive bucket; to run SQL joins across logs and business tables, route the sink to BigQuery or upgrade the Cloud Logging Bucket to Log Analytics (linked to BigQuery).
22. Principle 10 — Know Your Four Essential CLI Binaries (gcloud, kubectl, bq, cbt):
23. gcloud manages virtually all Google Cloud control-plane resources—including Cloud Storage via gcloud storage (preferred over legacy gsutil for faster parallel transfers and unified syntax).
24. kubectl manages Kubernetes objects inside GKE clusters (Pods, Deployments, StatefulSets, DaemonSets, Services, HPA) after you fetch cluster credentials via gcloud container clusters get-credentials.
25. bq executes BigQuery jobs, dry-run cost estimates (bq query --dry_run), and dataset operations.
26. cbt performs Cloud Bigtable table, column-family, and row lookups.

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