Google Cloud’s current Associate Cloud Engineer standard exam uses the v4.0 exam guide. As of October 2026, the guide organizes the role into four sections: Setting up a cloud solution environment at about 23%, Planning and implementing a cloud solution at about 30%, Ensuring successful operation of a cloud solution at about 27%, and Configuring access and security at about 20%.
The current Associate Cloud Engineer standard exam is two hours, costs USD 125 plus applicable tax, contains 50–60 multiple-choice and multiple-select questions, has no formal prerequisite, and recommends at least six months of hands-on Google Cloud experience. The certification is valid for three years.
Section 1: Setting up a cloud solution environment is about 23%
The first section covers the administrative foundation of Google Cloud: resource hierarchy, organization policies, IAM role assignments, Cloud Identity users and groups, API enablement, Google Cloud Observability setup, quotas, standalone organizations, cloud networking, product availability by location, Cloud Asset Inventory, and billing configuration.
This section is broader than “create a project.” It asks whether the engineer can establish a governed environment in which later workloads can be deployed safely and predictably.
Hierarchy, policy, and IAM define the operating boundary
Organizations, folders, and projects determine where resources live and where policy or IAM can be inherited. Organization Policy can constrain resource behavior across the hierarchy, while IAM grants people and service identities permission at the appropriate scope.
An IAM foundation is essential because permissions, inheritance, and least privilege influence nearly every later task in the exam.
Billing, quotas, locations, and inventory are engineering concerns
The current guide includes billing accounts, project-to-billing links, budgets and alerts, billing exports, quota assessment, and geographical availability of products. These are operational constraints, not administrative trivia. A deployment can fail or become expensive because quota, location, or billing assumptions were wrong.
Cloud Asset Inventory also appears in the current guide, giving engineers a way to inspect existing resources before making changes. Gemini Cloud Assist may be used to help analyze those resources, but the underlying inventory remains the source that must be understood.
Section 2: Planning and implementing is about 30%
This section covers compute, storage/data, networking, and infrastructure as code. Compute choices include Compute Engine, Google Kubernetes Engine, Cloud Run, Cloud Run functions, and event-driven serverless patterns. Candidates should also know instance templates, managed instance groups, OS Login, VM Manager, Spot VMs, custom machine types, GKE cluster deployment, and containerized applications.
A Compute Engine, GKE, and Cloud Run comparison is useful because the exam expects service selection based on operating model rather than popularity.
Storage and data choices follow the workload
The guide names Cloud SQL, BigQuery, Firestore, Spanner, Bigtable, AlloyDB, Dataflow, Pub/Sub, Google Cloud Managed Service for Apache Kafka, and Memorystore. It also covers Cloud Storage, Filestore, Google Cloud NetApp Volumes, and Cloud Storage classes such as Standard, Nearline, Coldline, and Archive.
A Cloud SQL use case should be recognized as a managed relational workload, while BigQuery is analytical, Bigtable is wide-column, and Cloud Storage handles object data. Loading data and maintaining multi-region redundancy are also part of this section.
Networking is a hands-on implementation area
Candidates should be able to create VPCs and subnets, understand Shared VPC, apply Cloud Next Generation Firewall policies, use secure Tags and service accounts in firewall rules, establish Cloud VPN or VPC Network Peering, understand Cloud Interconnect, select load balancers, and distinguish Network Service Tiers.
A Cloud DNS and load-balancing foundation helps with later operations even though DNS management appears in the operations section rather than as a separate planning domain.
Infrastructure as code is explicitly in scope
The v4.0 guide names Fabric FAST, Config Connector, Terraform, and Helm as examples of infrastructure-as-code tooling. Candidates should understand versioning, state management, updates, and repeatable deployment rather than treating infrastructure as a one-time console exercise.
The practical objective is reproducibility: the same environment should be understandable and deployable without relying on hidden manual steps.
Section 3: Successful operation is about 27%
This section covers day-to-day operation of Compute Engine, GKE, Cloud Run, storage and databases, networking, monitoring, and logging. Compute topics include remote access, snapshots/images, GKE inventory and node pools, Kubernetes resources, horizontal/vertical autoscaling, Autopilot resource requests, Cloud Run revisions, traffic splitting, and autoscaling.
The exam therefore expects candidates to operate what they deploy, not stop at provisioning.
Data, networking, and observability complete operations
Current operations topics include Cloud Storage object security and lifecycle policies, database queries, storage-cost estimation, backups and restores for several database services, Dataflow/BigQuery job status, Database Center, subnet expansion, static IP addresses, custom routes, Cloud DNS, and Cloud NAT.
Monitoring/logging includes alerts, custom metrics, log exports and routers, Cloud Logging, Trace, Profiler, Query Insights, Personalized Service Health, Ops Agent, Managed Service for Prometheus, audit logs, Gemini Cloud Assist for Cloud Monitoring, and Active Assist recommendations.
Section 4: Configuring access and security is about 20%
The final section focuses on IAM policies, basic/predefined/custom roles, service accounts, minimum permissions, assigning service accounts to resources, managing service-account permissions, impersonation, short-lived credentials, and using service accounts with GKE workloads.
This reinforces a modern Google Cloud security principle: workloads should use narrowly scoped identities and temporary authorization rather than long-lived keys whenever possible.
The current ACE is a cloud-operations exam.
The strongest candidate can establish a project environment, deploy compute/data/network resources, define infrastructure through code, operate and troubleshoot those resources, and secure access through IAM and service accounts. Those are connected responsibilities rather than separate product trivia.
The v4.0 guide’s first section also makes project setup more enterprise-aware. Candidates should know why an organization resource, folders, and projects exist; how APIs are enabled; how Cloud Identity users and groups are managed; and how Google Cloud Observability is provisioned early enough that workloads are measurable from the start. These are setup decisions because retrofitting ownership, logging, or policy after a project grows is more difficult.
Organization policy belongs above ordinary IAM because it constrains what resources or configurations may be created, while IAM controls who may perform actions. A project administrator can have broad resource permissions yet still be unable to violate an inherited organization policy. ACE scenarios can therefore require you to distinguish lack of permission from an explicit organizational constraint.
Quota assessment is also a setup responsibility. Compute cores, external IPs, API limits, or other service quotas can block deployment or scaling even when the architecture is otherwise sound. Engineers should check quota and regional capacity before a production rollout rather than discover the limit during an outage or traffic surge.
Standalone organizations appear in the current guide because not every cloud environment begins inside an established enterprise hierarchy. At associate depth, understand the purpose of establishing an organization boundary and how policy, identity, billing, and resource ownership become easier to manage once that boundary exists.
The compute section is operationally detailed. For Compute Engine, the guide expects launching instances, selecting disks, using instance templates and autoscaled managed instance groups, configuring OS Login and VM Manager, and understanding Spot VMs or custom machine types. These are the building blocks of a manageable VM fleet rather than a one-off server.
For GKE, candidates should be comfortable with kubectl setup, cluster deployment options such as Autopilot, regional, or private clusters, and deploying containerized applications. The exam does not require expert Kubernetes internals, but it assumes enough familiarity to create and operate ordinary clusters and workloads.
For serverless deployment, the guide includes Cloud Run and Cloud Run functions, including event-driven processing from Pub/Sub, Cloud Storage object-change notifications, or Eventarc. The key distinction is that the engineer deploys application code or containers while Google manages more of the underlying infrastructure and scaling.
Storage planning includes data loading and multi-region redundancy. Candidates should know that moving data into the chosen service is part of implementation and that the durability/availability design can include regional or multi-region behavior. The most appropriate storage choice depends on data model, access pattern, cost, and resilience.
Cloud Storage classes also matter because access frequency changes economics. Standard is suited to frequently accessed data; Nearline, Coldline, and Archive trade lower storage cost for different access/retrieval characteristics. Object lifecycle policies later automate movement or deletion according to business requirements.
Cloud NGFW policy rules are current networking content. The guide explicitly names ingress/egress rules and attributes such as action, source, destination, targets, protocols, and ports, plus secure Tags and service accounts. That means network policy can follow workload identity or metadata instead of depending only on IP addresses.
Shared VPC is another enterprise design pattern in scope. A host project can provide centrally managed networking to service projects, letting network teams retain control while application teams own their workloads. ACE candidates should recognize this as a project/network governance model rather than ordinary VPC peering.
Infrastructure-as-code state management is important because the tool must know what it already manages. Versioned configuration, reviewed changes, state, and controlled updates help teams avoid drift and accidental replacement. The guide is not testing Terraform syntax alone; it is testing the operational discipline of repeatable infrastructure.
Operations for Compute Engine include remote connection and image/snapshot work. Snapshots and images support recovery, cloning, or fleet management, while SSH/OS Login choices affect administrative access. The engineer should understand which artifact captures disk state versus a reusable machine image.
GKE operations include viewing nodes, Pods, and Services; managing node pools; configuring access to Artifact Registry; and horizontal or vertical Pod autoscaling. Autopilot resource requests also appear. This reinforces that ACE is not only about creating a cluster but also about keeping workloads healthy and scaled.
Cloud Run operations include deploying new versions, adjusting traffic splitting, and configuring autoscaling. A new revision can receive a portion of traffic before full promotion, giving the engineer a controlled rollout mechanism without managing servers directly.
Database operations are similarly practical. The guide includes querying several data services, estimating storage cost, backing up and restoring database instances, reviewing Dataflow or BigQuery job status, and using Database Center to manage a fleet. Candidates should know how to verify data services after deployment, not just create them.
Networking operations include adding or expanding subnets, reserving internal or external static addresses, adding custom static routes, and working with Cloud DNS and Cloud NAT. These tasks require understanding effective reachability and address planning because one route or subnet change can affect many workloads.
Monitoring and logging should be studied by question. Metrics answer resource behavior; custom metrics add application-specific signals; logs and log analytics show events; log routers send data elsewhere; audit logs show administrative or data-access actions; Trace and Profiler investigate application performance; Query Insights targets database-query behavior.
Personalized Service Health is especially useful when symptoms affect multiple resources or users at once. It tells the engineer whether Google Cloud reports a relevant platform event before local configuration is changed unnecessarily. Active Assist, meanwhile, provides optimization recommendations that should still be validated against business intent.
Service accounts should be treated as workload identities with their own permissions and lifecycle. The guide expects creating them, granting minimum permissions, attaching them to resources, managing their IAM policies, using impersonation, issuing short-lived credentials, and using a service account with GKE. Long-lived downloaded keys should not be the default mental model.
Within the broader Google Cloud certification portfolio, ACE validates practical deployment and operations. Final preparation should therefore follow the current v4.0 23/30/27/20 guide rather than older five-section outlines still found in legacy study materials.