The GCP-ACE blueprint is split across 4 domains. Weights are the official share of the exam; see the official exam guide for the authoritative breakdown.
What you must be able to do. Stand up a well-ordered project and billing foundation: a resource hierarchy that inherits policy correctly, IAM and Cloud Identity in place, quotas assessed, and budgets that warn before spend runs away.
In one sentenceThe foundation the rest of the platform sits on: the organisation, folder, and project hierarchy, Cloud Identity, enabling APIs and assessing quotas, and billing accounts with budgets and alerts.
Recall check: answer these from memory first
- State the levels of the resource hierarchy in order, and say how a policy attached to a folder reaches a project created inside it later.
- Explain in one line what a Cloud Billing budget alert does and does not do.
- Distinguish a quota increase from a capacity guarantee, and say what you do when a zone is out of a resource.
What it tests. Setting up cloud projects and accounts: creating a resource hierarchy, applying organisation policies to it, granting IAM roles within a project, and managing users and groups in Cloud Identity. It also covers enabling APIs, assessing quotas and requesting increases, configuring Cloud Asset Inventory and Workforce Identity Federation, and managing billing: creating billing accounts, linking projects, and setting budgets, alerts, and exports.
How to study it. Get the hierarchy solid first, because later domains lean on it: organisation, folder, project, resource, and how a policy set at one level reaches everything below. Learn that a Cloud Billing budget only notifies and never caps spend, because the exam plants that trap repeatedly. Practise the difference between a per-project, per-region quota and actual capacity, and know that a quota increase raises a ceiling but does not reserve resources. Keep Workforce Identity Federation (external human sign-in) distinct from Workload Identity Federation (external workloads).
Easy to confuse
- A budget alert versus a spending cap. A Cloud Billing budget only sends a notification when spend crosses a threshold; it never stops or caps charges by itself. To actually halt spend you wire the budget's Pub/Sub message to automation that disables billing, so an option promising a budget alone stops overspend is the distractor.
- Workforce Identity Federation versus Workload Identity Federation. Workforce Identity Federation lets external human users sign in with an external identity provider; Workload Identity Federation lets external workloads and CI systems authenticate without a service account key. If the scenario is people signing in it is Workforce; if it is a machine or pipeline it is Workload.
- A quota versus available capacity. A quota is an administrative per-project, per-region ceiling you can request to raise; capacity is whether Google actually has the resource in that zone at that moment. Raising a quota does not reserve capacity, so a stockout is solved with a reservation or another zone, not a quota request.
Worked example from the GCP-ACE bank
lock_openFree sampleSetting up a cloud solution environmentmedium
A boolean organization policy constraint is enforced on a folder. A team then creates a new project inside that folder, and no policy is set directly on the project. How does the constraint apply to the new project?
- AThe constraint is inherited from the folder and enforced on the new project, because a project evaluates an effective policy built from every ancestor above it.check_circle Correct
- BThe constraint does not reach the project, because organization policies attach to the organization node and folders but stop above the project level.
- CThe constraint applies only after an administrator re-applies it on the project, since existing policies do not propagate to resources created after the policy is set.
- DThe constraint is inherited but downgraded to advisory, so violations on the project are recorded in Cloud Logging instead of being blocked.
An organization policy set on a folder is inherited by and enforced on every project created beneath it. The Resource Manager computes an effective organization policy for each node by combining that node's own policy with those inherited from its ancestor folders and organization, so a folder-level constraint reaches all descendant projects even those created afterwards.
Why A is correct: Correct: the effective policy for any node is the result of evaluating its own policy against those inherited from the folders and organization above it, so a folder constraint applies to child projects.
Why B is wrong: It sounds plausible if you assume policies protect only higher tiers, but organization policies attach to and are enforced at organization, folder, and project nodes alike.
Why C is wrong: The timing detail is tempting, but inheritance is evaluated dynamically at each request, so a project created later still inherits the folder policy without any manual re-application.
Why D is wrong: It borrows the idea of a dry-run mode, but an enforced organization policy actively blocks non-compliant actions rather than merely logging them as advisory events.
What you must be able to do. Choose and deploy the right compute, storage, data, and networking building blocks for a workload under real constraints, and provision them repeatably with the appropriate tooling.
In one sentenceThe build domain and one of the two largest: selecting compute, storage and data products, and networking, and provisioning them with Infrastructure as Code and AI-assisted tooling.
Recall check: answer these from memory first
- Give the one-line signal that points a workload at Cloud Run rather than Compute Engine or GKE.
- Match Cloud SQL, Spanner, Bigtable, Firestore, and BigQuery each to the access pattern it fits best.
- State which firewall rule wins when two match a packet, and name the four Cloud Storage classes in order of access frequency.
What it tests. Planning and implementing a cloud solution: selecting compute for a workload among Compute Engine, Google Kubernetes Engine, Cloud Run, and Cloud Run functions, launching instances, creating autoscaled managed instance groups, and deploying GKE clusters and serverless event-driven services. It covers choosing data and storage products and Cloud Storage classes, VPCs and subnets, firewall rules and Cloud NGFW, connectivity and load balancer selection, and Infrastructure as Code with Terraform, Config Connector, and Helm.
How to study it. This is one of the two heaviest domains, so spend the most time here. Build a decision table for compute (Compute Engine for control and specific OS or kernel needs, GKE for portable multi-service containers, Cloud Run for stateless request-driven scale-to-zero, Cloud Run functions for small event handlers) and another for data products keyed to access pattern, consistency, and scale. Learn Cloud Storage classes by their minimum-duration and retrieval-cost trade-off, and firewall rules by direction and priority, where a lower priority number wins. Practise reading a scenario for the one constraint that eliminates the tempting-but-wrong service.
Easy to confuse
- Cloud Run versus GKE versus Compute Engine. Cloud Run runs stateless request-driven containers and scales to zero with no cluster to manage; GKE gives you Kubernetes for portable multi-service workloads you operate; Compute Engine gives full VM control for a specific OS, kernel module, or licensing need. The constraint in the stem, not the product's general power, decides which is best.
- Spanner versus Cloud SQL. Cloud SQL is a managed single-region relational database for standard OLTP workloads; Spanner is horizontally scalable relational with strong global consistency and a higher cost. Reach for Spanner only when the scenario needs global scale or multi-region strong consistency, not by default for any relational need.
- Firewall rule priority. When two VPC firewall rules match the same packet, the one with the lower priority number takes effect, and a hierarchical firewall policy is evaluated before VPC rules. A candidate who assumes a higher number or a later rule wins picks the distractor.
Worked example from the GCP-ACE bank
lock_openFree samplePlanning and implementing a cloud solutionhard
A team wants the lowest ongoing operational overhead for a stateless HTTP API and is willing to give up control over the host operating system. Which characteristic correctly distinguishes Cloud Run from Compute Engine for this workload?
- ACloud Run runs containers on a fully managed platform where Google patches and maintains the underlying infrastructure, whereas Compute Engine gives you a VM whose guest OS you must patch and maintain yourself.check_circle Correct
- BCloud Run requires you to size and patch worker VMs in the same way Compute Engine does, but bills you per request instead of per second of VM uptime.
- CCompute Engine automatically builds and deploys your container image from source, so it carries less deployment overhead than Cloud Run for a stateless API.
- DBoth services abstract the guest operating system equally, so the only real difference for this API is the region where each one can be deployed.
Understand that Cloud Run is a fully managed platform while Compute Engine leaves guest OS maintenance to the customer. Cloud Run abstracts the host and OS so Google patches the infrastructure, while Compute Engine is infrastructure-as-a-service where the customer owns and patches the guest operating system on each VM.
Why A is correct: Cloud Run is a managed serverless container platform, so Google operates the hosts and the candidate manages only the container image and its configuration, while Compute Engine hands you a VM you must patch.
Why B is wrong: This is tempting because both can run the same code, but it is wrong: fully managed Cloud Run exposes no worker VMs for you to size or patch, so the operational overhead claim is false.
Why C is wrong: This inverts the products: Compute Engine gives raw VMs and does no source-to-container build, whereas Cloud Run is the service designed to deploy container images or source directly.
Why D is wrong: This is wrong on substance because Compute Engine does not abstract the guest OS at all; you own patching on the VM, and region availability is not the distinguishing factor here.
What you must be able to do. Keep a running solution healthy: manage live compute, storage, and networking, and use Google Cloud Observability to detect and diagnose problems before users do.
In one sentenceThe operate domain and the other of the two largest: managing running compute, storage, and networking, plus monitoring and logging with Google Cloud Observability.
Recall check: answer these from memory first
- Describe how you run a gradual or canary rollout between two Cloud Run revisions.
- Distinguish horizontal Pod autoscaling, vertical Pod autoscaling, and the GKE cluster autoscaler in one line each.
- Name the tool that gives instances without an external IP outbound internet access, and the agent that collects VM metrics and logs.
What it tests. Ensuring the successful operation of a cloud solution: managing compute (connecting to instances, snapshots and images, GKE node pools and Pod autoscaling, Cloud Run revisions and traffic splitting), managing storage and data (bucket security, lifecycle rules, backups, and customer-managed encryption keys), and managing networking (subnet ranges, static IPs, routes, Cloud DNS, and Cloud NAT). It also covers monitoring and logging: Cloud Monitoring alerts, log sinks and buckets, the Ops Agent, and Managed Service for Prometheus.
How to study it. This domain shares top weight with the build domain, so give it heavy time too. Practise the day-two operations: split traffic across Cloud Run revisions for a canary, autoscale a GKE node pool versus scale Pods with horizontal Pod autoscaling, and schedule Compute Engine snapshots for backup. Learn Cloud Storage lifecycle rules by their conditions and actions, and remember that a SetStorageClass action only moves objects to a colder class. On observability, keep Cloud Monitoring (metrics and alerts) and Cloud Logging (logs and sinks) straight, use only current names, and know the Ops Agent is the unified collector for VM metrics and logs.
Easy to confuse
- Horizontal Pod autoscaling versus the GKE cluster autoscaler. Horizontal Pod autoscaling adds or removes Pod replicas based on a metric such as CPU; the cluster autoscaler adds or removes nodes so Pods have somewhere to run. A Pod stuck pending for lack of a resource request is an HPA or scheduling issue, not a node-count one, so the exam tests which layer the symptom belongs to.
- A snapshot versus an image. A snapshot is an incremental backup of a persistent disk used to restore or clone that disk; an image is used to create new instances or an instance template. If the goal is backup and restore it is a snapshot; if it is standardising new VMs it is an image.
- Cloud NAT versus a static external IP. Cloud NAT gives instances that have no external IP outbound access to the internet without exposing them to inbound traffic; a reserved static external IP gives a resource a fixed public address that does not change. One is about egress for private instances, the other about a stable inbound address.
Worked example from the GCP-ACE bank
lock_openFree sampleEnsuring the successful operation of a cloud solutionmedium
A GKE Standard cluster runs some workloads that need GPU machine types and others that need only general-purpose CPUs. Which statement correctly describes what a node pool provides in this cluster?
- AA node pool is a single Compute Engine VM whose machine type every workload in the cluster must share, so mixed hardware needs are met by resizing that one VM.
- BA node pool is the Kubernetes object that stores application state, so placing GPU workloads in it guarantees their data survives when a node is restarted or replaced.
- CA node pool is a namespace-scoped policy that reserves CPU and memory for Pods, with no relationship to the machine type of the underlying nodes.
- DA node pool is a group of nodes within the cluster that share one configuration, so you can create one pool with GPU machine types and another with general-purpose machine types.check_circle Correct
Recognise that a GKE node pool groups nodes of a shared configuration and that a cluster can hold several pools of different machine types. A node pool is a subset of nodes within a GKE cluster that all share the same configuration, including machine type; a cluster can run multiple pools, letting different hardware profiles such as GPU and general-purpose exist side by side.
Why A is wrong: This is tempting because a node is backed by a VM, but a node pool is a set of nodes rather than one VM, and a cluster can hold several pools, so mixed hardware is served by separate pools.
Why B is wrong: This confuses a node pool with persistent storage; a node pool defines node configuration and does not itself hold application state, which is provided by persistent volumes instead.
Why C is wrong: Resource reservation for Pods is done with requests and limits or quotas, whereas a node pool is a cluster-level grouping of nodes tied directly to their machine type.
Why D is correct: A node pool groups nodes of identical configuration, and a cluster can contain multiple pools, so a GPU pool and a general-purpose pool coexist and the scheduler places each workload on suitable nodes.
What you must be able to do. Grant exactly the access a person or workload needs and no more: the right IAM role at the right scope, and service accounts that authenticate without long-lived keys.
In one sentenceThe identity and security domain: IAM policies and role types with correct inheritance, and service accounts using impersonation and federation instead of exported keys.
Recall check: answer these from memory first
- Given a requirement to read objects in one bucket, say which role you grant and why not Editor.
- Explain where you attach an IAM binding so a team gets access to exactly the intended projects and no wider.
- Name the keyless ways a GKE application and an external CI pipeline each authenticate as a service account.
What it tests. Configuring access and security: viewing and creating IAM policies, attaching roles and understanding inheritance in the organisation hierarchy, and managing basic, predefined, and custom role types. It also covers service accounts: creating them with minimum permissions, assigning them to resources, managing impersonation and short-lived credentials, using a service account with a GKE application through Workload Identity, and provisioning Workload Identity Federation.
How to study it. Make least privilege automatic: when a scenario asks how to grant access, reach for the narrowest predefined role, and a custom role only when no predefined one fits. Learn the three role types cold (basic is broad and legacy, predefined is granular and Google-maintained, custom is your own permission set) and where a binding attaches so inheritance carries it to exactly the intended scope. On service accounts, learn why exported keys are the higher-risk choice and how impersonation, Workload Identity for GKE, and Workload Identity Federation for external workloads all avoid them. Keep the distinction between a role granted on a service account and a role granted to it.
Easy to confuse
- A basic role versus a predefined role. Basic roles (Owner, Editor, Viewer) are broad, legacy, project-wide grants; predefined roles are granular and scoped to a service, such as Storage Object Viewer. The exam almost always wants the narrowest predefined role that satisfies the requirement, so a basic role in the answer is usually the distractor.
- A role granted on a service account versus to it. Granting a role on a service account (such as Service Account User) lets a principal use or impersonate that account; granting a role to the service account gives the account itself permissions on other resources. The exam tests whether you can tell who is being authorised to do what.
- Workload Identity versus Workload Identity Federation. GKE Workload Identity binds a Kubernetes service account to a Google Cloud service account so Pods authenticate without a key; Workload Identity Federation lets a workload outside Google Cloud, such as GitHub Actions or AWS, authenticate without a key. One is inside GKE, the other is for external workloads.
Worked example from the GCP-ACE bank
lock_openFree sampleConfiguring access and securitymedium
A colleague new to Google Cloud asks how the three IAM role types differ. Which statement correctly characterises basic, predefined, and custom roles?
- ABasic roles are granular roles maintained by Google for a single service, predefined roles are the legacy Owner, Editor, and Viewer, and custom roles are copies of basic roles scoped to one project.
- BBasic roles are the broad legacy Owner, Editor, and Viewer roles, predefined roles are granular Google-maintained roles for specific services, and custom roles let you assemble a chosen set of permissions.check_circle Correct
- CBasic roles apply only to Cloud Storage buckets, predefined roles apply only to Compute Engine, and custom roles are the sole way to grant access to any other Google Cloud service.
- DBasic roles and predefined roles are both authored by the customer, whereas custom roles are supplied and updated automatically by Google as services change.
Distinguish basic roles as broad legacy roles, predefined roles as granular Google-maintained roles, and custom roles as customer-defined permission sets. IAM offers three role types: basic roles (Owner, Editor, Viewer) grant broad legacy access, predefined roles give granular Google-maintained permissions per service, and custom roles let an administrator combine exactly the permissions a task requires.
Why A is wrong: This swaps the definitions of basic and predefined roles; Owner, Editor, and Viewer are the basic roles, while the granular per-service roles maintained by Google are the predefined ones.
Why B is correct: This matches the model exactly: basic roles are broad and legacy, predefined roles are fine-grained and maintained by Google, and custom roles are built by selecting the specific permissions you want.
Why C is wrong: This invents per-service limits that do not exist; basic and predefined roles both span many services, and custom roles are an option for tailoring permissions rather than the only route to most services.
Why D is wrong: This reverses authorship; basic and predefined roles are provided and maintained by Google, while custom roles are the ones the customer authors and must maintain themselves.