Domain 3 — Ensuring the Successful Operation of a Cloud Solution

4.21 Compute Engine operations

Know how to:

• View running instances.
• Connect remotely using an approved method.
• Use OS Login-backed SSH where appropriate.
• Create, view, delete, and schedule snapshots.
• Create reusable VM images.
• Attach supported GPUs or TPUs after validating compatibility and availability.

Snapshot versus image

4.22 GKE operations

Know how to:

• Inspect nodes, Pods, Services, and workload events.
• Configure access to private Artifact Registry images.
• Add, edit, remove, and autoscale node pools.
• Work with Pods, Services, Deployments, and StatefulSets.
• Manage Pod resource requests in Autopilot.

Autoscaling comparison:

4.23 Cloud Run operations

Cloud Run releases create revisions. Use revisions to:

• Deploy a new version.
• Roll back if needed.
• Split traffic between revisions.
• Limit maximum instances to protect a downstream dependency.
• Perform canary-style rollouts.

Trap: Changing a DNS record is not the same as configuring revision-level traffic splitting.

4.24 AI agent and developer environment operations

The updated blueprint includes:

• Deploying an agent to Agent Runtime on Gemini Enterprise Agent Platform.
• Managing notebooks in Gemini Enterprise Agent Platform Workbench and BigQuery.
• Managing developer environments such as Cloud Workstations.

Recognize the terminology transition from former Vertex AI product names.

4.25 Cloud Storage operations

Know how to:

• Grant bucket-level or object-level access appropriately.
• Use IAM rather than making objects public unless public access is truly required.
• Configure Object Lifecycle Management.
• Estimate cost based on storage class, retention, retrieval, and operations.

Example lifecycle pattern:

New object
→ Standard storage
→ Transition to colder class after age threshold
→ Delete after retention requirement

4.26 Database operations

Know how to:

• Execute targeted queries against the correct database instance.
• Configure backups.
• Test restoration.
• Review job status for BigQuery and Dataflow.
• Use Database Center to manage database-fleet visibility.
• Configure CMEK when the customer must control the encryption-key lifecycle.

Trap: High availability does not eliminate the need for backup and restore testing.

4.27 Network operations

4.28 Monitoring, logging, and diagnostics

Monitoring

Use Cloud Monitoring to:

• Create alerts based on metrics and thresholds.
• Ingest custom metrics from applications or logs.
• Use Gemini Cloud Assist for Cloud Monitoring where appropriate.
• Review Active Assist recommendations before applying changes.
• Use Cloud Hub for operational context, active events, and application-health data.

Logging

Use Cloud Logging to:

• Filter entries by service, severity, time, resource, and other fields.
• Inspect detailed log messages.
• Route selected logs through log router sinks.
• Export logs to BigQuery or external systems.
• Configure log buckets and retention.
• Use Log Analytics for analytics-capable log queries.
• Review audit logs, VPC Flow Logs, and firewall logs for investigations.

Diagnostics

VM telemetry

Use Ops Agent to collect supported VM logs and metrics.

Prometheus metrics

Use Google Cloud Managed Service for Prometheus for Prometheus-compatible managed monitoring.

Domain 4 — Configuring Access and Security

4.29 IAM inheritance

IAM allow policies inherit down the hierarchy.

Organization role
→ inherited by folders
→ inherited by projects
→ inherited by eligible child resources

If a user has unexpected access, check:

1. Direct resource policy.
2. Project IAM.
3. Parent folder IAM.
4. Organization IAM.
5. Group membership.
6. Service-account impersonation pathways.

4.30 Role types

Trap: Owner and Editor are usually too broad for workload-specific requirements.

4.31 Service accounts

A service account is a workload identity.

Best-practice pattern:

1. Create a dedicated service account.
2. Grant only the required permissions.
3. Attach it to the runtime.
4. Avoid unnecessary long-lived key files.
5. Use impersonation or another short-lived credential flow when appropriate.

4.32 Attached service account versus key file

4.33 Workforce versus workload federation

Fast memory rule:
Workforce = people. Workload = machines. GKE workload identity = Pods.

4.34 Google-managed service accounts

Some managed services use Google-managed service accounts. Do not delete or over-grant them blindly. Preserve only the permissions required for the service to operate.

5. Service Selection Guide

Compute decision tree

Need direct OS control?
├── Yes → Compute Engine
└── No
    Need Kubernetes APIs or orchestration?
    ├── Yes → GKE
    │   ├── Minimize node operations → Autopilot
    │   └── Need direct node-pool control → Standard
    └── No
        Stateless container or HTTP service?
        ├── Yes → Cloud Run
        └── Event-driven function?
            ├── Yes → Cloud Run functions + Eventarc-supported event source
            └── Managed AI agent? → Agent Runtime on Gemini Enterprise Agent Platform

Database decision tree

Analytics warehouse?
├── Yes → BigQuery
└── No
    Cache?
    ├── Yes → Memorystore
    └── No
        Document database?
        ├── Yes → Firestore
        └── No
            Wide-column, time-series, very high throughput?
            ├── Yes → Bigtable
            └── No
                Relational database?
                ├── Conventional managed relational workload → Cloud SQL
                ├── Demanding PostgreSQL-compatible workload → AlloyDB
                └── Global horizontal relational scale + strong consistency → Spanner

Messaging and pipeline decision tree

Need asynchronous message delivery and decoupling?
├── Yes → Pub/Sub
└── No
    Need Kafka-compatible broker semantics?
    ├── Yes → Managed Service for Apache Kafka
    └── No
        Need batch or streaming transformations?
        └── Yes → Dataflow

Storage decision tree

Object storage?
├── Yes → Cloud Storage
└── No
    VM block storage?
    ├── Yes → Persistent Disk or Hyperdisk
    └── No
        Shared file access?
        ├── General managed NFS-style access → Filestore
        ├── Enterprise NFS or SMB requirements → Google Cloud NetApp Volumes
        └── Parallel POSIX throughput for AI or HPC → Google Cloud Managed Lustre

Connectivity decision tree

Need on-premises connectivity?
├── Encrypted over public internet → Cloud VPN
└── Private high-throughput connection → Cloud Interconnect

Need connectivity between VPC networks?
├── Central network ownership and shared subnets → Shared VPC
└── Separately administered VPCs connected privately → VPC Network Peering

Need outbound internet from private resources?
└── Cloud NAT

Need inbound traffic distribution?
└── Load balancer

Identity decision tree

Human users from external IdP?
└── Workforce Identity Federation

External machine workload?
└── Workload Identity Federation

GKE Pod calling Google Cloud API?
└── Workload Identity Federation for GKE

Google Cloud workload with attached identity support?
└── Attach a dedicated service account

Human temporarily acting as service account?
└── Service-account impersonation

6. Architecture Patterns

Pattern 1: Governed department projects

Organization
└── Finance folder
    ├── finance-prod
    └── finance-dev

Use:

• Folder-level IAM when finance teams need shared access.
• Folder-level organization policies when finance projects need shared restrictions.
• Separate billing account only when payment responsibility must differ.

Pattern 2: Central networking with application autonomy

Shared VPC host project
├── centrally managed subnets
└── firewall governance

Service projects
├── application project A
└── application project B

Use Shared VPC when network administrators must own subnets while application teams deploy resources into service projects.

Pattern 3: Stateless web API with minimal operations

Client
→ Load balancer or managed endpoint as required
→ Cloud Run service
→ Managed database or backend

Use Cloud Run when the application is stateless and the team wants minimal infrastructure management. Configure revision traffic splitting for a gradual rollout and maximum instances to protect downstream dependencies.

Pattern 4: Kubernetes platform

Artifact Registry
→ GKE cluster
   ├── Deployment
   ├── Service
   ├── node pools
   └── autoscaling

Use:

• Regional GKE cluster for greater control-plane resilience.
• Private cluster when nodes should avoid public IPs.
• Workload Identity Federation for GKE for keyless API access from Pods.
• Node-pool autoscaling, HPA, and VPA for the correct scaling layers.

Pattern 5: Private VM outbound internet access

Private VM without external IP
→ Cloud NAT
→ Internet

Use Cloud NAT for outbound access without exposing the VM directly to inbound internet traffic.

Pattern 6: Event-driven processing

Cloud Storage object event or Pub/Sub message
→ Eventarc-supported event flow
→ Cloud Run function

Use this instead of a polling VM when minimal operations and event-driven execution are required.

Pattern 7: External CI/CD without key files

External CI/CD identity
→ Workload Identity Federation
→ short-lived Google Cloud credentials
→ deployment action

Avoid downloading a long-lived service-account JSON key.

Pattern 8: Human partner access through external identity provider

Partner employee
→ external identity provider
→ Workforce Identity Federation
→ authorized Google Cloud resources

Do not use workload federation for a human-browser-access scenario.

Pattern 9: Operational observability

Application and infrastructure signals
├── Cloud Monitoring metrics and alerts
├── Cloud Logging filters, buckets, and sinks
├── Ops Agent for VM telemetry
├── Managed Service for Prometheus
├── Cloud Trace / Cloud Profiler
├── Query Insights / index advisor
├── Personalized Service Health
└── Cloud Hub

Pattern 10: Cost-aware object retention

Cloud Storage bucket
→ object lifecycle rule
→ transition to colder storage class
→ delete after retention requirement

Choose storage class based on expected access, retrieval, and retention patterns.

7. Exam Traps

7.1 Choosing a related service from the wrong category

Examples:

• Cloud NAT is not an inbound load balancer.
• Cloud DNS is not an authentication or routing engine for application traffic.
• BigQuery is not the default OLTP database.
• Cloud SQL is not a global horizontally scalable relational database.
• A billing alert is not a runtime scaler.
• Monitoring alerts detect conditions; they do not implement configuration changes.

7.2 Selecting a technically possible but operationally heavier option

If Cloud Run directly meets the requirement, a manually managed VM is usually inferior when the scenario emphasizes minimal operations.

If GKE Autopilot meets the requirement, GKE Standard is usually inferior when the scenario emphasizes minimizing node management.

7.3 Excessive IAM scope

Watch for:

• Organization Owner for a project-level task.
• Project Editor for bucket read-only access.
• Shared private keys for a changing workforce.
• Broad service-account permissions when one narrowly scoped role is enough.

7.4 Confusing organization policy with IAM

• IAM grants permissions.
• Organization policy restricts allowed configurations.
• Firewall rules control traffic.
• Billing accounts control payment linkage.

7.5 Confusing identities

• Workforce Identity Federation → humans.
• Workload Identity Federation → external machine workloads.
• Workload Identity Federation for GKE → Pods.
• Service-account impersonation → controlled short-lived use of a service account.
• Attached service account → preferred for supported Google Cloud runtimes.

7.6 Confusing network designs

7.7 Confusing storage types

• Cloud Storage is object storage.
• Persistent Disk and Hyperdisk are VM block storage.
• Filestore and NetApp Volumes are shared file services.
• Managed Lustre is a parallel POSIX file service for demanding workloads.
• Local SSD is ephemeral.

7.8 Confusing scaling layers

• Managed instance-group autoscaling → VM count.
• Node-pool autoscaling → GKE worker-node count.
• HPA → Pod replica count.
• VPA → per-Pod CPU and memory requests.
• Cloud Run autoscaling → Cloud Run instance count.

7.9 Confusing backup with availability

High availability is not a replacement for backup. A restore path should be tested.

7.10 Ignoring scope words

Pay attention to words such as:

• Organization-wide.
• Department-only.
• One project.
• One bucket.
• One subnet.
• One service account.
• Private resources.
• Public endpoint.
• Multi-region.
• Cross-zone.

The scope words often eliminate half the options immediately.

7.11 Ignoring the requested operational stage

The same product can appear in different questions, but the required action changes:

7.12 Assuming every recommendation should be applied automatically

Active Assist and index-advisor recommendations must be reviewed in workload context. A recommendation is input to an engineering decision, not an automatic command.

8. Quick Memory Rules

Governance

• Organization = company.
• Folder = department or policy boundary.
• Project = workload and billing-linkage boundary.
• Organization policy restricts configurations.
• IAM grants permissions.
• Budget alerts notify; they do not normally stop spend automatically.
• Billing export → BigQuery for analysis.

Compute

• OS control → Compute Engine.
• Kubernetes → GKE.
• Serverless stateless container → Cloud Run.
• Event-driven function → Cloud Run functions plus event source.
• Identical scalable VMs → instance template plus managed instance group.
• Restart-tolerant batch → Spot VM.
• IAM-backed SSH → OS Login.

GKE

• Minimize node operations → Autopilot.
• Need node-pool control → Standard.
• Cross-zone control-plane resilience → regional cluster.
• Avoid public node IPs → private cluster.
• Replica count → HPA.
• Pod requests → VPA.
• Node count → node-pool autoscaling.
• Stable stateful Pods → StatefulSet.

Data and storage

• Analytics → BigQuery.
• Traditional relational OLTP → Cloud SQL.
• Demanding PostgreSQL-compatible OLTP → AlloyDB.
• Global scalable relational consistency → Spanner.
• Document database → Firestore.
• Wide-column and time series → Bigtable.
• Cache → Memorystore.
• Messages → Pub/Sub.
• Transformations → Dataflow.
• Kafka compatibility → Managed Service for Apache Kafka.
• Object → Cloud Storage.
• VM block → Persistent Disk or Hyperdisk.
• Shared NFS-style file → Filestore.
• Enterprise NFS or SMB → NetApp Volumes.
• Parallel AI/HPC file system → Managed Lustre.

Networking

• Explicit CIDRs → custom mode VPC.
• Central network team and shared subnets → Shared VPC.
• Separate VPC administrations with private connectivity → VPC Network Peering.
• Encrypted public-internet hybrid path → Cloud VPN.
• Private high-throughput hybrid path → Cloud Interconnect.
• Private VM outbound internet → Cloud NAT.
• Inbound distribution → load balancer.
• DNS records → Cloud DNS.

Identity and security

• People → Workforce Identity Federation.
• External machines → Workload Identity Federation.
• Pods → Workload Identity Federation for GKE.
• Temporary act-as access → service-account impersonation.
• Supported Google Cloud runtime → attach service account, avoid key file.
• Least privilege → narrowest suitable role and scope.
• Customer controls encryption-key lifecycle → CMEK.

Operations

• Disk backup → snapshot.
• Reusable VM baseline → image.
• Slow request path → Cloud Trace.
• Code profiling → Cloud Profiler.
• Slow SQL → Query Insights.
• Index suggestions → index advisor.
• Google Cloud incident relevance → Personalized Service Health.
• VM logs and metrics → Ops Agent.
• Prometheus-compatible managed monitoring → Managed Service for Prometheus.
• Operational overview → Cloud Hub.

9. Final Revision Notes

One-page revision sequence

Review these topics in this order during the final days:

1. Compute selection: Compute Engine, GKE, Cloud Run, functions, and Agent Runtime.
2. Database and storage selection.
3. Shared VPC versus VPC Network Peering versus Cloud VPN versus Cloud Interconnect.
4. Cloud NAT versus load balancing versus Cloud DNS.
5. IAM hierarchy and least privilege.
6. Service-account attachment, impersonation, and federation.
7. GKE scaling layers.
8. Cloud Run revisions, traffic splitting, and autoscaling.
9. Snapshots, images, backups, restore testing, and CMEK.
10. Monitoring, logging, Query Insights, index advisor, Personalized Service Health, Ops Agent, Prometheus, Active Assist, and Cloud Hub.

Top confusing pairs

Option-elimination checklist

When two options look plausible:

1. Remove the option that grants more privilege than necessary.
2. Remove the option that operates at the wrong hierarchy scope.
3. Remove the option that solves monitoring when the question asks for configuration.
4. Remove the option that solves payment or billing when the question asks for capacity or runtime behavior.
5. Remove the option that uses a public endpoint when the scenario asks for private access.
6. Remove the option that introduces manual infrastructure when a managed service directly meets the requirement.
7. Remove the option designed for humans when the caller is a machine.
8. Remove the option designed for machine workloads when the caller is a person.
9. Prefer the answer that directly maps to the stated interface: object, block, file, database, message, pipeline, DNS, NAT, VPN, or load balancing.
10. Verify that the answer matches the requested operational stage: choose, deploy, scale, monitor, troubleshoot, or optimize.

Updated terminology to recognize

The updated blueprint includes terminology tied to Gemini Enterprise Agent Platform. Be ready to recognize:

• Agent Runtime on Gemini Enterprise Agent Platform, formerly Vertex AI Agent Engine.
• Gemini Enterprise Agent Platform Workbench, formerly Vertex AI Workbench.
• Gemini Cloud Assist for resource analysis and Cloud Monitoring support.
• AI-assisted planning and implementation tooling such as Gemini CLI, Google Antigravity, Gemini Cloud Assist, and Application Design Center.

10. Exam-Day Checklist

Before starting:

• Confirm whether your exam date uses the current or the June 30 updated English blueprint.
• Read each scenario for scope, workload type, security constraint, and operational goal.
• Identify whether the question expects one answer or multiple answers.
• Mark questions that require extra review and return to them later.
• Avoid spending too long on one service-name detail.

For every question:

• Ask: “What is the simplest managed solution that directly meets the requirement?”
• Check whether the option uses the correct hierarchy scope.
• Reject broad Owner or Editor access unless the scenario genuinely requires it.
• Reject long-lived keys when attached identities, impersonation, or federation are supported.
• Distinguish people from workloads.
• Distinguish inbound traffic from outbound connectivity.
• Distinguish object, block, and file storage.
• Distinguish analytics from transactional databases.
• Distinguish scaling signals from scaling layers.
• Distinguish detection tools from configuration tools.

Final confidence check:

• I can choose Compute Engine, GKE, Cloud Run, functions, and Agent Runtime correctly.
• I can choose relational, document, wide-column, analytical, cache, messaging, and pipeline services correctly.
• I can choose object, block, shared file, enterprise file, and parallel file storage correctly.
• I understand Shared VPC, peering, VPN, Interconnect, load balancing, NAT, DNS, and firewall decisions.
• I understand IAM inheritance, role scope, service accounts, impersonation, and federation.
• I can operate snapshots, images, autoscaling, traffic splitting, backups, CMEK, monitoring, logging, and diagnostics.
• I can eliminate distractors that solve the wrong problem category.

Official Alignment References

• Google Cloud Associate Cloud Engineer certification page: https://cloud.google.com/learn/certification/cloud-engineer
• Updated English standard exam guide scheduled for June 30: https://services.google.com/fh/files/misc/063026_associate_cloud_engineer_exam_guide_english.pdf