ACE cheat sheet

Setting up a cloud solution environment

Setting Up Google Cloud Projects, Resource Hierarchy, and IAM

• The hierarchy is organization to folders to projects to resources; IAM and organization policies attach at any level and inherit downward
• IAM inheritance is additive — a lower level can never revoke a role granted above it
• Prefer predefined roles granted to groups at the lowest hierarchy level that works; avoid basic Owner/Editor/Viewer
• Organization policies constrain what can be done (even by Owners); IAM controls who can do it
• Manage Cloud Identity users manually in the Admin console or automatically via GCDS/provisioning; Workforce Identity Federation grants access with no Google Accounts at all
• APIs are disabled by default per project — enable with gcloud services enable before use
• Quota increases are requested from the Cloud Quotas page, are reviewed by Google, and are not instant
• Install the Ops Agent for VM memory/disk-space metrics, and use a metrics scope to monitor multiple projects from one place

Google Cloud Billing Accounts, Budgets, Alerts, and BigQuery Export

• One billing account funds many projects; each project links to exactly one billing account
• Linking a project requires Billing Account User on the account plus Project Billing Manager (or Owner) on the project — neither alone suffices
• Billing Account Viewer is the read-only role for finance; Billing Account Administrator manages payment settings and billing IAM
• Budgets and alerts notify — they never stop spending; a hard cap must be built (Pub/Sub budget notifications driving billing disablement)
• Budget alert emails go to Billing Account Administrators and Users by default, not Project Owners
• BigQuery billing export is per billing account, not retroactive — enable it on day one
• Detailed usage cost export adds resource-level cost attribution; standard export stops at SKU/project granularity
• Disabling billing on a project stops paid services and can destroy resources — it is the drastic way to stop spend

Planning and implementing a cloud solution

Choosing and Deploying Compute: Compute Engine, GKE, and Cloud Run

• Pick compute by management burden and control: Compute Engine for VMs and lift-and-shift, GKE for orchestrated containers, Cloud Run for stateless containers with scale-to-zero, Cloud Run functions for single-purpose event handlers.
• The availability policy (MIGRATE vs TERMINATE plus automatic restart) controls maintenance behavior; OS Login replaces metadata SSH keys with IAM-governed access, and VM Manager patches, inventories, and enforces policy across the fleet.
• Zonal Persistent Disk is the default; regional Persistent Disk synchronously replicates across two zones for failover; Hyperdisk provisions IOPS and throughput independently of capacity; Local SSD is fast but ephemeral.
• MIGs are built from immutable instance templates and autoscale on CPU, load-balancer capacity, or custom metrics; regional MIGs plus autohealing are the VM high-availability pattern.
• Spot VMs are deeply discounted but preemptible with no availability SLA — fault-tolerant batch only; custom machine types fit exact vCPU and memory to the workload to avoid paying for a predefined shape you do not need.
• GKE Autopilot manages nodes for you and bills per Pod request; regional clusters survive zonal outages; private clusters give nodes internal IPs only; kubectl needs gcloud container clusters get-credentials before anything works.
• Serverless event processing maps Pub/Sub to message-driven work, Cloud Storage notifications to upload-driven work, and Eventarc to general event routing into Cloud Run.
• GPUs are the general-purpose accelerator across compute platforms; TPUs are purpose-built for very large-scale tensor and model-training workloads.

Choosing Storage and Databases: Cloud SQL, BigQuery, Spanner, and More

• Select databases by data model, scale, and consistency: Cloud SQL for regional relational, Spanner for globally consistent relational scale, Firestore for documents with sync, Bigtable for massive-throughput wide-column data, BigQuery for analytics.
• AlloyDB is the PostgreSQL-compatible step up from Cloud SQL for demanding transactional-plus-analytical workloads; Memorystore is the managed cache and session store, not a system of record.
• Pub/Sub ingests and decouples, Dataflow transforms streams and batches, Managed Service for Apache Kafka exists for Kafka-compatibility requirements — Pub/Sub to Dataflow to BigQuery is the canonical streaming pipeline.
• Cloud Storage classes trade at-rest price against retrieval fees and minimum durations: Standard (none), Nearline (30 days), Coldline (90 days), Archive (365 days) — all with the same durability and millisecond access.
• Bucket location is permanent and is the redundancy decision: regional for latency, dual-region for two active regions (optionally with turbo replication), multi-region for broadest geo-redundancy.
• File workloads map to Filestore for NFS, NetApp Volumes for SMB and enterprise NetApp features, Managed Lustre for HPC-scale parallel throughput.
• Load small and scripted data with gcloud storage cp and rsync; use Storage Transfer Service for large, recurring, or cross-cloud transfers; stage in Cloud Storage then load into BigQuery or import into Cloud SQL.
• Multi-region redundancy is automatic where it is a location or config choice (Cloud Storage, Spanner, Firestore, BigQuery) and operator-driven where it uses replicas (Cloud SQL cross-region replica promotion, Bigtable multi-cluster replication).

VPC Networks, Firewall Rules, and Load Balancing on Google Cloud

• VPC networks are global; subnets are regional — and custom mode is the production choice because auto mode ranges overlap and block peering.
• Shared VPC shares one network across projects in a single organization; VPC Network Peering connects two independent networks, is non-transitive, and forbids overlapping ranges.
• Firewall rules are stateful and defined by direction, action, priority (lower number wins), source or destination, targets, and protocols and ports; implied rules deny all ingress and allow all egress.
• Cloud NGFW firewall policies attach at organization, folder, or network scope, and their rules can match IAM-governed secure Tags and service accounts — stronger identities than legacy network tags.
• HA VPN offers a 99.99% SLA over encrypted internet tunnels; Dedicated Interconnect provides 10 or 100 Gbps private links; Partner Interconnect covers 50 Mbps to 50 Gbps without a colocation presence.
• Choose load balancers by layer (Application vs Network), client location (external vs internal), and scope (global vs regional); passthrough Network Load Balancers preserve client IPs and support UDP.
• Premium Tier rides Google's backbone and is required for global load balancing; Standard Tier is regional, uses the public internet sooner, and costs less.

Terraform, Config Connector, and AI-Assisted Tooling on Google Cloud

• Declarative IaC describes desired end state and safely converges to it; imperative gcloud scripts list steps and are not safely repeatable.
• The Terraform loop is init (download providers, configure backend), plan (preview the diff), apply (execute), destroy (tear down) — and plan output showing replace means destroy-and-recreate.
• Team Terraform state belongs in a Cloud Storage backend with state locking and Object Versioning; state maps configuration to real resources and can contain sensitive values.
• Config Connector manages Google Cloud resources as Kubernetes custom resources and continuously reconciles them, giving self-healing infrastructure that Terraform's on-demand applies do not.
• Helm packages Kubernetes applications as parameterized charts with versioned, rollback-capable releases — it deploys apps to GKE, not cloud infrastructure.
• Fabric FAST is an opinionated, staged Terraform framework that stands up an entire organization's landing zone from Google's best practices.
• Gemini Cloud Assist works in the console, Gemini CLI in the terminal, Google Antigravity as an agentic development platform, and Application Design Center turns visual architecture designs into IaC — all subject to the same review gates as hand-written code.

Ensuring the successful operation of a cloud solution

Managing Compute Engine, GKE, and Cloud Run: Day-2 Operations

• Use gcloud compute ssh with --tunnel-through-iap for instances without external IPs; IAP needs a firewall rule allowing 35.235.240.0/20 on port 22 and the roles/iap.tunnelResourceAccessor role.
• Snapshots are incremental disk backups you can automate with snapshot schedules; custom images are golden templates for launching identical instances.
• GKE nodes pull from Artifact Registry using the node service account, which needs roles/artifactregistry.reader — cross-project ImagePullBackOff means that grant is missing.
• Node pool autoscaling reacts to unschedulable Pods, not node CPU — Pods without resource requests will never trigger scale-up.
• HPA scales replica count, VPA rewrites Pod resource requests, and the cluster autoscaler scales nodes; never drive HPA and VPA from the same CPU or memory metric.
• Autopilot bills by Pod resource requests and provisions nodes for you — requests, not node pools, are the thing you manage.
• Every gcloud run deploy creates a revision; use --no-traffic plus update-traffic --to-revisions for canaries, and tags for private test URLs.
• Shape Cloud Run scaling with min instances (cold starts), max instances (protect backends), and concurrency (requests per instance).

Managing Cloud Storage and Databases: Lifecycle, Backups, and CMEK

• Prefer uniform bucket-level access so IAM alone governs Cloud Storage; fine-grained ACLs are legacy and only for per-object permission schemes.
• Signed URLs grant time-limited access to a single object without Google accounts or IAM changes — the answer for external, temporary sharing.
• Lifecycle rules pair actions (SetStorageClass, Delete) with conditions (age, isLive, numNewerVersions, daysSinceNoncurrentTime); cold classes carry minimum storage durations and retrieval fees.
• Match query tool to service: gcloud sql connect or the Auth Proxy for Cloud SQL, bq for BigQuery, gcloud spanner databases execute-sql for Spanner, cbt for Bigtable, client libraries for Firestore.
• Cloud SQL PITR needs automated backups plus transaction logging and restores to a new instance at an exact timestamp — backups restore to a state, PITR to a moment.
• Check jobs where they run: Dataflow Jobs page or gcloud dataflow jobs, and bq ls -j / bq show -j or INFORMATION_SCHEMA.JOBS for BigQuery; drain finishes in-flight streaming data, cancel drops it.
• Database Center gives fleet-wide inventory, health issues, and recommendations across all database services in one console view.
• CMEK requires granting the service agent roles/cloudkms.cryptoKeyEncrypterDecrypter on the Cloud KMS key; disabling or destroying the key makes the data inaccessible.

Managing VPC Networking: Subnets, Static IPs, Cloud DNS, and Cloud NAT

• Subnet ranges can only expand — gcloud compute networks subnets expand-ip-range decreases the prefix length in place with no downtime, and auto mode subnets cap at /16
• Static external IPs survive instance restarts and can be promoted from an in-use ephemeral address; internal static IPs come from the subnet range and stay VPC-only
• Custom static routes pick a next hop (gateway, instance, internal load balancer, VPN tunnel); most-specific destination wins, then lowest priority value — and subnet routes can never be overridden
• Cloud DNS private zones answer only from authorized VPC networks; public zones serve the internet and require delegating the domain to Google name servers
• Cloud NAT on a Cloud Router provides egress-only internet access for instances without external IPs; manual NAT IPs give partners a fixed address to allowlist
• VPC firewall rules are stateful with implied deny-all ingress and allow-all egress; lower priority number wins, and targets should prefer service accounts over network tags
• Cloud NGFW hierarchical firewall policies attach to the organization or folders, evaluate before VPC rules, and cannot be overridden by project teams

Cloud Monitoring and Logging: Alerts, Log Sinks, and Audit Logs

• Cloud Monitoring handles numeric time series and alerting; Cloud Logging handles discrete log entries, storage, and routing — log-based metrics bridge logs into alertable metrics
• An alerting policy is conditions plus notification channels: metric, threshold, and a duration window to suppress blips; metric-absence conditions catch heartbeats going silent
• Admin Activity audit logs are always on and free; Data Access audit logs are off by default (except BigQuery) and must be enabled before the read you want to investigate happens
• VPC Flow Logs are enabled per subnet and sampled; firewall logging is enabled per rule, and implied rules never log
• The Log Router delivers entries to sinks; destinations are log buckets, BigQuery, Cloud Storage, and Pub/Sub — Pub/Sub is the export path to on-premises and external systems
• A sink's writer identity service account must be granted access on the destination, or delivery silently fails; aggregated sinks at folder or organization level centralize logs with --include-children
• The Ops Agent unlocks memory, disk-space, and in-guest application telemetry on VMs; Managed Service for Prometheus keeps PromQL and exporters while Google runs the storage
• Match symptom to tool: Trace for cross-service latency, Profiler for CPU and heap, Query Insights for slow SQL, Personalized Service Health for Google-side incidents, Active Assist for optimization recommendations

Configuring access and security

Managing Cloud IAM: Roles, Policies, and Inheritance

• An IAM policy is a set of role bindings on a resource; each binding ties one role to principals, optionally with a condition
• Permissions are never granted directly — they travel only inside basic, predefined, or custom roles
• Inheritance is additive and allow-only: effective access is the union of all ancestor policies, and a lower level cannot revoke an inherited grant
• Prefer predefined roles granted to groups at the lowest hierarchy level that satisfies the requirement; avoid basic Owner/Editor/Viewer in production
• gcloud projects get-iam-policy views a policy; add-iam-policy-binding and remove-iam-policy-binding edit it; set-iam-policy replaces it wholesale
• Custom roles exist at the project or organization level only — never at the folder level — and Google does not maintain them for you
• Custom role launch stages (ALPHA, BETA, GA, DEPRECATED, DISABLED) signal maturity to admins but do not change enforcement
• Grant the same access across many projects with one folder- or organization-level binding, not per-project copies

Service Accounts, Impersonation, and Workload Identity Federation

• Service accounts come in three kinds: Google-managed service agents (hands off), auto-created default service accounts (historically over-privileged — avoid for workloads), and user-managed accounts you create per workload
• Grant service accounts minimum roles exactly like users — one account per workload, resource-level bindings where possible, never Editor for convenience
• Attaching a service account to a VM, Cloud Run service, or GKE workload delivers auto-refreshed short-lived tokens with no secret in your code; attaching requires serviceAccountUser on the account
• A service account is both a principal (its roles on other resources) and a resource (its own IAM policy controlling who can use, impersonate, or administer it)
• serviceAccountUser lets a principal attach and act as the account; serviceAccountTokenCreator lets them impersonate it — both are escalation paths, so grant them per-account, not project-wide
• Service account keys never expire, travel anywhere, and leak easily — block them with constraints/iam.disableServiceAccountKeyCreation and treat creation as a last resort
• Impersonation mints one-hour credentials on demand with full audit attribution — the keyless replacement for handing humans key files
• Workload Identity links a Kubernetes service account to a Google service account via a workloadIdentityUser binding and a KSA annotation; Workload Identity Federation does the same trust exchange for workloads outside Google Cloud