Google Cloud Associate Cloud Engineer Study Guide

Domain 1: Setting Up a Cloud Solution Environment

Key concepts you must know · 148 practice questions

The resource hierarchy is Organization > Folders > Projects > Resources; IAM policies set at a higher level are inherited by everything below, and child-level policies are additive (you cannot remove an inherited grant lower down).
An Organization node requires a Cloud Identity or Google Workspace account tied to a verified domain; it is created automatically the first time such a domain user signs in to Google Cloud.
Use Organization Policy constraints (e.g. gcp.resourceLocations) for centralized governance above IAM; the Resource Locations constraint can restrict resource creation to specific regions such as us-east1 and us-central1.
constraints/compute.trustedImageProjects restricts which projects images can be created from; constraints/storage.uniformBucketLevelAccess and the public-access-prevention constraint help lock down Cloud Storage.
Each project has a globally unique, immutable Project ID, a mutable Project Name, and a system-assigned Project Number; billing must be linked to a project before most resources can be created.
To create or link billing you need Billing Account Administrator; to associate a project with an existing billing account you need the Billing Account User role plus project-level billing permissions.
Set budgets and alerts under Billing > Budgets & alerts; budgets do NOT cap spend by default. To actually stop spend, publish budget notifications to a Pub/Sub topic that triggers a Cloud Function which disables billing on the project.
Enable billing export to BigQuery in the billing account settings, choose a destination dataset, and grant analysts the BigQuery Data Viewer role on that dataset for detailed cost analysis.
APIs must be enabled per project before use: gcloud services enable compute.googleapis.com (or container.googleapis.com, etc.); script enablement by iterating projects with gcloud services enable.
gcloud named configurations let you store separate project/account/region settings: gcloud config configurations create <name>, then gcloud config configurations activate <name> to switch contexts.
Cloud Shell is a free, ephemeral Debian VM with the SDK preinstalled and 5 GB of persistent $HOME storage; the VM itself is reclaimed after about 20 minutes of inactivity (non-home data is lost).
If gcloud is 'command not found' after installing the Cloud SDK, the SDK's bin directory has not been added to the system PATH environment variable.
Manage users and groups in Cloud Identity either by hand in the Admin console or automatically with Google Cloud Directory Sync, which mirrors an on-premises LDAP or Active Directory into Cloud Identity. Grant IAM roles to groups rather than to individuals so joiners and leavers are handled by group membership alone.
Quotas are per-project and per-region limits, separate from billing. Check current consumption under IAM & Admin > Quotas and request an increase before a launch rather than after a deployment fails; a quota error is not something more spending fixes on its own.
Not every product exists in every location, so verify availability across regions and zones before you design around a service. Resources are zonal (VM instances, zonal disks), regional (subnets, regional MIGs) or multi-regional (some Cloud Storage buckets, Spanner configs), and the scope decides what a single-zone outage takes with it.
Cloud Asset Inventory keeps a searchable, time-travelling record of resources and their IAM policies across an organisation, which is how you answer "what do we actually have and who can reach it". Gemini Cloud Assist can query the same inventory conversationally when you do not know the exact filter syntax.
Two federation features have confusingly similar names. Workforce Identity Federation lets human users from an external IdP such as Okta or Entra ID sign in to Google Cloud without Cloud Identity accounts; Workload Identity Federation lets external workloads (a GitHub Action, an AWS role) get Google credentials without a downloaded service-account key.
Enforce account security across the organisation by turning on 2-Step Verification in the Cloud Identity or Google Workspace Admin console, and provision Google Cloud Observability early so monitoring, logging and error reporting exist before the first workload does rather than after the first incident.

Domain 2: Planning and Implementing a Cloud Solution

Key concepts you must know · 335 practice questions

Match the compute product to the workload: Compute Engine for full VM control, GKE for container orchestration, Cloud Run for stateless containers that scale to zero, Cloud Run functions for event-driven code, and Agent Runtime on Gemini Enterprise Agent Platform (formerly Vertex AI Agent Engine) for hosting agents. The exam asks which fits, not which you personally prefer.
GKE Autopilot manages nodes, scaling and patching for you and bills per running Pod; GKE Standard gives you node pools, which is what you need for custom machine types, attached accelerators or particular node configuration. Autopilot is the default answer when the scenario stresses low operational overhead.
Launch a VM with "gcloud compute instances create", where the flags that matter most are the machine type, boot disk image and size, the availability policy (whether the instance is preemptible or migrates on host maintenance), and how SSH keys reach it - project-wide metadata, instance metadata, or OS Login.
Build reusable instance templates and back a managed instance group with one. A regional MIG spreads instances across zones, autohealing recreates an instance whose health check fails, and the autoscaler adds and removes VMs on a signal such as CPU or a load-balancer serving capacity.
Choose Compute Engine storage by durability scope and performance: zonal Persistent Disk lives in one zone, regional Persistent Disk synchronously replicates across two zones so a volume survives a zone outage, and Hyperdisk decouples provisioned IOPS and throughput from disk size for workloads that need tuned performance.
Spot VMs (the successor to preemptible VMs) are deeply discounted but can be reclaimed at any time with a 30-second warning, so they suit fault-tolerant, checkpointable batch work and never stateful services. Custom machine types let you pick vCPU and memory independently when no predefined type fits.
Committed Use Discounts give a 1- or 3-year discount for capacity you know you will run continuously, so they cover the steady baseline while on-demand or autoscaling absorbs the burst. Sustained Use Discounts apply automatically to long-running Compute Engine usage with nothing to purchase.
OS Login ties Linux SSH access to IAM identities instead of metadata-based SSH keys, so access is granted with roles/compute.osLogin (or osAdminLogin) and revoked by removing the role. It is the answer whenever a scenario asks for centralised, auditable SSH access control across a fleet.
VM Manager provides OS inventory, patch management and configuration for Compute Engine fleets. It requires the OS Config agent on each VM and the API enabled on the project - the prerequisite is the part the exam tests.
Install kubectl (gcloud components install kubectl) and then fetch cluster credentials with "gcloud container clusters get-credentials <cluster> --region <region>". Without that step kubectl reports that no current context exists, which is the single most common GKE troubleshooting question.
Deploy GKE clusters in the configuration the scenario demands: Autopilot for a fully managed node layer, a regional cluster to spread the control plane and nodes across zones, and a private cluster whose nodes have no external IPs (reaching the internet through Cloud NAT and the control plane through an authorised network or Private Service Connect).
Expose a containerised application on GKE with the right Service type: ClusterIP is internal only, NodePort opens a port on every node, LoadBalancer provisions an external or internal load balancer, and Ingress gives Layer 7 HTTP(S) routing with a single external address and TLS termination.
Set resource requests and limits so the scheduler and cluster autoscaler can place Pods, and use readiness probes so traffic reaches only healthy Pods and liveness probes so hung containers restart. In Autopilot the Pod resource requests are what you are billed on.
Deploy serverless workloads with "gcloud run deploy", controlling reachability with the ingress setting (all, internal, or internal plus load balancer) and configuration with environment variables or mounted secrets. Event-driven processing arrives through Pub/Sub messages, Cloud Storage object notifications, or Eventarc for Cloud Audit Log events.
Cloud Run and Cloud Run functions reach private VPC resources - a Cloud SQL private IP, an internal service - through Serverless VPC Access (Direct VPC egress or a connector). Without it a serverless service can only reach public endpoints.
Store and serve container images from Artifact Registry, the successor to Container Registry: create a Docker-format repository in a region, authenticate Docker to it, then push. GKE and Cloud Run pull from it using the workload service account, so that account needs the Artifact Registry Reader role.
Choose GPUs for general-purpose accelerated work - training and inference across many frameworks, plus graphics - and TPUs for large-scale training and inference of models built on frameworks with TPU support, where their throughput per dollar wins. GPUs are the safer answer when the workload or framework is unspecified.
Pick data products by shape: Cloud SQL for managed MySQL, PostgreSQL or SQL Server; AlloyDB for PostgreSQL needing far higher performance; Spanner for globally distributed, strongly consistent relational data; Bigtable for high-throughput wide-column NoSQL; Firestore for documents with real-time sync; BigQuery for serverless analytics; Memorystore for an in-memory cache.
For streaming, the reference pattern is Pub/Sub to ingest, Dataflow to process, and BigQuery to land results, with Google Cloud Managed Service for Apache Kafka when a team already runs Kafka and wants to keep its clients. Use Dataproc when the requirement is existing Spark or Hadoop jobs rather than a new pipeline.
Choose storage products by access pattern and protocol: Cloud Storage for objects, with Standard for hot data and Nearline, Coldline and Archive carrying 30-, 90- and 365-day minimum storage durations; Filestore or Google Cloud NetApp Volumes when a POSIX or NFS file system is needed; Managed Lustre for high-performance parallel workloads.
Load data with the tool matched to size and source: command-line upload with "gcloud storage cp" for local files, "bq load" (which accepts wildcard Cloud Storage URIs) into BigQuery, Storage Transfer Service for online transfers from S3 or another bucket, and Transfer Appliance when petabytes must move without saturating the corporate link.
Plan multi-region redundancy deliberately: multi-region and dual-region Cloud Storage buckets replicate objects across regions, and dual-region with turbo replication targets a 15-minute RPO. Relational tiers get there differently - Cloud SQL cross-region read replicas, or a Spanner multi-region instance configuration.
Create a custom-mode VPC so you define each subnet and its regional CIDR yourself; a VPC is global while subnets are regional. Shared VPC lets a host project share subnets with service projects (grant roles/compute.networkUser on the specific subnet), while VPC Network Peering joins two VPCs with non-overlapping ranges without a gateway.
Firewall rules and Cloud NGFW policies permit or deny by direction, priority, source and destination, protocol and port; the default VPC denies ingress and allows egress, and the lowest priority number wins. Scope rules with secure Tags or with service accounts rather than IP ranges so the rule follows the workload rather than its address.
Establish hybrid connectivity with the option that matches the bandwidth and privacy requirement: Cloud VPN for encrypted tunnels over the public internet (with Cloud Router and BGP for dynamic routes), Dedicated Interconnect for private 10 or 100 Gbps links from a colocation facility, and Partner Interconnect when you cannot reach a colocation facility.
Choose a load balancer by traffic type and scope: the global external Application Load Balancer for HTTP(S) with Layer 7 routing and Cloud CDN, the external passthrough Network Load Balancer for TCP and UDP at very high packet rates, and internal variants of both when only clients inside the VPC should reach the service.
Network Service Tiers decide the path traffic takes. Premium Tier carries traffic on Google’s backbone from the closest point of presence to the user and is required for global load balancing; Standard Tier routes over the public internet from the resource’s own region for less money and less consistency.
Provision infrastructure as code rather than by hand: Terraform with remote state in a versioned Cloud Storage bucket (the GCS backend provides locking), Config Connector to manage Google Cloud resources as Kubernetes objects, Helm to package Kubernetes manifests, and Fabric FAST as an opinionated Terraform foundation for a whole organisation.
Cloud Build automates the build and deploy path: define steps in cloudbuild.yaml and attach a trigger on push to a branch. Its service account needs the deploy permissions on the target, which is why cross-project deployments fail until that account is granted a role in the other project.
AI-assisted tooling is now explicitly in scope: Gemini CLI and Google Antigravity for agent-driven work at the command line, Gemini Cloud Assist for explaining and troubleshooting resources in context, and Application Design Center for laying out and templating an application architecture before it is provisioned.
Cloud SQL high availability uses a synchronous standby in a second zone of the same region with automatic failover; read replicas scale reads and do not provide HA. Enabling HA on an existing instance is an online change, but failover testing should be done deliberately, not in production at peak.
Serve a static site from a Cloud Storage bucket behind a global external Application Load Balancer with Cloud CDN and a Google-managed certificate for HTTPS on a custom domain. The bucket name and the DNS record both matter, and the certificate only provisions once DNS resolves to the load balancer address.
Keep secrets out of code and images: store them in Secret Manager, which versions them and controls access with IAM, and let the runtime service account read the version it needs. Mount them into Cloud Run as a volume or environment variable, or into GKE through the Secret Manager CSI driver.

Domain 3: Ensuring the Successful Operation of a Cloud Solution

Key concepts you must know · 155 practice questions

Connect to a Compute Engine instance with "gcloud compute ssh", and where the VM has no external IP use Identity-Aware Proxy TCP forwarding, which tunnels SSH through Google’s front end and is authorised by IAM. Opening port 22 to 0.0.0.0/0 to solve the same problem is the wrong answer.
Take stock before you change anything: "gcloud compute instances list" for running VMs, and "kubectl get nodes", "kubectl get pods -A" and "kubectl get svc" for GKE cluster inventory. Knowing what exists is the first step of nearly every operational question.
Compute Engine snapshots are incremental and can be taken while an instance runs; images are what you build new instances from. Use a snapshot schedule attached to a disk for automated backups rather than a cron job that calls the API.
Manage GKE node pools independently of the cluster: add a pool with different machine types or Spot nodes, enable cluster autoscaling per pool with minimum and maximum node counts, and use taints with matching tolerations to reserve a pool for particular workloads such as GPU jobs.
Work with the Kubernetes objects the exam names: Deployments for stateless replicas, Services to expose them, and StatefulSets when each replica needs a stable identity and its own persistent volume, which is what a database on GKE requires.
Scale Pods on signals, not by hand: the Horizontal Pod Autoscaler adds replicas on CPU, memory or a custom metric, while the Vertical Pod Autoscaler adjusts the requests of existing Pods. In Autopilot, Pod resource requests are both the scheduling input and the billing basis.
Roll out a new Cloud Run revision and control exposure with traffic splitting - deploy with --no-traffic, then shift a percentage to the new revision for a canary, and roll back by sending 100% to the previous revision. GKE and Cloud Run functions offer the same gradual-shift pattern.
Tune Cloud Run for the workload: raise maximum instances for spikes, set minimum instances to keep warm capacity when cold starts break a latency SLO, adjust per-instance concurrency, and raise the request timeout for long jobs. CPU and memory are per-instance settings, not per-request.
Attach GPUs or TPUs to the workloads that need them - Compute Engine instances, GKE node pools, or Cloud Run - and remember that accelerators are zonal, quota-limited and often the reason a deployment cannot schedule in the region you picked.
Deploy an agent to Agent Runtime on Gemini Enterprise Agent Platform (formerly Vertex AI Agent Engine) when the requirement is a managed home for an agent rather than a container you operate, and manage notebooks in Gemini Enterprise Agent Platform Workbench (formerly Vertex AI Workbench) or directly in BigQuery for analysis work.
Cloud Workstations gives developers managed, preconfigured environments that run inside your VPC with your IAM and firewall rules applied, which is the answer when the requirement is a consistent development environment that never puts source code on a laptop.
Manage Cloud Storage objects with IAM at the bucket level and uniform bucket-level access to switch off per-object ACLs, and automate the rest with Object Lifecycle Management: transition to a colder class after N days, delete after N days, or keep versions bounded. Retention policies and Object Lock prevent early deletion.
Query data where it lives - the bq CLI or console for BigQuery, and the equivalent clients for Cloud SQL, AlloyDB, Spanner, Bigtable and Firestore - and check job status for long-running work in the Dataflow and BigQuery job lists rather than assuming a submitted job succeeded.
Protect databases with automated backups plus point-in-time recovery, which needs transaction or binary logging enabled before the incident, not after. Restoring to a moment just before a destructive statement is what PITR is for; a nightly backup alone loses everything since it.
Database Center gives a single fleet-wide view of Google Cloud databases - inventory, health, and recommendations across Cloud SQL, AlloyDB, Spanner and Bigtable - which is where you look when the question is about the estate rather than one instance.
Configure customer-managed encryption keys in Cloud KMS when you need control over key rotation and lifecycle. CMEK can be set as the default for a Cloud Storage bucket, a BigQuery dataset or a disk; everything is already encrypted at rest with Google-managed keys, so CMEK is about control, not about whether encryption happens.
Estimate costs before provisioning with the Google Cloud Pricing Calculator, and afterwards use billing reports and the BigQuery billing export to see what a workload actually cost. Storage estimates must account for class minimums - deleting a Nearline object before 30 days still bills the full 30.
Adjust networking in place rather than rebuilding: a subnet’s primary IPv4 range can be expanded but never shrunk, static external or internal IP addresses can be reserved so an address survives instance replacement, and custom static routes send specific destinations to a next hop such as a VPN tunnel or an appliance.
Cloud DNS serves authoritative public zones for your domains and private zones that resolve internal names inside chosen VPCs, while Cloud NAT gives instances without external IPs outbound internet access without making them reachable from outside.
Cloud Monitoring holds dashboards and alerting policies over resource metrics, but memory and detailed disk metrics need the Ops Agent installed on the VM. Uptime checks probe public endpoints from several global locations and alert when they fail.
Create log-based metrics from a log filter - counting errors, or extracting a value - and alert on them, delivering through notification channels such as email, SMS, Slack or PagerDuty. Custom application metrics can also be written directly to Cloud Monitoring.
Know the audit log types: Admin Activity logs are always on and free and record configuration changes; Data Access logs record reads and writes of data, are mostly off by default and can be high volume; VPC Flow Logs and firewall logs are enabled per subnet and per rule.
Route logs with sinks: the _Required bucket cannot be excluded or disabled, the _Default bucket can have exclusion filters to cut noise and cost, and additional sinks export to Cloud Storage, BigQuery or Pub/Sub for retention or external analysis. Log Analytics queries log buckets with SQL.
When something is slow rather than broken, reach for the diagnostic tools: Cloud Trace for request latency across services, Cloud Profiler for CPU and heap inside a process, and Query Insights with the index advisor for slow database queries. For a VM that will not boot, read "gcloud compute instances get-serial-port-output".
Google Cloud Managed Service for Prometheus collects Prometheus metrics at scale without you running the servers, and the Personalized Service Health dashboard reports Google-side incidents that affect your specific projects - the place to check before spending an hour debugging your own code.
Use the assistive operations tooling: Active Assist recommenders surface idle VMs, oversized machine types and unused service accounts; Cloud Hub gives a cross-project view of active events and application health; and Gemini Cloud Assist can explain an alert or a metric in place.
Cut cost on workloads that do not run continuously with Compute Engine instance schedules that start and stop VMs on a timetable, and act on rightsizing recommendations rather than leaving oversized instances running because they were provisioned for a launch that is over.
Keep the supply chain checked: Artifact Registry with Artifact Analysis scans images for known vulnerabilities on push, so an operational review can tell whether what is running was ever scanned.

Domain 4: Configuring Access and Security

Key concepts you must know · 128 practice questions

An IAM policy binds members (users, groups, service accounts, domains) to roles on a resource; prefer granting roles to Google Groups, then manage membership in the group, and apply at folder/project level for inheritance.
Role types: basic (Owner/Editor/Viewer - too broad, avoid in production), predefined (service-scoped, recommended), and custom (least-privilege tailored sets). Follow least privilege and use predefined/custom over basic.
Service accounts are both an identity and a resource: attach a custom service account with only the needed roles to a VM and use the metadata server for credentials instead of downloading and storing key files.
IAM Conditions add context to a grant - e.g. an expiry condition gives a contractor access that automatically lapses after 30 days; conditions can also restrict by resource name or request attributes.
Use IAM Recommender to find and remove excess/unused permissions, and disable or delete service accounts unused for 90+ days after confirming they are not needed.
Workload Identity is the recommended way for GKE pods to call Google APIs: bind a Kubernetes service account to a Google service account so pods get credentials without node-stored keys.
A service account is both an identity and a resource, which is why two different permissions matter: roles granted TO the service account decide what it can do, and roles granted ON the service account (such as Service Account User) decide who can act as it or attach it to a resource.
Prefer impersonation to keys. "gcloud --impersonate-service-account" or the Service Account Token Creator role lets a human or workload borrow a service account’s permissions and produce short-lived credentials, leaving nothing durable to leak. Downloaded JSON keys are the option of last resort.
Short-lived credentials - access tokens, ID tokens and signed JWTs minted through the IAM Credentials API - expire in an hour or less, which bounds the damage of a leak and is why they are preferred wherever a long-lived key would otherwise be stored.
Google-managed service accounts (the Compute Engine default, and per-service agents) already exist in a project and carry broad default roles. The default Compute Engine service account in particular should be replaced with a purpose-built account holding only the roles the workload needs.
Assign a service account to a resource at creation - a VM, a Cloud Run service, a Cloud Run function - and let the workload read credentials from the metadata server rather than embedding anything. Changing a VM’s service account requires the instance to be stopped.
Workload Identity Federation lets a workload outside Google Cloud - a GitHub Actions job, an AWS role, an on-premises system with an OIDC provider - exchange its own identity token for Google credentials, removing exported service-account keys from CI/CD entirely.
Secure service-to-service calls with identity rather than network position: require authentication on a Cloud Run service and grant the calling service account the Cloud Run Invoker role, so the caller must present an identity token that Google verifies before the request reaches your code.
Audit access continuously. IAM Recommender flags roles far broader than actual usage, Policy Analyzer answers who can do what on which resource, and service accounts unused for 90 days can be disabled first and deleted later - disabling is reversible, deletion is not.
Grant at the right level of the hierarchy. A role granted on a folder is inherited by every project beneath it and cannot be taken away lower down, so broad grants belong near the leaves and only genuinely universal ones near the root. Deny policies, evaluated before allows, are how you carve out an exception.

Google Cloud Associate Cloud Engineer exam tips

Read for the qualifier words - "most cost-effective", "least privilege", "minimal operational overhead", "fastest", "highest availability". They usually decide between two technically valid answers.
Know the gcloud command structure cold (gcloud <group> <resource> <verb> --flags) and the common ones for compute instances, container clusters, run, IAM, projects and config, and storage. "gcloud container clusters get-credentials" in particular is what makes kubectl work at all.
Two sections carry ~30% each - planning and implementing, and ensuring successful operation - so roughly three fifths of the exam is building things and then running them. Setting up the environment and access and security are ~20% each.
Section 4 is narrower than people expect: the published sub-topics are only managing IAM and managing service accounts. Impersonation, short-lived credentials and Workload Identity Federation matter more than any single product name here.
Default to managed and serverless options (Cloud Run, Cloud Run functions, GKE Autopilot, Cloud SQL, BigQuery) when a scenario stresses low operational burden, and reserve Compute Engine or GKE Standard for requirements that genuinely need node-level control.
Memorise the resource hierarchy and IAM inheritance, the difference between organisation policy constraints and IAM, and the Cloud Storage class minimum durations (Nearline 30 days, Coldline 90, Archive 365).
The current guide names services the older one did not: Hyperdisk, AlloyDB, Managed Service for Apache Kafka, Managed Lustre, NetApp Volumes, Cloud NGFW policies with secure Tags, Fabric FAST and Config Connector, and Agent Runtime on Gemini Enterprise Agent Platform. Recognising what each one is for is enough.
Manage your 120 minutes: flag and skip scenario-heavy questions on the first pass, answer the quick recall items, then come back. Never leave anything blank, since there is no penalty for a wrong answer.

Study guide FAQ

How is the Associate Cloud Engineer exam scored and what is passing?

Google does not publish a fixed passing score; results are reported as pass or fail. The exam is about 50-60 multiple-choice and multiple-select questions in 120 minutes, and there is no penalty for a wrong answer, so answer every question.

How many sections does the current exam guide have?

Four. Google’s current Associate Cloud Engineer exam guide publishes Setting up a cloud solution environment (~20%), Planning and implementing a cloud solution (~30%), Ensuring the successful operation of a cloud solution (~30%), and Configuring access and security (~20%). An earlier revision split planning from deploying across five sections; those two are now a single section, so study material still showing five sections is out of date.

How much hands-on experience do I need before attempting it?

Google publishes both halves of the answer on the certification page: "Prerequisites: None", so nothing gates you from booking, and "Recommended experience: 6+ months hands on experience with Google Cloud", so the six months is Google's own figure rather than our estimate. Google also describes the candidate as having experience working with public clouds or on-premises solutions and being able to perform common platform-based tasks, supported by AI tooling, to maintain and scale one or more deployed solutions. The exam is practical, so time in the gcloud CLI and the Console beats reading.

Should I focus on the gcloud CLI or the Cloud Console?

Both, but the gcloud CLI is heavily tested - you must recognise correct command syntax, flags and configuration switching. Console-based steps (billing, budgets, IAM grants, monitoring setup) still appear, and a few objectives are console-first, such as Database Center and the Personalized Service Health dashboard.

What topics carry the most weight on the exam?

Planning and implementing a cloud solution and ensuring its successful operation are ~30% each, so together they are about 60% of the exam. Across every section, IAM and service accounts, the resource hierarchy, VPC and firewall behaviour, and the compute and storage product choices come back repeatedly.

Official exam sources

The domain names and weightings on this page follow the published exam blueprint. Each source below records what it confirmed and when it was read, so the split can be checked rather than taken on trust.

Google Cloud - Associate Cloud Engineer exam guide (web)link and content verified 8 September 2026Five sections: Setting up a cloud solution environment ~20%, Planning and configuring ~17.5%, Deploying and implementing ~25%, Ensuring successful operation ~20%, Configuring access and security ~17.5%.
Google - Associate Cloud Engineer certification exam guide (PDF)link and content verified 8 September 2026Four sections, read off the rendered PAGES and not only out of an extraction: "Section 1: Setting up a cloud solution environment (~20% of the exam)", "Section 2: Planning and implementing a cloud solution (~30% of the exam)", "Section 3: Ensuring the successful operation of a cloud solution (~30% of the exam)", "Section 4: Configuring access and security (~20% of the exam)". They total 100% and the document ends at Section 4 on page 5, so there is no fifth section anywhere in it. CertGrid practice exams use the same 20/30/30/20 weighting. The audience paragraph is also word-for-word what Google's certification landing page shows today, including "supported by AI tooling". METHOD, because the previous record was wrong about this: the file DOES carry a text layer - 9,681 characters extract cleanly - and all five pages were additionally rasterised and read as images, with the section headings and their percentages checked against the images rather than trusted from the extraction. pdftoppm is not installed here, so the pages were rendered with pdf.js inside headless Chrome and screenshotted over the DevTools protocol. An image-only PDF would not have been unverifiable either; it would just have needed the same visual read without the text layer to cross-check against. Still true from the earlier record: the PDF carries no version number and no revision date, on any of its five pages.

These sources disagree. Both of these Google sources are live today and they genuinely disagree, so which one this page follows is stated rather than left implicit. The exam guide PDF gives FOUR sections at 20/30/30/20. The HTML guide page at cloud.google.com/learn/certification/guides/cloud-engineer gives FIVE at 20/17.5/25/20/17.5, splitting planning from deploying and shading the other three differently. What settles it is the product vocabulary inside each. The HTML page's guide body names "Cloud Functions" three times and "Anthos" once - a product Google renamed to Cloud Run functions and one it folded into GKE Enterprise - and contains NONE of the products the PDF names. The PDF names Cloud Run functions, Gemini Cloud Assist, Gemini Enterprise Agent Platform (which it labels "formerly Vertex AI Agent Engine"), Google Antigravity, Cloud NGFW, Database Center, Cloud Hub, Google Cloud Managed Lustre and Workforce Identity Federation, and names neither Cloud Functions nor Anthos anywhere. A document cannot be the current one while describing the previous generation of a vendor's own product names. So the HTML guide page is a stale copy, the PDF is current, and the four-section 20/30/30/20 split is the live blueprint - which is what this page and our practice mocks already follow. That conclusion rests on retired product names rather than on which document looks newer, so anyone can check it for themselves. Worth knowing separately: Google now publishes a shorter renewal exam (1 hour, 20 questions, $75) beside the standard one this page describes (2 hours, 50-60 questions, $125). The figures here are the standard exam, which is the right one for a first-time candidate; a renewing candidate should check Google's renewal page instead.

Related Google resources

Test yourself: 766 Google Cloud Associate Cloud Engineer practice questions