Domain 1: Bootstrapping and Maintaining a Google Cloud Organization
- Design the resource hierarchy before anything is built: an organization node, folders that reflect how the business is actually structured, and a project per application per environment. An application-centric layout keeps a team's blast radius and its IAM grants in the same place.
- The recommended environment topology is a separate GCP project per environment (dev/staging/prod) under a folder hierarchy, governed centrally by organization policies.
- Share networking centrally rather than per team: Shared VPC lets a host project own subnets that service projects attach workloads to, VPC Network Peering joins two VPCs with non-overlapping ranges, and Private Service Connect exposes a service through a private endpoint in the consumer's own VPC without peering the whole network.
- Aggregate monitoring and logging across projects instead of visiting each one: a metrics scope lets one scoping project chart metrics from many, and an organization or folder log sink routes every child project's logs to one bucket, BigQuery dataset or Pub/Sub topic.
- Govern with organization policy constraints as well as IAM. IAM decides who may act; org policy constrains what may exist at all - restricting resource locations, blocking external IPs, or requiring shielded VMs - and it is inherited down the hierarchy.
- Create purpose-built service accounts per workload and manage their lifecycle: grant them only the roles the workload needs, prefer impersonation and short-lived credentials over downloaded keys, and disable accounts that go unused before deleting them.
- Data residency is a design constraint, not a setting applied later. Use the resource locations org policy constraint to keep resources inside permitted regions, and remember that logs, backups and multi-region buckets can quietly move data outside the boundary the policy was meant to protect.
- Infrastructure as Code with Terraform or Google's Infrastructure Manager (managed Terraform) manages GCP resources declaratively, enabling peer-reviewed, reproducible, versioned environment changes.
- Pick the infrastructure-as-code tooling the guide names and know what each is for: Infrastructure Manager is managed Terraform, the Cloud Foundation Toolkit provides Google-maintained blueprint modules, Config Connector manages Google Cloud resources as Kubernetes objects, Helm packages Kubernetes manifests, and GitOps makes the repository the source of truth that a controller reconciles.
- Make infrastructure changes through the pipeline, not the console: plan, review and apply from version control so every change is auditable and reversible. Detect drift with a scheduled plan and treat a non-empty diff as an incident in its own right.
- Automate the parts Terraform is wrong for with scripting in Python or Go against the client libraries - bulk one-off migrations, custom reporting, glue between systems - and keep those scripts in the same repository under the same review as everything else.
- Design the CI/CD stack deliberately: Cloud Build for continuous integration, Cloud Deploy for continuous delivery with Skaffold rendering and Kustomize overlays per target, and Artifact Registry as the one place built artifacts live. Third-party tooling - Git, Jenkins, Argo CD, Packer, kpt - is explicitly in scope alongside them.
- Secure the CI/CD tooling itself, because it is the most privileged system you own. Scope the build service account per environment, keep production deploy permissions out of the build that runs pull-request code, and audit who can edit a trigger as tightly as who can deploy.
- Manage environments as a set rather than as snowflakes: separate projects for staging and production, ephemeral preview environments created and destroyed per change, and configuration and policy held as code so an environment can be rebuilt from the repository.
- Manage GKE across an enterprise with fleets: a fleet groups clusters so team membership, policy and service mesh configuration apply once across all of them rather than cluster by cluster, with namespace sameness across the fleet.
- Patch and upgrade safely by using release channels for predictable GKE versions, upgrading a canary cluster or node pool before the fleet, setting maintenance windows and exclusions around business-critical periods, and using surge upgrades so capacity is added before nodes drain.
- Cloud Workstations provides managed, container-based, reproducible and isolated development environments defined by a workstation configuration, suitable for teams needing consistent IDE setups.
- Cloud Shell is a free, browser-based, on-demand VM with the Cloud SDK (gcloud, kubectl, etc.) preinstalled; only the 5 GB $HOME directory persists and the VM terminates after about 20 minutes of inactivity.
- Bootstrap development environments with the tooling already present - custom images, a preset IDE configuration, the Cloud SDK - so a new engineer does not spend a day installing things and every environment is identical.
- gcloud config set project PROJECT_ID sets the active project; gcloud config set compute/region us-central1 sets the default compute region for the active configuration.
- gcloud auth login performs an interactive browser OAuth flow for the CLI, while gcloud auth application-default login sets up Application Default Credentials (ADC) for local application code.
- Named CLI configurations are managed with gcloud config configurations create and gcloud config configurations list, letting you switch between project/account/region profiles.
- gcloud services enable run.googleapis.com enables an API (here the Cloud Run Admin API) before the corresponding service can be used.
- Keyless authentication is preferred: use Workload Identity Federation for CI/CD systems and Application Default Credentials for local development instead of long-lived service account key files.
- Grant elevated roles using IAM Conditions for time-bounded access or just-in-time elevation rather than permanent broad grants, following least privilege.
- Leverage the AI assistance the guide now names: Gemini Code Assist inside the IDE for writing and explaining code, Gemini Cloud Assist for investigating resources, logs and alerts in context, and Gemini CLI for agent-driven work at the terminal.
Domain 2: Building and Implementing CI/CD Pipelines
- Cloud Build is Google Cloud's fully managed CI/CD platform; it executes ordered steps defined under the steps: field in cloudbuild.yaml, runs tests, builds Docker images, and can trigger deployments via Cloud Deploy.
- A Cloud Build trigger connected to a repository (e.g., GitHub, Cloud Source Repositories) automatically starts builds on Git push or pull request events.
- Design the pipeline around triggers and gates: a trigger on push to a branch, on a tag, or on a pull request; automated tests that block promotion; and an approval flow in Cloud Deploy for the step into production, so a human decision is recorded rather than assumed.
- Artifact Registry is the recommended managed registry for container images and language packages (Maven, npm, Python); it supports per-repository IAM and automated vulnerability scanning, superseding the deprecated Container Registry.
- gcloud builds submit --tag builds an image and pushes it to Artifact Registry; gcloud artifacts repositories create --repository-format=docker creates a Docker repo; gcloud auth configure-docker configures Docker auth to Artifact Registry.
- Optimize build speed and cost with build caching (reuse unchanged steps and cache layers via Kaniko or the Cloud Build cache), and parallelize independent steps while staging tests by speed.
- Configure Artifact Registry cleanup policies to automatically delete or keep-most-recent stale image versions, controlling storage cost and clutter.
- Continuous testing is part of the pipeline, not a separate phase: unit and integration tests on every build, contract tests before promotion, and smoke tests against the deployed target. For machine learning workloads the same shape applies to data validation and model evaluation before a model is promoted.
- Cloud Deploy is the managed continuous delivery service that orchestrates progressive promotion through targets (dev to staging to prod) with approvals and built-in rollback.
- Deploy to hybrid and multi-cloud targets from one pipeline - GKE clusters wherever they run, plus Cloud Run - by keeping the rendered manifests and the deploy step uniform and letting the target definition carry the differences.
- A canary deployment routes a small slice (typically 1-5%) of real traffic to the new version to observe error rate, latency, and business metrics before a full rollout.
- A blue/green deployment keeps two identical environments and switches all traffic at once, enabling near-instant rollback by flipping back to the previous environment.
- Rolling updates replace instances or Pods in batches with no second environment, which makes them the cheapest strategy and the slowest to roll back. Traffic splitting shifts a percentage between revisions, and feature flags decouple release from deploy entirely so a feature can be disabled without shipping anything.
- Define success metrics before the rollout, not during it. A canary is only meaningful if you have decided in advance which telemetry - error rate, latency, or an ML pipeline's evaluation metric - decides whether it advances or rolls back.
- Pair automated test gates that block failing builds with progressive delivery (canary or blue/green) and automated rollback to limit blast radius when a defect reaches production.
- Audit and track deployments across the chain: Cloud Build records what was built from which commit, Artifact Registry records the image and its digest, Cloud Deploy records which release reached which target and who approved it, and Cloud Audit Logs record the API calls behind all of it.
- Troubleshoot deployment failures by locating the stage: a build failure is in the Cloud Build log, a rollout that never becomes ready is usually a failing readiness probe or an image the workload identity cannot pull, and a rollout blocked at admission is usually Binary Authorization rejecting an unattested image.
- Manage keys and secrets with the right service for each: Cloud KMS for encryption keys, Secret Manager for versioned application secrets, Certificate Manager for TLS certificates, and Parameter Manager for non-secret configuration that still needs versioning and controlled rollout.
- Know the difference between build-time and runtime secret injection. A secret injected at build time is baked into the artifact and travels wherever the image goes; a secret read at runtime from Secret Manager by the workload's own identity can be rotated without rebuilding and never exists in the registry.
- Application code should use Application Default Credentials via an attached service account or Workload Identity rather than embedding credentials, so secrets never live in the image.
- Use Workload Identity Federation so an external CI system - GitHub Actions, or a build running outside Google Cloud - exchanges its own OIDC token for short-lived Google credentials. That removes the exported service-account key that is otherwise the most valuable secret in the repository.
- Artifact Analysis scans images in Artifact Registry for known vulnerabilities on push and continuously afterwards, so a base image that becomes vulnerable next month is still flagged. Scanning results are what an attestation should be based on.
- Binary Authorization is a deploy-time control for GKE and Cloud Run that blocks images lacking valid cryptographic attestations from trusted authorities, enforcing a trusted supply chain.
- SLSA-aligned build provenance combined with Binary Authorization attestations created during the Cloud Build pipeline proves images passed required checks before deployment.
- Scope IAM by environment: the identity that deploys to staging should not be able to deploy to production, and the build that runs untrusted pull-request code should have almost no permissions at all. Separate service accounts per environment are what make that enforceable.
Domain 3: Applying Site Reliability Engineering Practices
- An SLI is a measured indicator (e.g., the fraction of requests served successfully under 200ms) and an SLO is the target set on that SLI (e.g., 99.9% of requests succeed); the SLI is the measurement and the SLO is the goal.
- An SLA is the contractual promise made to a customer, with consequences attached. Set the internal SLO tighter than the SLA so the error budget is exhausted, and the team alerted, well before a contractual breach.
- The best user-facing SLIs are request success rate and latency as experienced by the user, measured at the serving edge or load balancer, not internal-only signals.
- The recommended availability SLI is the ratio of successful, sufficiently fast (good) requests to total valid requests measured at the serving edge, which reflects real user experience.
- An error budget equals 1 minus the SLO: a 99.9% availability SLO yields a 0.1% error budget, the allowable unreliability the team may 'spend' over a rolling window before slowing risky releases.
- When the error budget is exhausted, the policy is to freeze risky feature releases and redirect engineering effort to reliability work until the budget recovers.
- Surplus error budget can be deliberately spent on calculated risk such as faster rollouts, chaos experiments, or planned maintenance.
- Set the SLO to the lowest level that keeps users happy; each additional 'nine' of reliability dramatically increases cost and effort, and 100% reliability is unrealistic.
- Each additional nine costs disproportionately more to reach and to hold, so reliability targets are an economic decision. Compare the opportunity cost of the engineering effort against what the additional availability is actually worth to users before committing to it.
- Cloud Service Mesh gives a place to define SLOs and measure error budgets from the mesh's own telemetry, so success rate and latency are measured consistently at the proxy rather than reimplemented in each service.
- Toil is work that is manual, repetitive, automatable, tactical, devoid of enduring value, and scales linearly with service growth; SRE teams aim to keep toil below 50% of their time.
- Shared ownership of reliability between developers and SREs aligns incentives so teams build services that are operable, observable, and debuggable, avoiding 'throw it over the wall' handoffs.
- Manage a service across its whole lifecycle, not just its launch: a production readiness review before onboarding, defined ownership and runbooks during operation, and a deliberate retirement plan that includes decommissioning the alerts, dashboards and quota the service used.
- Plan capacity against real limits: quotas are per-project and per-region and need lead time to raise, reservations hold capacity for when you actually need it, and Dynamic Workload Scheduler obtains scarce accelerator capacity for batch and training workloads that can wait for a slot.
- Autoscaling automatically matches capacity to load: GKE Horizontal Pod Autoscaler scales pods on CPU or custom metrics, Cloud Run scales instances on request concurrency, and Managed Instance Groups autoscale Compute Engine VMs.
- The GKE Cluster Autoscaler adds nodes when pods cannot be scheduled and removes underutilized nodes after safely evicting pods, keeping the node pool right-sized.
- Google Kubernetes Engine (GKE) manages containerized workloads with autoscaling, self-healing, and rolling updates; Autopilot mode further offloads node management.
- Improve GKE resilience by spreading pods across zones and nodes with pod anti-affinity in multi-zone clusters, and set resource requests and limits so the scheduler places pods well and prevents noisy neighbors.
- Mitigate an incident by moving users away from the failure before diagnosing it: drain or redirect traffic to a healthy region or backend, fail over, or shed load. Restoring service comes first and the investigation follows.
- Adding capacity is a legitimate mitigation when the cause is saturation - raise autoscaler maximums, lift a quota, add nodes - but confirm the workload is genuinely load-bound first, because scaling a service that is failing on a dependency just multiplies the failing calls.
- Roll back a Cloud Run regression by routing 100% of traffic to a previous known-good revision using gcloud run services update-traffic --to-revisions, since prior revisions are retained.
- Have a rollback strategy chosen before the deploy: which revision or release is the known-good one, how long the rollback takes, and whether a schema or data migration makes it one-way. A strategy that only works if the database is untouched is not a strategy for the release that touches the database.
- During an active incident, restoring service availability takes priority over cost optimization; mitigate first (e.g., roll back, add capacity), then investigate root cause afterward.
- Effective incident response assigns a clear Incident Commander plus defined roles (communications lead, scribe, operations responders) and follows a structured communication plan to avoid chaos.
- Pre-written, validated runbooks for known failure modes reduce mean time to recovery (MTTR) by encoding diagnosis, remediation, rollback, and escalation steps any on-call engineer can follow.
- A blameless postmortem documents the timeline and contributing factors of an incident and produces tracked action items without attributing fault, creating psychological safety so engineers report issues honestly.
- Recurrence is prevented only by completing owned, tracked postmortem action items with due dates; these fix the root cause, add earlier-detection monitoring, and automate remediation.
Domain 4: Implementing Observability Practices and Troubleshooting Issues
- Collect telemetry with agents and standards rather than bespoke code: the Ops Agent gathers system metrics and logs from VMs, OpenTelemetry instruments applications portably for metrics and traces, and Cloud Audit Logs, VPC Flow Logs and Cloud Service Mesh telemetry cover the platform and network layers.
- The three observability pillars are metrics, logs, and traces; metrics show health over time, traces reveal latency across microservice calls, and logs provide detailed event context.
- Optimise logs at ingestion, because that is where the cost is: exclusion filters drop what you will never read, sampling keeps a representative fraction of high-volume events, and choosing the source level (dropping DEBUG in production) beats filtering the same volume later.
- Collect metrics from everywhere the system runs: applications, the platform, networking, Cloud Service Mesh, and Kubernetes through Google Cloud Managed Service for Prometheus, which ingests Prometheus metrics at scale without you operating Prometheus servers - including from hybrid and multi-cloud clusters.
- Synthetic monitors proactively probe endpoints and multi-step workflows from Google's infrastructure on a schedule, so a broken checkout is detected before a user reports it. They complement real-user telemetry rather than replacing it.
- Create custom metrics for what the platform does not expose, and log-based metrics to turn a log pattern into a time series you can chart and alert on - counting occurrences, or extracting a numeric value from a structured field.
- Analyse logs in the Logs Explorer with the Logging query language: filter by resource type and labels, use severity and timestamp bounds to narrow the window, and search structured fields with jsonPayload rather than substring-matching the whole line.
- gcloud logging read with a resource.type filter retrieves logs (e.g., Cloud Run logs); gcloud logging sinks create with a BigQuery destination routes logs to a dataset for analysis or retention.
- Export and retain logs deliberately: route to BigQuery for SQL analysis, to Cloud Storage for cheap long-term retention, and to Pub/Sub to feed an external system. Set bucket retention to match the compliance requirement instead of keeping everything in the default bucket forever.
- Handle sensitive data before it lands: use a log processor or the Cloud Data Loss Prevention integration to redact personally identifiable information and protected health information at ingestion, because a log bucket you have to purge afterwards has already leaked.
- Route compliance and audit logs to a dedicated, access-controlled log sink (e.g., to BigQuery or Cloud Storage) and use exclusion filters to keep noisy non-essential logs out of the _Default bucket.
- Analyse metrics in the Metrics Explorer, then build dashboards worth looking at during an incident: filter and group by the labels that matter, query with PromQL where the data comes from Managed Service for Prometheus, share the dashboard with the on-call rota, and attach playbooks so the responder sees what to do next to the chart that woke them.
- Cloud Monitoring alerting policies trigger notifications through notification channels when metrics such as error rate exceed a threshold; gcloud beta monitoring channels create --channel-content-from-file creates a channel.
- Define alert policies as code using the Terraform google_monitoring_alert_policy resource or gcloud alpha monitoring policies create for repeatable, version-controlled alerting.
- Alert on user-facing SLO and symptom signals (latency, error rate) rather than on every internal cause metric, to reduce alert fatigue and pages that are not actionable.
- Set up layered alerting: SLO and symptom alerts for reliability, resource-utilization alerts for capacity, plus budget and anomaly alerts via Cloud Billing budgets for cost.
- Integrate alerting with wherever the team actually works - webhooks, PagerDuty, Rootly - rather than relying on an inbox. The routing and escalation policy is part of the alert design, not an afterthought.
- Burn-rate alerting fires when the error budget is consumed faster than sustainable; multi-window, multi-burn-rate alerts (a fast-burning short window plus a slower long window) reduce false alarms while catching fast degradation early.
- Capture distributed traces with OpenTelemetry and read the waterfall: each span is one operation, the width is its duration, and the gap between a parent span and its children is time spent somewhere you have not instrumented. That gap is usually where the latency is.
- Correlate traces with logs by emitting the trace ID as a field in structured logs, so a slow trace links directly to the log lines from that exact request. Without that field you are matching on timestamps and guessing.
- Error Reporting automatically captures, deduplicates, and groups application exceptions with stack traces and notifies on new error types.
- Use Gemini Cloud Assist to shorten investigation: summarising a noisy log query, interpreting an unfamiliar metric, or explaining what a trace shows. Treat its output as a lead to confirm against the underlying telemetry, not as the finding itself.
- Troubleshoot by layer, and know which telemetry answers which question: infrastructure issues in platform metrics and audit logs, pipeline issues in build and deploy logs, application issues in application logs, traces and Error Reporting, and latency issues in traces and profiles. An observability gap is itself a finding worth fixing.
Domain 5: Optimizing Performance and Cost
- Monitor application performance continuously rather than only during incidents: latency distributions rather than averages, saturation of the resources the service depends on, and profiles that show where CPU and memory actually go inside the process.
- Active Assist turns telemetry into specific recommendations - idle VMs, oversized machine types, unattached disks, over-granted IAM roles - and it is the fastest route from "we should optimise" to a list of changes someone can actually make.
- Use the Google Cloud recommenders across all five categories the guide names - cost, security, performance, manageability and reliability - and review them on a schedule. A recommendation nobody looks at monthly is not a practice.
- Observability has its own cost, and it grows with traffic. Budget for log ingestion and metric cardinality explicitly: an unbounded label such as a user ID or request ID on a custom metric is the classic way a monitoring bill overtakes the workload it monitors.
- Choose cost-effective compute: Spot (preemptible) VMs fit fault-tolerant restartable batch jobs, while Committed Use Discounts (CUDs) reduce cost for steady, predictable always-on workloads.
- Plan infrastructure cost rather than discovering it: committed use discounts for the steady baseline, sustained use discounts applied automatically, and Network Service Tiers chosen deliberately, since Standard Tier costs less than Premium and gives up the global backbone path that global load balancing requires.
- Cut Cloud Run cost by lowering min-instances toward zero during off-peak hours; cut Cloud Storage cost with Object Lifecycle Management rules that transition data to colder classes or delete it.
- Reduce BigQuery cost and scan volume by selecting only needed columns (avoid SELECT *) and partitioning and clustering tables so queries scan less data.
- Relieve a saturated Cloud SQL primary by adding read replicas for read-only traffic and a caching layer for hot repeated reads; smooth bursty load with a Pub/Sub queue feeding autoscaling Cloud Run workers.
- Memorystore for Redis is a fully managed in-memory cache; caching hot reads with a TTL aligned to data update frequency cuts database load and serves data in microseconds.
- Cloud CDN caches static content at edge points of presence in front of the global HTTP(S) load balancer, reducing user latency and origin load; cache behavior is driven by Cache-Control headers.
- Optimise individual workloads by their own scaling model: for GKE, right-size requests and use the cluster autoscaler with Spot node pools for tolerant work; for Cloud Run, tune concurrency and let minimum instances fall to zero off-peak; for Compute Engine, right-size machine types and stop what does not run overnight.
- Keep cost work honest about reliability. During an active incident, availability wins over cost, and an optimisation that removes the redundancy an SLO depends on has not saved money - it has spent error budget that has not come due yet.
Google Cloud DevOps Engineer exam tips
- Half the exam is CI/CD pipelines and observability - ~25% each. Those two sections together outweigh SRE theory (~18%) and cost optimisation (~12%), so weight your preparation towards Cloud Build, Cloud Deploy, Artifact Registry, Cloud Logging, Cloud Monitoring and Cloud Trace.
- Almost every question is a scenario pitting reliability against velocity. Default to SRE doctrine: error budgets, SLOs built on user-facing SLIs, toil reduction, and blameless postmortems.
- Know the deployment strategies cold - canary, blue/green, rolling, traffic splitting and feature flags - and which Google Cloud service implements each. Cloud Deploy orchestrates promotion through targets with approval gates; Cloud Run splits traffic across revisions natively.
- Memorise the operations suite mapping: Cloud Monitoring for metrics, dashboards and alerts; Cloud Logging for logs and sinks; Cloud Trace for distributed traces; Error Reporting for grouped exceptions; and Managed Service for Prometheus where the metrics are Prometheus-format.
- When a question asks for the most secure or recommended authentication, prefer keyless options: Workload Identity Federation for CI/CD systems and Application Default Credentials with an attached service account for workloads. A downloaded JSON key is rarely the right answer.
- For incident scenarios pick mitigate-then-fix - drain traffic, roll back, add capacity - followed by a blameless postmortem with tracked action items. For alerting scenarios pick multi-window, multi-burn-rate error budget alerts over static thresholds.
- The current guide names AI assistance explicitly across several sections: Gemini Code Assist, Gemini Cloud Assist and Gemini CLI. Know what each is for rather than treating them as marketing.
- Secret handling is its own published sub-topic. Be able to distinguish Cloud KMS, Secret Manager, Certificate Manager and Parameter Manager, and to explain why runtime injection beats baking a secret into an image at build time.
Study guide FAQ
What are the exam sections and how are they weighted?
Google publishes five: bootstrapping and maintaining a Google Cloud organization (~20%), building and implementing CI/CD pipelines including continuous testing (~25%), applying site reliability engineering practices (~18%), implementing observability practices and troubleshooting issues (~25%), and optimising performance and cost (~12%). CI/CD and observability are the two largest at a quarter of the exam each.
How is the error budget calculated and what happens when it runs out?
The error budget is 1 minus the SLO, so a 99.9% availability SLO gives a 0.1% budget over a rolling window. When the budget is healthy, teams ship features aggressively; when it is exhausted, the policy is to freeze risky releases and prioritize reliability work until the budget recovers.
What is the difference between an SLI, an SLO, and an SLA?
An SLI is the measured indicator (e.g., percentage of requests succeeding under 200ms), an SLO is the internal target set on that SLI (e.g., 99.9%), and an SLA is the external contractual commitment to customers, usually set looser than the SLO so you can act on budget burn before breaching the contract.
How much hands-on Google Cloud experience does this exam assume?
Google recommends about three years of industry experience including at least one year managing solutions on Google Cloud. You should be comfortable with gcloud commands, Cloud Build, Cloud Deploy, GKE, Cloud Run, the Operations suite, and applying SRE practices, not just memorizing definitions.
Is this exam more about tools or about SRE concepts?
Both, but SRE concepts dominate the framing. Many questions describe a situation and ask for the practice that best balances reliability and velocity (error budgets, toil reduction, blameless postmortems), then expect you to choose the correct Google Cloud service or command to implement it.
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 - Professional Cloud DevOps Engineer exam guide (PDF)link and content verified 8 September 2026Google's web exam-guide URL for this exam now returns a 301 redirect to this PDF, which makes the PDF the current first-party guide rather than one of two competing versions.
- Google Cloud - Professional Cloud DevOps Engineer certification pagelink and content verified 8 September 2026Recommended experience: "3+ years of industry experience including 1+ years designing and managing production systems using Google Cloud".