Before you touch any GCP resource you need the right structure underneath it: an Organisation, Folders, Projects, and Billing Accounts, all tied together with Identity and Access Management (IAM).
Before you touch the console or gcloud, the ACE exam wants you to think about project structure, resource hierarchy, and billing. Everything in Google Cloud sits inside a hierarchy: Organization > Folders > Projects > Resources. Folders group projects (e.g. by department or environment) and IAM policies inherit downward. A resource always belongs to exactly one project, and every project has a unique Project ID (immutable, globally unique) plus a Project Number (auto-assigned) and a Project Name (editable, not unique).
Part of planning is picking the right compute product: Compute Engine (VMs, full control), Google Kubernetes Engine (containers, orchestration), App Engine (fully managed PaaS, zero infra), Cloud Run (managed containers, scales to zero), and Cloud Functions (event-driven, single purpose). The exam loves scenario questions - match workload needs (stateful vs stateless, scaling to zero, custom runtime) to the right service.
A billing account must be linked to a project before you can use most services. Billing accounts can be self-serve (credit card) or invoiced. Budgets and alerts are set per billing account or per project, with configurable threshold percentages (e.g. 50%, 90%, 100%) - alerts notify but do NOT automatically stop spending unless you build automation (e.g. a Cloud Function triggered by a Pub/Sub budget notification that disables billing).
GCP enforces two types of quotas: rate quotas (reset after a time interval, e.g. API calls per 100 seconds) and allocation quotas (fixed resource counts, e.g. number of VPCs per project). Quotas are checked at project and region level. You can request quota increases via the console (IAM & Admin > Quotas) - some increases are automatic, others need Google approval and can take days.
Resources are either global (e.g. images, snapshots, VPC networks), regional (e.g. subnets, static external IPs), or zonal (e.g. VM instances, persistent disks, GKE zonal clusters). A key planning mistake is placing a VM in one zone but its persistent disk in another - they must match. Choose regions based on latency to users, price, and compliance/data-residency needs.
Compute Engine gives you full control over VMs. You choose machine type, boot disk image, network, and startup scripts. Use instance templates to define a reusable VM config, then instance groups to deploy at scale.
GKE runs containerised workloads on managed Kubernetes clusters.
App Engine is a fully managed, serverless platform for deploying application code without managing servers.
Google Cloud IAM controls who (identity) can do what (role) on which resource. Every permission check follows this identity + role + resource pattern. You almost never grant permissions directly - you grant roles, and roles bundle permissions together.
Identities can be Google accounts, service accounts, Google groups, Cloud Identity domains, or 'allUsers'/'allAuthenticatedUsers' for public access. Prefer groups over individual users for easier management at scale.
Policies flow downward: Organisation > Folder > Project > Resource. A role granted at the organisation level is inherited by every folder, project and resource beneath it. You cannot restrict a permission lower down that was granted higher up - only add more. Deny policies (a separate feature) can block access regardless of allow policies, and deny always wins over allow.
A service account is an identity for applications/VMs, not a person. Each has an email like PROJECT_NUMBER-compute@developer.gserviceaccount.com (default Compute Engine SA) or name@project.iam.gserviceaccount.com. Avoid using the default service account with the broad Editor role in production - assign a custom SA with minimal roles instead. Service account keys (JSON) are a security risk if leaked - prefer attaching SAs directly to resources or using Workload Identity Federation instead of downloading keys.
A VPC network is global, but subnets are regional and span all zones in that region.
VPC networks come in two flavours: auto mode (one subnet per region, created automatically, /20 ranges) and custom mode (you define subnets and ranges yourself). Custom mode is best practice for production.
Subnets have a primary IP range plus optional secondary ranges, used for GKE alias IPs (pods and services).
Firewall rules are stateful, apply at the VPC level (not per subnet), and use priority numbers from 0-65535 (lower number = higher priority). Default rules: implied allow egress, implied deny ingress.
Know the split: global external load balancers (HTTP(S), SSL Proxy, TCP Proxy) front global backends and need Premium Tier networking; regional load balancers (Internal HTTP(S), Internal TCP/UDP, external regional Network LB) stay within one region.
HTTP(S) Load Balancing is Layer 7 and can route by URL path/host; Network Load Balancing is Layer 4 (pass-through).
Cloud Storage buckets are globally unique by name and hold objects, not filesystems. Four storage classes by access pattern, not performance: Standard (frequent access), Nearline (accessed <1x/month, 30-day minimum), Coldline (<1x/quarter, 90-day minimum), Archive (<1x/year, 365-day minimum). Early deletion before the minimum duration still incurs the full minimum-duration charge.
Use Object Lifecycle Management rules to auto-transition or delete objects by age/class/version.
Bucket location can be region, dual-region, or multi-region - multi-region gives higher availability, region gives lowest latency to a single area.
Persistent Disk (zonal or regional) attaches to Compute Engine VMs like a virtual hard drive - zonal PD survives one zone only, regional PD replicates across two zones for HA.
Filestore provides managed NFS file storage for multiple VMs needing shared file access.
Cloud SQL is managed relational (MySQL/PostgreSQL/SQL Server); Cloud Spanner is for globally distributed, horizontally scalable relational needs; Firestore/Bigtable are NoSQL (Firestore = document/mobile-web, Bigtable = huge analytical/time-series workloads).