Use this as a last-mile review page. ACE gets much easier when you stop treating every question as a compute question and classify it in this order:
- Scope: organization, folder, project, region, zone, resource, or principal?
- Service fit: runtime, data product, network entry point, or storage/database lane?
- Control boundary: IAM, service account, subnet, route, firewall, or peering?
- Operations signal: deployment, logs, metrics, audit, backup, snapshot, or rollback?
ACE answer sequence
Use this when the stem mixes scope, service fit, control boundary, or operations evidence.
flowchart TD
S["Scenario"] --> C["Classify scope first"]
C --> F["Pick the service fit"]
F --> B["Check the control boundary"]
B --> O["Check the operations signal"]
Fastest 10-minute review
| If the question says… |
Strongest first lane |
| business unit, billing separation, or API enablement |
project or folder boundary |
| “simple containerized app” with minimal ops |
Cloud Run before heavier runtimes |
| cluster primitives, node pools, or Kubernetes control |
GKE |
| outbound internet from private VMs |
Cloud NAT, not public IPs on every VM |
| “who changed this” or “who accessed this” |
audit logs |
| threshold alert, SLO drift, or CPU saturation |
Cloud Monitoring |
| app event detail or request failure trace |
Cloud Logging |
| team or workload needs access |
IAM role, binding, scope, or service account before network guesses |
ACE review map
| Official section |
Weight |
Use this cheat-sheet section first |
| 1. Setup |
~20% |
scope ladder, project and billing rules, IAM basics |
| 2. Planning |
~17.5% |
runtime picker, storage/database picker, network chooser |
| 3. Deployment |
~25% |
deployment lanes, VPC rules, service composition |
| 4. Operations |
~20% |
logging vs monitoring, recovery and rollback cues |
| 5. Access & Security |
~17.5% |
IAM scope, service accounts, least privilege, impersonation |
Scope and control-first decision order
flowchart TD
Org["Organization"] --> Folder["Folder"] --> Project["Project"] --> Place["Region / Zone"] --> Resource["Resource"]
Resource --> Control["Control Boundary"]
Control --> Service["Service Fit"]
Service --> Net["Network Path"]
Net --> Ops["Operations Signal"]
Scope ladder
| Layer |
What it really answers |
Strong exam reading |
| organization |
top governance boundary |
org-wide guardrail or admin pattern |
| folder |
grouped projects under one branch |
business-unit or environment grouping |
| project |
billing, IAM, API enablement, and quota boundary |
the main ACE operating lane |
| region |
multi-zone placement area |
residency, latency, and resilience choice |
| zone |
single failure-domain placement |
VM or zonal resource location |
| resource |
one object or service instance |
the exact thing being changed |
Scope traps
| If the stem says… |
Do not jump to… |
Stronger first reading |
| “team needs access” |
bigger VM or another subnet |
IAM member, role, and scope |
| “charge this to a different unit” |
resource labels only |
project or billing-account structure |
| “users in multiple regions need the same entry path” |
regional-only thinking |
global service or multi-region design |
| “private VM cannot reach a service” |
immediate restart or redeploy |
route, firewall, NAT, DNS, or peering boundary |
Runtime and service picker
| Requirement |
Strongest first lane |
Common trap |
| full OS control, legacy software, or custom agents |
Compute Engine |
choosing VMs when a managed runtime is enough |
| containerized app with the least platform work |
Cloud Run |
expecting it to replace every cluster need |
| Kubernetes APIs, node pools, or cluster policy |
GKE |
choosing it without a real Kubernetes requirement |
| event-triggered short logic |
Cloud Functions |
stretching it into full app hosting |
| large-scale analytical SQL |
BigQuery |
treating Cloud SQL like a warehouse |
| object durability, exports, archives, and media |
Cloud Storage |
confusing it with attached disks |
| transactional relational application store |
Cloud SQL |
using it for warehouse-style analytics |
| globally distributed document pattern |
Firestore |
forcing relational assumptions onto it |
| event fan-out and async messaging |
Pub/Sub |
using it as a database |
Deployment and change-control cues
| If the question is really about… |
Strongest first lane |
| repeatable infrastructure review and rollout |
Terraform or IaC workflow |
| container revision traffic shaping |
Cloud Run rollout or traffic split |
| cluster deployment primitives |
GKE + kubectl, manifests, or Helm |
| one-off admin shell work |
Cloud Shell or gcloud |
| image-based VM fleet standardization |
instance templates and managed instance groups |
Storage and database fit
| Requirement |
Strongest first lane |
Why |
| immutable files, backups, exports, and object lifecycle |
Cloud Storage |
storage classes and object semantics |
| petabyte analytics over large datasets |
BigQuery |
warehouse and analysis path |
| managed MySQL, PostgreSQL, or SQL Server |
Cloud SQL |
operational relational workload |
| globally distributed JSON-like document access |
Firestore |
document database path |
| attached block storage for one VM or instance template |
persistent disk |
block semantics |
| managed shared file path |
Filestore |
file protocol and shared-mount path |
High-confusion storage pairs
| Pair |
Keep this distinction clear |
| Cloud Storage vs persistent disk |
object storage versus attached block storage |
| BigQuery vs Cloud SQL |
analytics warehouse versus transactional relational engine |
| Cloud SQL vs Firestore |
relational transactions versus document model |
| storage class choice vs engine choice |
cost-retention lever versus application data-model decision |
Networking and traffic path rules
| Requirement |
Strongest first lane |
| explicit subnet planning |
custom mode VPC |
| default starter subnet layout |
auto mode VPC |
| permit or block traffic |
firewall rules or higher policy controls |
| private traffic between cloud networks |
peering or the right private connectivity model |
| private outbound internet from internal VMs |
Cloud NAT |
| internal or external name resolution |
Cloud DNS |
| global entry path to distributed backends |
global load balancing |
| regional entry path |
regional load balancing |
Network troubleshooting order
| Check |
Why it comes early |
| DNS |
bad names look like bad routes |
| route |
no path means no connectivity |
| firewall |
reachable networks can still block traffic |
| NAT or egress design |
private VMs often need outbound internet without public IPs |
| peering or private connectivity boundary |
the path itself may be missing |
Networking traps
| Trap |
Better reading |
| “peering fixes everything” |
peering gives path only; routes and firewalls still matter |
| “VM needs internet” |
first ask whether it needs public inbound reachability or only outbound egress |
| “load balancer” |
first classify global versus regional |
| “DNS issue” |
separate naming from routing and filtering |
IAM and security quick rules
| If the question is really about… |
Strongest first lane |
| who has access right now |
inspect IAM policy at the relevant scope |
| common job-function permissions |
predefined role |
| narrower least-privilege gap |
custom role |
| workload identity without static user credentials |
service account |
| temporary delegated use of another principal |
service account impersonation |
| broad governance guardrail |
higher-scope organization or folder policy |
IAM boundary table
| Item |
What it is |
Do not confuse it with |
| role |
permission bundle |
a principal |
| binding |
assignment of role to member |
the role definition itself |
| service account |
workload principal |
a human administrator |
| impersonation |
short-lived delegated use |
distributing long-lived keys |
| audit log |
record of who did what |
performance metrics |
Operations and recovery cues
| Symptom or need |
Inspect first |
| thresholds, CPU, latency, saturation, uptime trend |
Cloud Monitoring |
| request failures, app events, stack traces, detailed system messages |
Cloud Logging |
| admin activity or access history |
audit logs |
| bad deployment version |
revision history, rollout controls, or traffic split |
| VM recovery path |
snapshots, images, backups, or instance history |
| private service reachability failure |
route, firewall, NAT, subnet, and target location |
Logging versus monitoring
| Question |
Cloud Logging |
Cloud Monitoring |
| Main job |
event records and detailed log messages |
metrics, dashboards, thresholds, and alerts |
| Strongest first when |
you need what happened |
you need trend or health signal |
| Common trap |
expecting logs alone to act like alerts |
expecting metrics to explain the full event record |
High-confusion pairs
| Pair |
Keep this distinction clear |
| project vs folder |
workload boundary versus higher admin grouping |
| region vs zone |
broader placement area versus one failure-domain location |
| role vs binding |
permission set versus assignment |
| service account vs user |
workload identity versus human identity |
| Cloud Run vs GKE |
managed container runtime versus Kubernetes control need |
| logging vs audit |
general event record versus governance-focused who-did-what record |
| peering vs Cloud NAT |
private network reachability versus outbound internet egress |
| global vs regional load balancing |
cross-region entry versus region-scoped entry |
| Tool or surface |
Why ACE mentions it |
gcloud |
primary CLI for create, inspect, and change operations |
| Cloud Shell |
fast browser-based admin shell with Google Cloud tooling |
kubectl |
cluster and workload operations on GKE |
| Terraform |
repeatable reviewed infrastructure changes |
| Cloud Console |
visual admin and inspection path |
Last 15-minute review
| Recheck this |
Because the miss often hides here |
| scope words such as project, folder, region, zone, and principal |
wrong answers often solve the wrong boundary |
| managed versus self-managed runtime fit |
the simpler managed service usually wins |
| logging versus monitoring versus audit |
these are different operator lanes |
| route, firewall, NAT, and peering |
networking questions punish blurred boundaries |
| role, binding, service account, and impersonation |
IAM questions often fail on one boundary mismatch |
What strong ACE answers usually do
- fix the scope or access boundary before tuning the workload
- choose the most operationally appropriate managed service
- separate private connectivity, traffic filtering, and name resolution
- inspect the right signal before making a broad infrastructure change
- prefer the answer that is easier to operate, audit, and explain