Compute Engine

Compute Engine offers scalable and flexible virtual machine computing capabilities in the cloud, with options to utilize certain CPUs, GPUs, or Cloud TPUs. You can use Compute Engine to solve large-scale processing and analytic problems on Google’s computing, storage, and networking infrastructure.

Google Cloud Compute Options – VMs, GKE & Cloud Run

~ Last updated on : ~ jayendrapatil

Google Cloud Compute Options

📌 Updated June 2026: This post has been updated to reflect major Google Cloud compute changes including Cloud Functions rebranding to Cloud Run functions (Aug 2024), Cloud Run worker pools (GA 2026), GPU support on Cloud Run, GKE Autopilot as default mode, new Axion-based machine types, and App Engine legacy runtime deprecations.

Compute Engine

  • provides Infrastructure as a Service (IaaS) in the Google Cloud
  • offers scalable, high performance virtual machines (VMs) on Google’s infrastructure.
  • provides full control/flexibility on the choice of OS, resources like CPU and memory
  • supports a wide range of machine families:
    • General-purpose: E2, N2, N2D, N4, N4A (Axion/Arm-based), C4, C4A (Axion/Arm-based), C4D
    • Compute-optimized: C2, C2D, H3
    • Memory-optimized: M1, M2, M3
    • Accelerator-optimized: A2, A3, G2 (with NVIDIA GPUs)
  • New (2024-2026):
    • Google Axion Processors – custom Arm-based processors powering C4A and N4A instances, delivering up to 65% better price-performance and 60% greater energy efficiency than comparable x86 systems
    • C4 VMs – latest Intel-based general-purpose VMs with Google Titanium system offload
    • C4D VMs – AMD-based with confidential computing support, up to 384 vCPUs and 3TB DDR5 memory
    • N4A VMs – most cost-effective N-series VM, up to 2x better price-performance than comparable x86 VMs (GA 2025)
  • Usage patterns
    • lift and shift migrations of existing systems
    • existing VM images to move to the cloud
    • need low-level access to or fine-grained control of the operating system, network, and other operational characteristics
    • require custom kernel or arbitrary OS
    • software that can’t be easily containerized
    • using a third party licensed software
    • AI/ML training workloads requiring GPU accelerators
  • Usage anti-patterns
    • containerized applications – Choose GKE or Cloud Run
    • stateless event-driven applications – Choose Cloud Run functions
    • simple web applications – Choose App Engine or Cloud Run

App Engine

  • is a platform as a service (PaaS) for developing and hosting web applications.
  • helps build highly scalable web and mobile backend applications on a fully managed serverless platform
  • developers can focus on writing code without having to manage the underlying infrastructure.
  • offers two environments:
    • Standard environment – applications run in a sandbox, supports specific runtimes, faster scaling including scale to zero
    • Flexible environment – applications run in Docker containers on Compute Engine VMs, supports any runtime
  • Runtime Updates (2024-2026):
    • Legacy runtimes (Python 2.7, Java 8, Go 1.11, PHP 5.5) reached end of support on January 30, 2024 – existing apps continue to run but re-deployment may be blocked
    • Go 1.11 and PHP 5.5 runtimes deprecated on January 31, 2026
    • Migration to second-generation runtimes is recommended
    • Latest supported runtimes include Python 3.12+, Java 21+, Node.js 20+, Go 1.22+, PHP 8.3+, Ruby 3.3+
  • Usage patterns
    • Rapidly developing CRUD-heavy applications
    • HTTP/S based applications
    • Deploying complex APIs
    • Applications needing automatic scaling without container management
  • Usage anti-patterns
    • Stateful applications requiring lots of in-memory states to meet the performance or functional requirements
    • Systems that require protocols other than HTTP
    • Applications requiring container-level customization – Choose Cloud Run
  • Note: For new projects, Google recommends evaluating Cloud Run as a more flexible alternative to App Engine, with an official migration guide available.

Google Kubernetes Engine – GKE

  • provides a managed environment for deploying, managing, and scaling containerized applications using Google infrastructure.
  • available in two modes:
    • Autopilot (recommended, default since 2023) – fully managed, Google configures and manages nodes, node pools, and in-cluster policy. Pay per pod resource requests.
    • Standard – user manages nodes and node configuration. More flexibility but more operational overhead.
  • GKE Updates (2024-2026):
    • Autopilot is now default mode for new cluster creation (30% of active GKE clusters used Autopilot in 2024)
    • Autopilot compute classes now available for Standard clusters – turn on Autopilot per-workload basis (KubeCon EU 2026)
    • GKE Enterprise (formerly Anthos) – enterprise tier for governing, managing, and operating workloads at scale across hybrid/multi-cloud
    • AI/ML workload support – 66% of organizations rely on Kubernetes for generative AI apps and agents (2026)
    • Multi-agent AI workflows surged 327% in early 2026
  • Usage patterns
    • containerized applications or those that can be easily containerized
    • Hybrid or multi-cloud environments (with GKE Enterprise)
    • Systems leveraging stateful and stateless services
    • Strong CI/CD Pipelines
    • AI/ML workloads requiring GPU orchestration at scale
    • Microservices architectures requiring service mesh
  • Usage anti-patterns
    • non-containerized applications – Choose Compute Engine or App Engine
    • applications requiring very low-level access to the underlying hardware like custom kernel, networking, etc. – Choose Compute Engine
    • stateless event-driven applications – Choose Cloud Run functions
    • simple stateless containerized apps not requiring Kubernetes features – Choose Cloud Run

Cloud Run

  • is a fully managed application platform for running code, functions, or containers on Google’s highly scalable infrastructure.
  • allows developers to build applications in any programming language and deploy them in seconds.
  • abstracts away all infrastructure management allowing users to focus on building applications.
  • is built from Knative.
  • Three resource types (2024-2026):
    • Services – responds to HTTP requests using stateless instances that autoscale (including scale to zero). Also handles events and functions.
    • Jobs – executes parallelizable tasks manually or on a schedule that run to completion.
    • Worker Pools (GA 2026) – handles always-on background workloads such as pull-based workloads (e.g., Kafka consumers, Pub/Sub pull queues, RabbitMQ consumers). Does NOT have a load-balanced endpoint or autoscale automatically.
  • Key Features (2024-2026):
    • GPU support – on-demand access to NVIDIA L4 GPUs for AI inference workloads, instances start in 5 seconds and scale to zero
    • Cloud Run functions – Cloud Functions rebranded and merged into Cloud Run (August 2024), same event-driven model with Cloud Run’s configurability
    • Sidecars – multi-container deployments with independent sidecar containers alongside main container
    • Always-on CPU allocation – CPU available even between requests for background processing
    • Volume mounts – Cloud Storage, NFS, in-memory, CIFS/SMB, and Ephemeral Disk support
    • Manual scaling option – override automatic scaling for predictable workloads
    • WebSocket and gRPC support – full support for real-time communication
    • Source-based deployment – deploy directly from source code without building containers
    • AI/ML workloads – run LLM inference (Ollama, Gemma), AI agents (ADK, A2A), and MCP servers
  • Usage patterns
    • Stateless services that are easily containerized
    • Event-driven applications and systems
    • Applications that require custom system and language dependencies
    • AI inference workloads (with GPU support)
    • Background processing (worker pools for Kafka consumers, message queues)
    • Batch processing (jobs with parallelism)
    • Websites, APIs, and microservices
  • Usage anti-patterns
    • Applications requiring persistent VMs with custom kernels – Choose Compute Engine
    • Complex container orchestration requiring Kubernetes features – Choose GKE
    • Applications requiring strict low-level infrastructure control

Cloud Run Functions (formerly Cloud Functions)

⚠️ Rebranding Notice (August 2024): Google Cloud Functions has been renamed to Cloud Run functions and merged under the Cloud Run platform. The event-driven programming model remains the same, but functions now run on Cloud Run infrastructure with its full configurability. The gcloud functions CLI and APIs continue to work.
  • offers scalable pay-as-you-go Functions as a Service (FaaS) to run code with zero server management.
  • provides a serverless execution environment for building and connecting Cloud services.
  • provides serverless compute for event-driven apps.
  • developers can focus on writing code without having to manage the underlying infrastructure.
  • Two generations:
    • Cloud Run functions (formerly 2nd gen / Cloud Functions 2nd gen) – runs on Cloud Run infrastructure, supports longer timeouts (up to 60 min), larger instances (up to 32 GB RAM, 8 vCPUs), concurrency, traffic splitting, and Direct VPC egress
    • Cloud Run functions (1st gen) (formerly Cloud Functions 1st gen) – original version with limited event triggers and configurability, limited to 9 min timeout and 8 GB RAM
  • Usage patterns
    • ephemeral and event-driven applications and functions
    • fully managed environment
    • pay only for what you use
    • quick data transformations (ETL)
    • Webhooks and lightweight APIs
    • Responding to Cloud Storage, Pub/Sub, Firestore, or Firebase events
  • Usage anti-patterns
    • continuous stateful application – Choose Compute Engine, App Engine, or GKE
    • long-running background processing – Choose Cloud Run worker pools
    • applications requiring multiple containers or sidecars – Choose Cloud Run services

Google Cloud Compute Options Comparison

Feature Compute Engine GKE App Engine Cloud Run Cloud Run Functions
Type IaaS CaaS (Container) PaaS Serverless Containers FaaS
Abstraction Level VMs Containers/Pods Application Container/Source Function
Scaling Autoscaler (MIGs) Pod/Node Autoscaler Automatic Automatic (0 to N) Automatic (0 to N)
Scale to Zero No No (pods stay) Yes (Standard) Yes Yes
GPU Support Yes Yes No Yes (NVIDIA L4) No
Max Timeout Unlimited Unlimited 60 min 60 min (services) 60 min (2nd gen)
Pricing Per VM (sec) Per node + mgmt fee Per instance-hour Per request/instance Per invocation + time
Google Cloud Compute Options Comparison
Credit @ https://thecloudgirl.dev/

Google Cloud Compute Options Decision Tree

Google Cloud Compute Options Decision Tree

Key Decision Criteria

  • Need full VM control? → Compute Engine
  • Containerized app needing Kubernetes features (service mesh, complex networking, stateful sets)? → GKE
  • Simple containerized app, HTTP-driven? → Cloud Run (services)
  • Background pull-based processing (Kafka, queues)? → Cloud Run (worker pools)
  • Batch/parallel tasks running to completion? → Cloud Run (jobs)
  • Event-driven single-purpose functions? → Cloud Run functions
  • Quick PaaS web app without container knowledge? → App Engine
  • AI inference with serverless GPU? → Cloud Run with GPU
  • AI training at scale with GPU orchestration? → GKE or Compute Engine

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. Your organization is developing a new application. This application responds to events created by already running applications. The business goal for the new application is to scale to handle spikes in the flow of incoming events while minimizing administrative work for the team. Which Google Cloud product or feature should you choose?
    1. Cloud Run
    2. Cloud Run for Anthos (Note: Cloud Run for Anthos has been deprecated and archived. It is now referred to as Knative serving on GKE.)
    3. App Engine standard environment
    4. Compute Engine
  2. A company wants to build an application that stores images in a Cloud Storage bucket and wants to generate thumbnails as well as resize the images. They want to use managed service which will help them scale automatically from zero to scale and back to zero. Which GCP service satisfies the requirement?
    1. Google Compute Engine
    2. Google Kubernetes Engine
    3. Google App Engine
    4. Cloud Run functions (formerly Cloud Functions)
  3. A startup needs to deploy a containerized machine learning inference model that requires GPU access, should scale to zero when not in use, and needs to start serving requests within seconds. Which compute option is most suitable?
    1. Compute Engine with GPU attached
    2. GKE with GPU node pool
    3. Cloud Run with GPU (NVIDIA L4)
    4. App Engine flexible environment
  4. Your team has a Kafka consumer application that needs to continuously process messages from a topic. The application does not serve HTTP requests. You want to use a serverless managed platform. Which Cloud Run resource type should you use?
    1. Cloud Run service
    2. Cloud Run job
    3. Cloud Run worker pool
    4. Cloud Run functions
  5. A company is running multiple microservices across on-premises data centers and Google Cloud. They need a consistent container orchestration platform with centralized policy management across all environments. Which solution should they use?
    1. Cloud Run
    2. App Engine flexible
    3. GKE Enterprise (formerly Anthos)
    4. Compute Engine managed instance groups
  6. You are designing a new serverless application that processes files uploaded to Cloud Storage. The processing takes about 30 seconds per file and you want minimal operational overhead. Which option is most appropriate?
    1. Compute Engine with a cron job
    2. Cloud Run functions triggered by Cloud Storage event
    3. GKE CronJob
    4. App Engine Standard with task queue
  7. Your team needs to run a data migration script that processes 10,000 records in parallel and should complete execution. The script does not need to serve HTTP traffic. Which Cloud Run resource type is best suited?
    1. Cloud Run service with always-on CPU
    2. Cloud Run job with parallelism
    3. Cloud Run worker pool
    4. Cloud Run functions
  8. A company wants to use Google’s custom Arm-based processors for their web servers to optimize cost and energy efficiency. Which instance family should they choose?
    1. N2 instances
    2. C2 instances
    3. C4A instances (Google Axion)
    4. E2 instances

See also: Google Cloud Compute Services Cheat Sheet

Google Cloud Compute Engine Snapshots & Backups

~ Last updated on : ~ jayendrapatil

Compute Engine Snapshots

  • Snapshots provide periodic backup of Persistent Disk and Google Cloud Hyperdisk volumes.
  • Snapshots incrementally back up data from the disks.
  • Snapshots are global resources by default, so any snapshot is accessible by any resource within the same project. Regionally scoped snapshots (Preview) are also available for data residency requirements.
  • Snapshots can be shared across projects.
  • Storage costs for disk snapshots charge only for the total size of the snapshot.
  • Snapshots once created with the current state of the disk, can be restored as a new disk.
  • Compute Engine stores multiple copies of each snapshot across multiple locations with automatic checksums to ensure the integrity of the data.
  • Snapshots can be created from disks even while they are attached to running virtual machine (VM) instances.
  • Lifecycle of a snapshot created from a disk attached to a running VM instance is independent of the lifecycle of the VM instance.
  • Standard and archive snapshots can be stored in either one Cloud Storage multi-regional location, such as asia, or one Cloud Storage regional location, such as asia-south1.
  • A multi-regional storage location provides higher availability and might reduce network costs when creating or restoring a snapshot.
  • A snapshot can be used to create a new disk in any region and zone, regardless of the storage location of the snapshot.

Snapshot Types

  • Compute Engine provides three types of snapshots: Standard, Archive, and Instant.
  • All three types capture the contents of a disk at a specific point in time but differ in retention behavior, recovery time, and storage location.

Standard Snapshots

  • Provide geo-redundant data backup stored in one or more regions, separate from the source disk.
  • Best for disaster recovery and regular backups.
  • Support both Persistent Disk and Hyperdisk volumes.
  • Can be created with snapshot schedules for automated backups.
  • Are NOT deleted when the source disk is deleted.
  • Offer faster data recovery times than archive snapshots.

Archive Snapshots

  • Same benefits as standard snapshots (incremental chains, compression, encryption) but at lower cost.
  • Best suited for compliance, audit, and long-term cold storage use cases.
  • Have a 90-day minimum billing period and charges for retrievals.
  • Have the longest data recovery times but offer the most cost-efficient storage.
  • Cannot be created with snapshot schedules.
  • Are NOT deleted when the source disk is deleted.
  • Stored in separate incremental snapshot chains from standard snapshots.

Instant Snapshots

  • Introduced in August 2024, instant snapshots provide near-instantaneous, high-frequency, point-in-time checkpoints of a disk.
  • Provide in-place data backup stored in the same zone or region as the source disk.
  • Offer the lowest and best recovery times — RPO of seconds and RTO in tens of seconds.
  • Created in seconds with no performance impact to the underlying disk.
  • Are incremental — only store changed data blocks since the previous instant snapshot.
  • Are deleted when the source disk is deleted (lifecycle tied to source disk).
  • Not redundant — stored only in the same zone/region as the source disk.
  • Cannot be created with snapshot schedules.
  • Can be converted to standard or archive snapshots for geo-redundant, long-term storage.
  • Support Persistent Disk and most Hyperdisk types (except Hyperdisk ML and Hyperdisk Throughput).
  • Use cases include:
    • Rapid recovery from user error, application failures, and file system corruption.
    • Backup verification workflows (create snapshot, restore, verify consistency).
    • Taking restore points before application upgrades for rapid rollback.
    • Improving developer productivity with fast restores during development cycles.

Snapshot Type Comparison

Feature Standard Archive Instant
Best for Geo-redundant DR backup Long-term cold storage, compliance In-place backup, rapid restore
Storage Location Multi-region or regional (separate from source) Multi-region or regional (separate from source) Same zone/region as source disk
Recovery Time Minutes Longest (minutes to hours) Seconds
Redundancy Geo-redundant Geo-redundant Not redundant (same zone only)
Hyperdisk Support Yes Yes Yes (except ML & Throughput)
Snapshot Schedules Yes No No
Deleted on Source Disk Deletion No No Yes

Snapshot Scopes (Preview)

  • Snapshots can be created as globally scoped (default) or regionally scoped.
  • Globally scoped snapshots can be created and restored in any region without restriction.
  • Regionally scoped snapshots ensure all snapshot data and metadata are co-located within the scoped region.
    • Restrict allowed snapshot creation and restore locations.
    • Help control network costs.
    • Enhance resiliency to global outages.
    • Provide additional data security by limiting locations where data can be created/restored.
  • Regionally scoped snapshots can only be stored in Cloud Storage regional locations (not multi-regional).
  • Cannot convert a globally scoped snapshot to a regionally scoped snapshot — must create a new one.

Snapshot Creation

  • Snapshots are incremental and automatically compressed, so that they can be regularly created on a Persistent Disk or Hyperdisk faster and at a lower cost than regularly creating a full image of the disk.
  • Incremental snapshots work as follows:
    • The first successful snapshot of a disk is a full snapshot that contains all the data on the disk.
    • The second snapshot only contains any new data or modified data since the first snapshot. Data that hasn’t changed since the first snapshot isn’t included. Instead, it contains references to the first snapshot for any unchanged data.
    • Snapshot 3 contains any new or changed data since snapshot 2 but won’t contain any unchanged data from snapshot 1 or 2. Instead, snapshot 3 contains references to blocks in snapshot 1 and snapshot 2 for any unchanged data.
  • To ensure the reliability of snapshot history, a snapshot might occasionally capture a full image of the disk automatically.

Snapshot Chains

  • Standard snapshots can be created in distinct snapshot chains by specifying a chain name at creation time.
  • Each new snapshot with the same chain name is based incrementally on the last successful snapshot created with that chain name.
  • Useful for advanced use cases like chargeback tracking across separate incremental chains.
  • Standard and archive snapshots are stored in separate incremental chains.

Snapshot Deletion

  • Compute Engine uses incremental snapshots so that each snapshot contains only the data that has changed since the previous snapshot.
  • For unchanged data, snapshots reference the data in previous snapshots.
  • Warning: Deleting a snapshot is irreversible. You can’t recover a deleted snapshot.
  • When a snapshot is deleted:
    • If the snapshot has no dependent snapshots, it is deleted outright.
    • If the snapshot does have dependent snapshots:
      • Any data that is required for restoring other snapshots is moved into the next snapshot, increasing its size.
      • Any data that is not required for restoring other snapshots is deleted. This lowers the total size of all your snapshots.
      • The next snapshot no longer references the snapshot marked for deletion, and instead references the snapshot before it.
  • Deleting a snapshot does not necessarily delete all the data on the snapshot because subsequent snapshots might require that information.
  • To definitively delete data from the snapshots, you should delete all snapshots.
  • If a disk has a snapshot schedule, you must detach the schedule from the disk before deleting it.

Snapshot Schedules

  • Snapshot schedules create standard snapshots at specified intervals to provide automated, geo-redundant disk backups.
  • Support both Persistent Disk and Hyperdisk volumes (zonal and regional).
  • Snapshot schedules are a best practice for backing up Compute Engine workloads — available at no additional charge.
  • Configure schedules with:
    • Frequency: Hourly (1-23 hour intervals), daily, or weekly.
    • Retention policy: Maximum number of days to retain snapshots with auto-deletion of older ones.
    • Source disk deletion behavior: What happens to automatic snapshots when the source disk is deleted.
    • Storage location: Region or multi-region for snapshot storage.
  • Application consistent snapshots can be configured for:
    • Windows: VSS (Volume Shadow Copy Service) snapshots.
    • Linux: Guest-flush option with pre/post snapshot scripts (Persistent Disk only).
  • Snapshot schedules have separate frequency considerations and don’t contribute to the manual snapshot frequency limit.

Backup and DR Service

  • Google Cloud Backup and DR Service provides enhanced protection with immutable and indelible backups of Compute Engine instances.
  • Offers an out-of-the-box backup solution with seamless backup management across projects.
  • Supports backup plans that can be applied to instances during or after creation.
  • Provides features beyond snapshot schedules:
    • Immutable backups protected against deletion for a specified retention period.
    • Centralized backup management console.
    • Cross-region backup storage for disaster recovery.
    • Scheduled backups (daily, weekly, monthly, yearly).
  • Uses Persistent Disk snapshots under the hood to incrementally back up data at the instance level.

Snapshot Best Practices

  • Security: Only grant snapshot-related IAM permissions (compute.snapshots.useReadOnly, compute.instantSnapshots.useReadOnly) to trusted principals to prevent unintended privilege escalation.
  • Crash Consistent vs Application Consistent:
    • Crash consistent: Default behavior — captures disk state as if the machine crashed (may have pending writes in transit).
    • Application consistent: Pause applications and flush writes before snapshot to capture complete application state.
  • If creating a snapshot while an application is running, prepare disk for consistency:
    • Pause application/processes that write data, flush disk buffers.
    • Unmount disk completely.
    • For Windows, use VSS snapshots.
    • For Linux on Persistent Disk, use guest-flush with pre/post scripts.
    • For Linux on Hyperdisk, manually pause the application before creating the snapshot.
  • Use snapshot schedules as a best practice to back up your Compute Engine workloads.
  • Use instant snapshots or disk clones instead of standard snapshots when you need an immediate copy in the same zone.
  • Schedule snapshots during off-peak hours (avoid midnight peaks).
  • Snapshot frequency limit: You can snapshot a specific disk at most 6 times every 60 minutes. Avoid taking snapshots more often than once per hour.
  • Use multiple disks for large data volumes. Larger amounts of data create larger snapshots, which cost more and take longer.
  • Run fstrim before snapshot (Linux) or enable the discard mount option to clean up space, reducing snapshot size and creation time.
  • Create an image from an infrequently used snapshot, instead of using the snapshot itself repeatedly (saves networking costs).
  • Use journaling file systems like ext4 to reduce the risk that data is cached without being written to disk.
  • Wait for new snapshots to finish before taking subsequent snapshots from the same disk to avoid duplicate effort.

Snapshot Storage Locations

  • Standard and archive snapshots can be stored in:
    • Cloud Storage multi-regional locations (e.g., asia, us) — highest availability and resilience.
    • Cloud Storage regional locations (e.g., asia-south1, us-central1) — more control over data placement.
  • Regionally scoped snapshots can only be stored in regional locations.
  • You cannot change the storage location of an existing snapshot.
  • Snapshot settings define a default storage location for all project snapshots (configurable).
  • Network charges apply for cross-region snapshot creation or restoration.
  • To minimize costs, store snapshots in the same region as the source disk.

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. You have a workload running on Compute Engine that is critical to your business. You want to ensure that the data on the boot disk of this workload is backed up regularly. You need to be able to restore a backup as quickly as possible in case of disaster. You also want older backups to be cleaned automatically to save on cost. You want to follow Google-recommended practices. What should you do?
    1. Create a Cloud Function to create an instance template.
    2. Create a snapshot schedule for the disk using the desired interval.
    3. Create a cron job to create a new disk from the disk using gcloud.
    4. Create a Cloud Task to create an image and export it to Cloud Storage.
  2. Your application is running on Compute Engine and you need to take point-in-time backups of your Persistent Disk that allow restoration within seconds. The backup must be stored locally for fastest recovery. Which solution should you use?
    1. Create a standard snapshot and store it in the same region.
    2. Create an archive snapshot for long-term storage.
    3. Create an instant snapshot of the disk.
    4. Create a machine image of the entire VM.
  3. You need to retain disk backups for compliance purposes for 2 years, and you rarely need to access them. You want the lowest cost option. What should you do?
    1. Create standard snapshots on a schedule.
    2. Create archive snapshots of the disk.
    3. Create instant snapshots and convert them to standard snapshots.
    4. Export disk images to Cloud Storage Coldline.
  4. You are performing a software upgrade on a Compute Engine VM and want a rapid rollback option if the upgrade fails. You need to restore the disk state in seconds. What is the recommended approach?
    1. Create a standard snapshot before the upgrade.
    2. Create a machine image before the upgrade.
    3. Create an instant snapshot before the upgrade.
    4. Clone the disk before the upgrade.
  5. You delete a snapshot from an incremental chain. What happens to the data that is needed by subsequent snapshots?
    1. The data is permanently lost.
    2. The data is moved to the next snapshot in the chain.
    3. All dependent snapshots are also deleted.
    4. The source disk is updated with the snapshot data.
  6. You need to ensure your Compute Engine disk snapshots comply with data residency requirements and are restricted to a specific region. What should you do?
    1. Store globally scoped snapshots in a regional location.
    2. Use instant snapshots which are stored in the same zone.
    3. Create regionally scoped snapshots with restricted creation and restore locations.
    4. Use archive snapshots with a specific storage location.

References

GCE Storage Options – Persistent Disk vs Local SSD vs Hyperdisk

~ Last updated on : ~ jayendrapatil

Google Cloud Compute Engine Storage Options

📌 2026 Update: Google Cloud now recommends Hyperdisk as the primary block storage for Compute Engine workloads, offering higher performance and customizable IOPS/throughput. Persistent Disk remains available but Hyperdisk is preferred for new deployments on 3rd-gen+ machine series.

Hyperdisk

  • Hyperdisk is the fastest and most efficient durable block storage for Compute Engine, recommended by Google for boot and data disks.
  • Hyperdisk leverages Google’s Titanium storage offload technology for higher IOPS and throughput than Persistent Disk.
  • Hyperdisk volumes are durable network storage devices that function as physical disks attached to compute instances.
  • Hyperdisk provides customizable performance — IOPS and throughput can be configured independently and adjusted dynamically while in use.
  • Hyperdisk volumes are portable and can be detached from one instance and attached to another.
  • Hyperdisk provides built-in torn write protection with an atomic write unit of 128 KB, which can improve database write throughput by up to 25% by eliminating the need for doublewrite buffers.
  • Hyperdisk supports Confidential Computing mode for Hyperdisk Balanced volumes attached to Confidential VMs.

Hyperdisk Types

  • Hyperdisk Balanced — Best fit for most workloads; supports boot disks, virtual desktops, databases (Postgres, MySQL). Max 160,000 IOPS / 2,400 MiB/s throughput. Supports multi-writer (up to 8 instances).
  • Hyperdisk Balanced High Availability — Synchronously replicates data across two zones in the same region. Max 100,000 IOPS / 2,400 MiB/s. Supports multi-writer (up to 8 instances). Designed for RPO of 0.
  • Hyperdisk Extreme — Highest IOPS for demanding workloads (SAP HANA, Oracle, SQL Server). Max 350,000 IOPS / 5,000 MiB/s throughput.
  • Hyperdisk Throughput — High throughput for scale-out analytics (Hadoop, Spark, Kafka) and cold storage. Max 2,400 MiB/s. Cost-effective for capacity-intensive applications.
  • Hyperdisk ML — Designed for AI/ML inference and training; supports read-only attachment to up to 2,500 instances simultaneously. Highest read-only throughput.

Hyperdisk Storage Pools

  • Hyperdisk Storage Pools allow purchasing capacity and performance in bulk, reducing storage TCO by up to 40%.
  • Simplifies planning with thin provisioning, data reduction, and capacity pooling.
  • Supports Hyperdisk Balanced and Hyperdisk Throughput volumes.
  • Hyperdisk Exapools are designed for workloads requiring 1 PiB+ capacity or 1 TiB/s+ throughput per zone (e.g., large-scale AI/ML, parallel file systems).

Hyperdisk High Availability & Disaster Recovery

  • Cross-zonal (synchronous) — Hyperdisk Balanced High Availability replicates data synchronously between two zones in the same region.
  • Cross-regional (asynchronous) — Asynchronous Replication continuously copies data to a secondary region. Supported for Hyperdisk Balanced, Hyperdisk Extreme, and Hyperdisk Balanced High Availability.

Hyperdisk Machine Series Support

  • Hyperdisk Balanced is supported on C3, C3D, C4, C4A, C4D, N4, N4A, N4D, M3, M4, A3, A4, G4, Z3 and other 3rd-gen+ machine series.
  • Older machine series (N1, E2, C2, C2D, T2A) do not support Hyperdisk and must use Persistent Disk.
  • Generally, use Hyperdisk Balanced High Availability for 3rd-gen+ machine series and Regional Persistent Disks for 2nd-gen or older.

Persistent Disk

  • Persistent disks are durable network storage devices that the instances can access like physical disks in a desktop or a server.
  • Persistent disks are used as boot disks.
  • Data on each persistent disk is distributed across several physical disks.
  • Compute Engine manages the physical disks and the data distribution to ensure redundancy and optimal performance.
  • Persistent disks are located independently from the VM instances and can be detached or moved to keep the data even after the instance is deleted.
  • Persistent disk performance scales automatically with size, so they can be resized or additional ones added to meet the performance and storage space requirements.
  • Google now recommends Hyperdisk for highest performance and advanced features on supported machine series.

Persistent Disk Types

  • Standard persistent disks (pd-standard) are backed by standard hard disk drives (HDD).
  • Balanced persistent disks (pd-balanced) are backed by solid-state drives (SSD). They are an alternative to SSD persistent disks that balance performance and cost.
  • SSD persistent disks (pd-ssd) are backed by solid-state drives (SSD).
  • Extreme persistent disks (pd-extreme) provide configurable IOPS (2,500 to 120,000) with SSD-backed storage for high-performance database workloads like SAP HANA and SQL Server.

Zonal Persistent Disks

  • Zonal persistent disks provide durable storage and replication of data within a single zone in a region.
  • Persistent disks have built-in redundancy to protect the data against equipment failure and to ensure data availability through datacenter maintenance events.
  • For additional space on the persistent disks, resize the disks and resize the single file system rather than repartitioning and formatting.
  • Compute Engine automatically encrypts the data in transit, before it travels outside of the instance to persistent disk storage space.
  • Zonal persistent disk remains encrypted either with system-defined keys or with customer-supplied keys.

Regional Persistent Disks

  • Regional persistent disks provide durable storage and replication of data between two zones in the same region.
  • Regional persistent disks are also designed to work with regional managed instance groups.
  • Zonal outage can be handled by force attaching the disk to the standby instance, even if the disk can’t be detached from the original VM.
  • Regional persistent disks are designed for
    • workloads that require a lower RPO and RTO compared to using persistent disk snapshots.
    • write performance is less critical than data redundancy across multiple zones.
  • Regional persistent disks cannot be used with memory-optimized machines and compute-optimized machines.
  • For 3rd-gen+ machine series, Google recommends Hyperdisk Balanced High Availability instead of Regional Persistent Disks.

Local SSD

  • Local SSDs are physically attached to the server that hosts the VM instance.
  • Local SSDs have higher throughput and lower latency than standard persistent disks or SSD persistent disks.
  • Data stored on a local SSD persists only until the instance is stopped or deleted.
  • Local SSD disks cannot be used as boot disks.
  • Local SSD disks can be attached only during instance creation, and not once the instance is created.
  • Local SSDs performance gains require certain trade-offs in availability, durability, and flexibility. Because of these trade-offs, Local SSD storage isn’t automatically replicated and all data on the local SSD might be lost if the instance terminates for any reason.
  • Each local SSD is 375 GB in size, but a maximum of 24 local SSD partitions can be attached for a total of 9 TB per instance.
  • Compute Engine automatically encrypts the data when it is written to local SSD storage space. Customer-supplied encryption keys is not supported with local SSDs.

Local SSD on Newer Machine Series

  • For C3, C3D, C4, and C4D machine series, Local SSD is available only with specific machine types that end in -lssd (e.g., c3-standard-88-lssd, c4-standard-96-lssd).
  • For Z3, A4X, A4, A3, and A2 Ultra machine series, every machine type comes with Local SSD storage.
  • C4 VMs with Intel Xeon 6 (Granite Rapids) use Titanium Local SSD with up to 35% lower access latency compared to prior generations.
  • Local SSD cannot be used with shared-core machine types (e.g., E2).

Cloud Storage Buckets

  • Cloud Storage buckets are the most flexible, scalable, and durable storage option for the VM instances.
  • Cloud Storage is ideal if you don’t require the lower latency of Persistent Disks and Local SSDs, and can store the data in a Cloud Storage bucket.
  • Performance of Cloud Storage depends on the selected storage class.
  • Standard storage class used in the same location as the instance gives performance that is comparable to persistent disks but with higher latency and less consistent throughput characteristics.
  • Cloud Storage buckets have built-in redundancy to protect the data against equipment failure and to ensure data availability through datacenter maintenance events.
  • Cloud Storage buckets aren’t restricted to the zone where the instance is located. Multiregional Cloud Storage buckets store the data redundantly across at least two regions within a larger multiregional location.
  • Cloud Storage bucket can be mounted on the instance as a file system using Cloud Storage FUSE (gcsfuse).
  • Cloud Storage allows read and write data to a bucket from multiple instances simultaneously.
  • However, Cloud Storage buckets are object stores that don’t have the same write constraints as a POSIX file system and can’t be used as boot disks. Multiple instances working on the same file can lead to overwritten data.
  • Cloud Storage supports both encryption at rest and in transit.

Cloud Storage FUSE

  • Cloud Storage FUSE (gcsfuse) is a fully supported, GA product that allows mounting Cloud Storage buckets as local file systems on Compute Engine instances.
  • Particularly beneficial for AI/ML workloads that use frameworks requiring file-based data access (PyTorch, TensorFlow).
  • Supports caching, parallel downloads, and performance profiles for optimized workloads.
  • Provides a cost-effective alternative to persistent disk storage for read-heavy workloads.

Filestore

  • Filestore provides high-performance, fully managed network-attached storage (NAS) file storage using NFSv3 and NFSv4.1 protocols.
  • Filestore is ideal for workloads requiring a shared file system across multiple Compute Engine instances.

Filestore Service Tiers

  • Basic (HDD/SSD) — Entry-level, single-zone file storage for development and testing.
  • Zonal — High-performance, single-zone storage with up to 26 GiB/s throughput. Ideal for AI/ML training workloads.
  • Regional — Multi-zone availability within a region for business-critical workloads.
  • Enterprise — Multi-zone, multi-share capable, regional resilience for mission-critical enterprise workloads. Supports the Filestore CSI driver for GKE.

Storage Options Comparison

Feature Hyperdisk Persistent Disk Local SSD Cloud Storage Filestore
Type Network block storage Network block storage Locally attached Object storage Managed NFS
Durability 99.999%–99.9999% 99.999%–99.9999% Not durable (ephemeral) 99.999999999% (11 nines) Regional redundancy
Boot Disk Yes (Balanced only) Yes No No No
Performance Up to 350K IOPS / 5,000 MiB/s Up to 120K IOPS (Extreme) Very high (lowest latency) High throughput, higher latency Up to 26 GiB/s (Zonal)
Multi-VM Access Yes (multi-writer / read-only) Yes (multi-writer / read-only) No (single VM only) Yes Yes
Encryption Google-managed / CMEK / Confidential Google-managed / CMEK / CSEK Automatic (no CSEK) Google-managed / CMEK / CSEK Google-managed / CMEK

Google Cloud Compute Engine Storage Options

Storage Options Performance Comparison

Google Cloud Compute Engine Storage Performance

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. A company needs block storage for a database running on a C4 machine that requires the highest IOPS with configurable performance. Which storage option should they use?
    1. Persistent Disk SSD (pd-ssd)
    2. Hyperdisk Balanced
    3. Hyperdisk Extreme
    4. Local SSD
    Show Answer

    Answer: c – Hyperdisk Extreme provides the highest IOPS (up to 350,000) with configurable performance on C4 machine series.

  2. An organization wants to ensure zero data loss (RPO = 0) across zones for their mission-critical application running on C3 VMs. Which storage option provides this?
    1. Regional Persistent Disk
    2. Hyperdisk Balanced High Availability
    3. Hyperdisk Balanced with Asynchronous Replication
    4. Cloud Storage with multi-region bucket
    Show Answer

    Answer: b – Hyperdisk Balanced High Availability synchronously replicates data across two zones within the same region with RPO of 0. For 3rd-gen+ machine series, it is preferred over Regional Persistent Disks.

  3. A data science team needs to share a large ML model dataset across 500 GPU instances for inference. Which storage type is most appropriate?
    1. Hyperdisk Balanced with multi-writer
    2. Hyperdisk ML
    3. Hyperdisk Throughput
    4. Cloud Storage
    Show Answer

    Answer: b – Hyperdisk ML supports read-only attachment to up to 2,500 instances simultaneously and provides the highest read-only throughput, making it ideal for ML inference workloads.

  4. Which of the following statements about Local SSD on newer machine series (C3, C4) is correct?
    1. Local SSD can be attached to any C4 machine type after instance creation
    2. Local SSD is available only on machine types ending in -lssd (e.g., c3-standard-88-lssd)
    3. Local SSD is automatically attached to all C3 machine types
    4. Local SSD on C4 uses HDD storage for cost savings
    Show Answer

    Answer: b – For C3, C3D, C4, and C4D machine series, Local SSD is only available with specific machine types ending in -lssd.

  5. A company has a Hadoop cluster requiring high throughput, low-cost storage. Which Hyperdisk type is most suitable?
    1. Hyperdisk Balanced
    2. Hyperdisk Extreme
    3. Hyperdisk Throughput
    4. Hyperdisk ML
    Show Answer

    Answer: c – Hyperdisk Throughput is designed for scale-out analytics workloads like Hadoop, Spark, and Kafka, providing high throughput at a cost-effective price.

  6. Which Hyperdisk feature can improve MySQL database write performance by up to 25%?
    1. Customizable IOPS
    2. Torn write protection
    3. Storage Pools
    4. Multi-writer mode
    Show Answer

    Answer: b – Hyperdisk’s built-in torn write protection eliminates the need for database-level doublewrite buffers, increasing write throughput by up to 25%.

  7. An organization running N1 VMs needs high-performance block storage. Which storage option is available?
    1. Hyperdisk Balanced
    2. Hyperdisk Extreme
    3. Extreme Persistent Disk (pd-extreme)
    4. Hyperdisk ML
    Show Answer

    Answer: c – N1 machine series does not support any Hyperdisk type. Extreme Persistent Disk (pd-extreme) is available for high-performance needs on older machine series.

  8. Which storage option should be used to protect Hyperdisk data from a regional outage?
    1. Hyperdisk Balanced High Availability
    2. Regional Persistent Disk
    3. Asynchronous Replication
    4. Cloud Storage multi-region bucket
    Show Answer

    Answer: c – Asynchronous Replication maintains a copy of Hyperdisk data in another region for cross-regional disaster recovery. Hyperdisk Balanced HA only protects against zonal outages within a region.

References

Google Cloud Compute Services Cheat Sheet

~ Last updated on : ~ jayendrapatil

Google Cloud Compute Services

Google Cloud - Compute Services Options

Google Cloud provides a range of compute services to run workloads, from fully managed serverless platforms to infrastructure-level virtual machines. The key compute services include Compute Engine, GKE, App Engine, Cloud Run, and Cloud Run functions (formerly Cloud Functions).

Compute Engine

  • is a virtual machine (VM) hosted on Google’s infrastructure.
  • can run the public images for Google provided Linux and Windows Server as well as custom images created or imported from existing systems
  • availability policy determines how it behaves when there is a maintenance event
    • VM instance’s maintenance behavior onHostMaintenance, which determines whether the instance is live migrated MIGRATE (default) or stopped TERMINATE
    • Instance’s restart behavior automaticRestart which determines whether the instance automatically restarts (default) if it crashes or gets stopped
  • Live migration helps keep the VM instances running even when a host system event, such as a software or hardware update, occurs
  • Spot VMs (recommended replacement for Preemptible VMs) offer up to 60-91% discount compared to on-demand pricing
    • can be reclaimed by Compute Engine at any time when resources are needed
    • unlike Preemptible VMs, Spot VMs have no maximum runtime limit (no 24-hour expiration)
    • same pricing model as Preemptible VMs
    • ideal for fault-tolerant, batch, and stateless workloads
  • Preemptible VMs (legacy — Google recommends using Spot VMs instead)
    • can be created and run at a much lower price than normal instances
    • always stop after 24 hours of running
    • can be stopped at any time when Compute Engine needs resources
  • Shielded VM offers verifiable integrity of the Compute Engine VM instances, to confirm the instances haven’t been compromised by boot- or kernel-level malware or rootkits.
  • Confidential VMs keep sensitive code and data encrypted in memory during processing (encryption-in-use)
    • uses hardware-based memory encryption with AMD SEV, AMD SEV-SNP, or Intel TDX
    • supports GPU workloads with A3 machine types (NVIDIA H100) using Intel TDX
    • together with encryption-at-rest and encryption-in-transit, provides encryption at all times
  • Instance template is a resource used to create VM instances and managed instance groups (MIGs) with identical configuration
  • Instance group is a collection of virtual machine (VM) instances that can be managed as a single entity.
    • Managed instance groups (MIGs)
      • allows app creation with multiple identical VMs.
      • workloads can be made scalable and highly available by taking advantage of automated MIG services, including: autoscaling, autohealing, regional (multiple zone) deployment, and automatic updating
      • supports rolling update feature
      • works with load balancing services to distribute traffic across all of the instances in the group.
    • Unmanaged instance groups
      • allows load balance across a fleet of VMs that you manage yourself which may not be identical
  • Instance templates are global, while instance groups are regional.
  • Machine image stores all the configuration, data, metadata and permissions from one or more disks required to create a VM instance
  • Sole-tenancy provides dedicated hosting only for the project’s VM and provides added layer of hardware isolation
  • deletionProtection prevents accidental VM deletion esp. for VMs running critical workloads and need to be protected
  • provides Sustained Discounts, Committed discounts, free tier etc. in pricing

Machine Families (Updated 2025)

  • General-purpose — best price-performance for common workloads
    • C4 — powered by 5th/6th Gen Intel Xeon Scalable processors (Emerald Rapids/Granite Rapids) and Google Titanium
    • C4D — powered by 5th Gen AMD EPYC Turin processors and Titanium; up to 80% higher throughput per vCPU for web-serving workloads; supports confidential computing
    • C4A — powered by Google Axion (Arm-based) processors with Titanium SSD; up to 72 vCPUs
    • N4D — AMD Turin-based; up to 3.5x throughput for web-serving vs. previous-gen N2D
    • E2, N2, N2D, N1 — previous generation general-purpose options
  • Compute-optimized — highest per-core performance (C2, C2D, H3)
  • Memory-optimized — large in-memory workloads (M1, M2, M3, X4)
  • Accelerator-optimized — GPU/ML workloads (A2, A3, G2, G4)
    • A3 — NVIDIA H100 GPUs, ideal for AI/ML training and large model inference
    • G4 — NVIDIA RTX PRO 6000 GPUs for graphics and virtual workstations
  • Storage-optimized — high IOPS local storage (Z3)

Storage Options

  • Persistent Disk — network-attached block storage (Standard, Balanced, SSD, Extreme)
  • Hyperdisk — next-generation block storage with substantially higher IOPS and throughput
    • Hyperdisk Balanced — general workloads with independently configurable IOPS and throughput
    • Hyperdisk Throughput — optimized for sequential reads/writes
    • Hyperdisk Extreme — highest performance for databases
    • Hyperdisk Balanced High Availability — multi-zone replication for critical workloads
    • Supports Confidential mode for hardware-based encryption
  • Local SSD — physically attached high-performance local storage
  • Titanium SSD — Google’s custom SSD integrated with Titanium infrastructure (available on C4A)

App Engine

  • App Engine helps build highly scalable applications on a fully managed serverless platform
  • Each Cloud project can contain only a single App Engine application
  • App Engine is regional, which means the infrastructure that runs the apps is located in a specific region, and Google manages it so that it is available redundantly across all of the zones within that region
  • App Engine application location or region cannot be changed once created
  • App engine allows traffic management to an application version by migrating or splitting traffic.
    • Traffic Splitting (Canary) – distributes a percentage of traffic to versions of the application.
    • Traffic Migration – smoothly switches request routing
  • Supports Standard and Flexible environments
    • Standard environment
      • Application instances that run in a sandbox, using the runtime environment of a supported language only.
      • Sandbox restricts what the application can do
        • only allows the app to use a limited set of binary libraries
        • app cannot write to disk
        • limits the CPU and memory options available to the application
      • Sandbox does not support
        • SSH debugging
        • Background processes
        • Background threads (limited capability)
        • Using Cloud VPN
    • Flexible environment
      • Application instances run within Docker containers on Compute Engine virtual machines (VM).
      • As Flexible environment supports docker it can support custom runtime or source code written in other programming languages.
      • Allows selection of any Compute Engine machine type for instances so that the application has access to more memory and CPU.
  • min_idle_instances indicates the number of additional instances to be kept running and ready to serve traffic for this version.

App Engine Runtime Lifecycle (Updated 2025)

  • Legacy runtimes reached End of Support on January 30, 2024 — Python 2.7, Java 8, PHP 5.5, Go 1.11
  • Legacy runtimes deprecated on January 31, 2026 and will be decommissioned after that
  • Google recommends Cloud Run as the modern alternative for new serverless container workloads
  • Cloud Run offers more flexibility: custom containers, VPC connectivity, GPU support, and finer-grained scaling controls
  • App Engine migration center provides guidance for moving to Cloud Run

Google Kubernetes Engine (GKE)

  • is a managed Kubernetes service for deploying and managing containerized applications
  • provides a fully managed environment for deployment, management, and scaling of containerized apps using Google infrastructure
  • uses Compute Engine instances as nodes in a cluster

GKE Modes of Operation

  • Autopilot mode (default since 2023, recommended)
    • fully managed — GKE manages nodes, node pools, and cluster infrastructure
    • pay-per-pod model — charges based on requested vCPU, memory, and ephemeral storage
    • hardened security configuration enabled by default
    • automatic security patching of nodes
    • built-in best practices for security, reliability, performance, and scalability
    • In 2024, 30% of active GKE clusters used Autopilot mode
    • In 2025, Autopilot became available to all qualifying clusters (automatic migration)
    • supports custom compute classes for workload-specific hardware requirements
  • Standard mode
    • provides full control over node configuration and management
    • user is responsible for managing and configuring individual nodes
    • can run Autopilot-mode workloads within Standard clusters
    • multi-cluster management features (Fleets, Teams, Config Management, Policy Controller) now included at no additional cost (2025)

GKE Key Features

  • Node Pools — group of nodes with identical configuration within a cluster
    • supports autoscaling (automatically adjusts number of nodes)
    • supports auto-provisioning (GKE creates optimal node pools automatically)
    • surge upgrade strategy by default (maxSurge=1, maxUnavailable=0)
  • Cluster Autoscaler — automatically resizes number of nodes based on workload demands
  • Vertical Pod Autoscaler (VPA) — adjusts CPU/memory requests for containers
  • Horizontal Pod Autoscaler (HPA) — adjusts number of pod replicas
  • GKE Sandbox — provides an extra layer of security using gVisor for untrusted workloads
  • Confidential GKE Nodes — uses Confidential VMs for hardware-based memory encryption
  • Workload Identity Federation — recommended way to access Google Cloud services from GKE workloads
  • Binary Authorization — deploy-time security control to ensure only trusted containers are deployed

GKE AI/ML Features (2024-2026)

  • GKE Inference Gateway — optimized routing for AI model inference workloads
  • GKE Inference Quickstart — simplified deployment for AI inference serving
  • Custom Compute Classes — define hardware requirements for AI workloads (GPUs, TPUs)
  • GKE Agent Sandbox — secure execution environment for AI agents
  • Support for clusters up to 130,000 nodes for massive AI computation
  • GKE now powers AI workloads for all top 50 Google Cloud platform customers

GKE Commands

  • gcloud container clusters create — creates a new cluster (Autopilot by default)
  • gcloud container clusters create --mode=standard — creates a Standard mode cluster
  • gcloud container clusters resize --num-nodes — scales the cluster node count (--size is deprecated)
  • gcloud container node-pools create — creates a new node pool

Cloud Run

  • is a fully managed serverless platform for running containerized applications
  • automatically scales containers up and down, including scale to zero
  • supports any container that listens for HTTP requests or processes events
  • no infrastructure to manage — deploy with a single command (gcloud run deploy)
  • Cloud Run services — for serving HTTP requests (web apps, APIs)
  • Cloud Run jobs — for running batch tasks to completion (GA since 2023)
  • Cloud Run worker pools — for long-running background workers (2025)
  • GPU support — serverless GPU acceleration with NVIDIA L4 GPUs (GA 2025)
    • ideal for AI inference, image/video processing, and scientific computation
    • no cluster management required
  • pay-per-use pricing — charged only when container is handling requests or running jobs
  • supports both request-based and instance-based billing models
  • integrates with VPC for private networking and direct VPC egress

Cloud Run Functions (formerly Cloud Functions)

  • Renamed from Cloud Functions to Cloud Run functions in August 2024
  • is a Functions-as-a-Service (FaaS) offering powered by Cloud Run and Eventarc
  • provides a simple event-driven programming model for small code snippets
  • supports 90+ event sources via Eventarc triggers
  • deployed as Cloud Run services under the hood, providing same scalability and networking features
  • 1st gen — original version with limited event triggers (legacy)
  • 2nd gen (Cloud Run functions) — latest version with advanced control, longer timeouts, larger instances, and traffic splitting
  • no server management — write code and deploy, infrastructure is handled automatically
  • supports Node.js, Python, Go, Java, .NET, Ruby, and PHP

Compute Services Comparison

Feature Compute Engine GKE App Engine Cloud Run Cloud Run Functions
Type IaaS CaaS (Containers) PaaS Serverless containers FaaS
Use case Full VM control Container orchestration Web apps Stateless containers Event-driven functions
Scaling MIG autoscaling Pod/node autoscaling Automatic Automatic (to zero) Automatic (to zero)
Management User manages OS, runtime User manages containers Google manages runtime Google manages infra Google manages everything
Pricing Per VM (seconds) Per node or per pod Per instance hour Per request/instance Per invocation
GPU support Yes Yes No Yes (L4) No

Google Cloud Compute Services Cheat Sheet Questions

  1. A company needs to run a containerized application that automatically scales based on traffic and requires zero infrastructure management. Which service should they use?
    1. Compute Engine
    2. GKE Standard
    3. Cloud Run
    4. App Engine Flexible
    Show Answer

    Answer: c. Cloud Run – provides automatic scaling including scale-to-zero with no infrastructure management for containerized apps.

  2. A team wants to run Kubernetes workloads without managing node pools, patching, or capacity planning. Which GKE mode should they choose?
    1. GKE Standard
    2. GKE Autopilot
    3. GKE Enterprise
    4. GKE Sandbox
    Show Answer

    Answer: b. GKE Autopilot – fully managed mode where GKE handles all node management, patching, and capacity planning.

  3. Which Compute Engine VM type is recommended over Preemptible VMs and has no maximum runtime limit?
    1. Shielded VM
    2. Confidential VM
    3. Spot VM
    4. Sole-tenant VM
    Show Answer

    Answer: c. Spot VM – recommended replacement for Preemptible VMs with same pricing but no 24-hour time limit.

  4. What happened to Google Cloud Functions in August 2024?
    1. It was deprecated entirely
    2. It was renamed to Cloud Run functions
    3. It was merged into App Engine
    4. It moved to GKE
    Show Answer

    Answer: b. It was renamed to Cloud Run functions – Cloud Functions (2nd gen) is now Cloud Run functions, deployed as services on Cloud Run.

  5. An organization needs to deploy AI inference models on GKE with optimized routing. Which feature should they use?
    1. GKE Sandbox
    2. GKE Inference Gateway
    3. Cloud Run GPU
    4. Compute Engine A3
    Show Answer

    Answer: b. GKE Inference Gateway – provides optimized routing specifically for AI model inference workloads on GKE.

  6. Which storage option provides substantially higher IOPS and throughput than Persistent Disk with independently configurable performance?
    1. Local SSD
    2. Standard Persistent Disk
    3. Hyperdisk
    4. Filestore
    Show Answer

    Answer: c. Hyperdisk – next-generation block storage with independently configurable IOPS and throughput.

  7. A company wants to run serverless GPU workloads for AI inference without managing clusters. Which service is most appropriate?
    1. Compute Engine with GPU
    2. GKE with A3 nodes
    3. Cloud Run with GPU
    4. App Engine Flexible
    Show Answer

    Answer: c. Cloud Run with GPU – provides serverless GPU acceleration with NVIDIA L4 GPUs, no cluster management required.

  8. Which Compute Engine feature protects data in memory using hardware-based encryption?
    1. Shielded VM
    2. Confidential VM
    3. Sole-tenant node
    4. Live migration
    Show Answer

    Answer: b. Confidential VM – keeps data encrypted in memory during processing using AMD SEV, SEV-SNP, or Intel TDX.

Related Posts

Google Cloud Compute Engine – VM Instance Types

~ Last updated on : ~ jayendrapatil

Google Cloud Compute Engine

  • Compute Engine instance is a virtual machine (VM) hosted on Google’s infrastructure.
  • Compute Engine instances can run the public images for Linux and Windows Server that Google provides as well as private custom images created or imported from existing systems.
  • Docker containers can also be deployed, which are automatically launched on instances running the Container-Optimized OS public image.
  • Each instance belongs to a GCP project, and a project can have one or more instances. When you delete an instance, it is removed from the project.
  • For instance creation, the zone, operating system, and machine type (number of virtual CPUs and the amount of memory) need to be specified.
  • By default, each Compute Engine instance has a small boot persistent disk that contains the OS. Additional storage options can be attached.
  • Each network interface of a Compute Engine instance is associated with a subnet of a unique VPC network.
  • Regardless of the region where the VM instance is created, the default time for the VM instance is Coordinated Universal Time (UTC).
  • Compute Engine offers the best single instance compute availability SLA of any cloud provider: 99.95% availability for memory-optimized VMs and 99.9% for all other VM families.

Compute Engine Instance Lifecycle

Instance life cycle.

  • PROVISIONING. Resources are being allocated for the instance. The instance is not running yet.
  • STAGING. Resources have been acquired and the instance is being prepared for the first boot.
  • RUNNING. The instance is booting up or running. You should be able to ssh into the instance soon, but not immediately after it enters this state.
  • REPAIRING – The instance is being repaired because the instance encountered an internal error or the underlying machine is unavailable due to maintenance. During this time, the instance is unusable. If repair is successful, the instance returns to one of the above states.
  • STOPPING: The instance is being stopped because a user has made a request to stop the instance or there was a failure. This is a temporary status and the instance will move to TERMINATED.
  • TERMINATED. A user shut down the instance, or the instance encountered a failure. You can choose to restart the instance or delete it.
  • SUSPENDING The instance is being suspended due to a user action
  • SUSPENDED – Instance is suspended and can be resumed or deleted

GCP Compute Engine Instance Stopping vs Suspending vs Resetting

Compute Engine Machine Types

  • A machine type is a set of virtualized hardware resources available to a virtual machine (VM) instance, including the system memory size, virtual CPU (vCPU) count, and persistent disk limits.
  • Machine types are grouped and curated by families for different workloads.
  • Machine families are further classified by series, generation, and processor type.

Machine Families

  • General-purpose — best price-performance ratio for a variety of workloads (N4, N4A, N4D, N2, N2D, N1, C4, C4A, C4D, C3, C3D, E2, Tau T2D, Tau T2A)
  • Compute-optimized — highest performance per core for HPC and compute-intensive workloads (H4D, H3, C2, C2D)
  • Memory-optimized — ideal for memory-intensive workloads, with up to 32 TB of memory (X4, M4, M4N, M3, M2, M1)
  • Storage-optimized — best for workloads that are low in core usage and high in storage density (Z3)
  • Network-optimized — ideal for IO-intensive workloads with up to 400 Gbps internal bandwidth (M4N)
  • Accelerator-optimized — ideal for massively parallelized CUDA compute workloads such as ML/AI and HPC (A4X Max, A4X, A4, A3, A2, G4, G2)

4th Generation Machine Series (Latest – 2024-2025)

  • C4 — Intel Granite Rapids/Emerald Rapids with Titanium offload, up to 288 vCPUs, 2.2 TB DDR5 memory. Delivers up to 20% better price-performance for general-purpose workloads.
  • C4A — Google Axion (Arm Neoverse V2) processor with Titanium, up to 72 vCPUs, 576 GB DDR5 memory. Delivers up to 65% better price-performance and 60% better energy efficiency than comparable x86 instances.
  • C4D — AMD EPYC Turin with Titanium, up to 384 vCPUs, 3 TB DDR5 memory.
  • N4 — Intel Emerald Rapids with Titanium, up to 80 vCPUs, 640 GB DDR5 memory. Supports custom machine types.
  • N4A — Google Axion (Arm Neoverse N3) with Titanium, up to 64 vCPUs, 512 GB DDR5 memory. Most efficient and flexible Arm-based series.
  • N4D — AMD EPYC Turin with Titanium, up to 96 vCPUs, 768 GB DDR5 memory. Supports custom machine types and dynamic resource management.
  • X4 — Intel Sapphire Rapids bare metal, up to 1,920 vCPUs, 6-32 TB of memory.
  • M4 — Intel Emerald Rapids, up to 224 vCPUs with up to 26.5 GB memory per vCPU.
  • H4D — AMD EPYC Turin with Titanium and Cloud RDMA support, 192 vCPUs, 720 GB DDR5. Designed for HPC workloads.
  • A4 — 224 vCPUs with 8 NVIDIA B200 GPUs, up to 3,600 Gbps network bandwidth.
  • A4X — NVIDIA Grace CPUs with 4 NVIDIA B200 GPUs, up to 2,000 Gbps network bandwidth.
  • G4 — AMD EPYC Turin with NVIDIA RTX PRO 6000 GPUs, supports fractional GPUs (1/8, 1/4, 1/2), up to 400 Gbps networking.

Google Titanium

  • Titanium is Google Cloud’s custom-designed architecture that offloads networking and storage tasks to dedicated hardware.
  • Delivers more consistent and predictable performance by reserving the entire CPU exclusively for applications.
  • Foundation to all 3rd-generation and newer Compute Engine machine types (C3, C4, N4, H3, H4D, Z3, etc.).
  • Provides performance, reliability, and security improvements by freeing up the CPU from I/O processing.

GCP Compute Engine Machine Types

Compute Engine Storage

  • Compute Engine offers multiple storage options:
    • Persistent Disk (PD) — network-attached block storage (Standard PD, Balanced PD, SSD PD, Extreme PD)
    • Hyperdisk — next-generation block storage with independently configurable IOPS, throughput, and capacity
    • Local SSD / Titanium SSD — physically attached high-performance local storage
  • Hyperdisk (GA 2024+) is the recommended storage for newer machine series (C4, N4, C4A, etc.):
    • Hyperdisk Balanced — best combination of price and performance; also used as boot disk for newer machine types. Up to 160,000 IOPS and 2,400 MiB/s throughput per volume.
    • Hyperdisk Balanced High Availability — synchronous replication across two zones in a region.
    • Hyperdisk Extreme — highest IOPS for demanding database workloads.
    • Hyperdisk ML — optimized for ML model serving with high throughput.
    • Hyperdisk Throughput — optimized for high-throughput sequential workloads.
  • Hyperdisk Storage Pools allow pre-provisioning capacity, throughput, and IOPS that multiple disks can share, enabling deduplication and thin provisioning.

Refer blog post @ Compute Engine Storage Options

Compute Engine Guest Environment

  • A Guest environment is automatically installed on the VM instance when using Google-provided public images
  • Guest environment is a set of scripts, daemons, and binaries that read the content of the metadata server to make a VM run properly on CE
  • A metadata server is a communication channel for transferring information from a client to the guest operating system.
  • Guest environment can be manually installed on custom images

Compute Engine Instance Availability Policies

  • Compute Engine does regular maintenance of its infrastructure which entails hardware and software updates
  • Google might require to move the VM away from the host undergoing maintenance and Compute Engine automatically manages the scheduling behavior of these instances.
  • Compute Engine instance’s availability policy determines how it behaves when there is a maintenance event
    • Live migrate – move the VM instances to another host machine
    • Stop the instances
  • Instance’s availability policy can be changed by configuring the following two settings:
    • VM instance’s maintenance behavior onHostMaintenance, which determines whether the instance is live migrated MIGRATE (default) or stopped TERMINATE
    • Instance’s restart behavior automaticRestart which determines whether the instance automatically restarts (default) if it crashes or gets stopped

Compute Engine Live Migration

  • Live migration helps keep the VM instances running even when a host system event, such as a software or hardware update, occurs
  • Compute Engine live migrates the running instances to another host in the same zone instead of requiring the VMs to be rebooted
  • Live migration allows Google to perform maintenance to keep infrastructure protected and reliable without interrupting any of the VMs.
  • GCP provides a notification to the guest that migration is imminent, when a VM is scheduled to be live migrated
    • Regular infrastructure maintenance and upgrades.
    • Network and power grid maintenance in the data centers.
    • Failed hardware such as memory, CPU, network interface cards, disks, power, and so on. This is done on a best-effort basis; if hardware fails completely or otherwise prevents live migration, the VM crashes and restarts automatically and a hostError is logged.
    • Host OS and BIOS upgrades.
    • Security-related updates, with the need to respond quickly.
    • System configuration changes, including changing the size of the host root partition, for storage of the host image and packages.
  • Live migration does not change any attributes or properties of the VM including internal and external IP addresses, instance metadata, block storage data and volumes, OS and application state, network settings, network connections, and so on.
  • Compute Engine can also live migrate instances with Local SSD disks attached, moving the VMs along with their local SSD to a new machine in advance of any planned maintenance.
  • Instances with GPUs attached cannot be live migrated and must be set to stop and optionally restart. Compute Engine offers a 60-minute notice before a VM instance with a GPU attached is stopped.
  • Instances created with bare metal machine types cannot be live migrated.
  • Spot VMs cannot be configured for live migration.

Spot VMs

✅ Spot VMs are the latest and recommended version of preemptible VMs. Google recommends using Spot VMs instead of preemptible VMs for new workloads.

  • A Spot VM is an instance that can be created and run at a much lower price (60-91% discount) than standard on-demand instances.
  • Compute Engine might stop (preempt) Spot VMs if it requires access to those resources for other tasks.
  • Spot VMs are excess Compute Engine capacity, so their availability varies with usage.
  • Spot VMs are ideal for fault-tolerant, batch, and stateless workloads that can withstand possible interruptions.
  • Key advantages over legacy Preemptible VMs:
    • No 24-hour maximum runtime limit — Spot VMs can run indefinitely as long as capacity is available (unless you explicitly limit the runtime).
    • Same pricing as preemptible VMs.
    • Same preemption behavior and mechanisms.
  • Spot VM limitations:
    • Compute Engine might preempt Spot VMs at any time due to system events.
    • Are finite GCE resources, so they might not always be available.
    • Can’t live migrate to a regular VM instance, or be set to automatically restart when there is a maintenance event.
    • Are not covered by any Service Level Agreement (SLA).
    • GCP Free Tier credits for Compute Engine don’t apply to Spot VMs.
  • Preemption process:
    • Compute Engine sends a preemption notice to the instance in the form of an ACPI G2 Soft Off signal.
    • Shutdown script can be used to handle the preemption notice and complete cleanup actions before the instance stops.
    • If the instance does not stop after 30 seconds, Compute Engine sends an ACPI G3 Mechanical Off signal to the operating system.
    • Compute Engine transitions the instance to a TERMINATED state.
  • Managed Instance Groups (MIGs) support Spot VMs.

Preemptible VM Instances (Legacy)

⚠️ Note: Preemptible VMs are the legacy version of Spot VMs. Google recommends using Spot VMs for all new workloads. Preemptible VMs continue to be supported but have the additional limitation of a 24-hour maximum runtime.

  • A preemptible VM is an instance that can be created and run at a much lower price than normal instances.
  • Preemptible instance limitations (in addition to Spot VM limitations):
    • Always stops preemptible instances after they run for 24 hours (Spot VMs do NOT have this limit).

Flex-start VMs

  • Flex-start VMs (introduced 2024) provide on-demand pricing but with flexible start times.
  • Ideal for workloads that need guaranteed capacity but can tolerate a short delay in provisioning.
  • Supported in managed instance groups (MIGs) for batch and scale-out workloads.

Shielded VM

  • Shielded VM offers verifiable integrity of the Compute Engine VM instances, to confirm the instances haven’t been compromised by boot- or kernel-level malware or rootkits.
  • Shielded VM’s verifiable integrity is achieved through the use of Secure Boot, virtual trusted platform module (vTPM)-enabled Measured Boot, and integrity monitoring.

Confidential VMs

  • Confidential VMs are a type of Compute Engine virtual machine that use hardware-based memory encryption to help ensure that data and applications can’t be read or modified while in use.
  • Provides an additional layer of security for sensitive workloads through hardware-level isolation.
  • Supported technologies:
    • AMD SEV (Secure Encrypted Virtualization) — encrypts VM memory with a dedicated per-VM key. Supported on N2D, C2D, C3D, C4D, and G4 machine series.
    • AMD SEV-SNP — adds memory integrity protection and attestation. Supported on N2D machine series.
    • Intel TDX (Trust Domain Extensions) — creates isolated trust domains with hardware-based attestation. GA on C3 machine series (since September 2024) and A3 accelerator-optimized machines.
    • NVIDIA Confidential Computing — enables GPU memory encryption for AI workloads. Supported on A3 and G4 machine series.
  • No additional code changes required for applications running inside Confidential VMs.

Managing Access to the Instances

  • Linux instances:
    • Compute Engine uses key-based SSH authentication to establish connections to Linux virtual machine (VM) instances.
    • By default, local users with passwords aren’t configured on Linux VMs.
    • By default, Compute Engine uses custom project and/or instance metadata to configure SSH keys and to manage SSH access. If OS Login is used, metadata SSH keys are disabled.
    • Managing Instance Access Using OS Login,
      • allows associating SSH keys with the Google Account or Google Workspace account and manage admin or non-admin access to the instance through IAM roles.
      • connecting to the instances using the gcloud command-line tool or SSH from the console, Compute Engine can automatically generate SSH keys and apply them to the Google Account or Google Workspace account.
      • Supports two-factor authentication (2FA) for additional security.
      • Supports SSH certificates for enhanced key management.
      • Supports security keys (FIDO2) as SSH authentication factors.
    • Manage the SSH keys in the project or instance metadata
      • allows granting admin access to instances with metadata access that does not use OS Login.
      • connecting to the instances using the gcloud command-line tool or SSH from the console, Compute Engine can automatically generate SSH keys and apply them to project metadata.
      • Project-wide public SSH keys
        • give users general access to a Linux instance.
        • give users access to all of the Linux instances in a project that allows project-wide public SSH keys
      • Instance metadata
        • If an instance blocks project-wide public SSH keys, a user can’t use the project-wide public SSH key to connect to the instance unless the same public SSH key is also added to instance metadata
    • Identity-Aware Proxy (IAP) TCP forwarding — allows SSH connections to VMs that don’t have external IP addresses through IAP tunnels, without needing a VPN or bastion host.
  • On Windows Server instances:
    • Create a password for a Windows Server instance

Compute Engine Images

  • Compute Engine Images help provide operation system images to create boot disks and application images with preinstalled, configured software
  • Main purpose is to create new instances or configure instance templates
  • Images can be regional or multi-regional and can be shared and accessed across projects and organizations
  • Compute Engine instances can run the public images for Linux and Windows Server that Google provides as well as private custom images created or imported from existing systems.
    • Public images
      • provided and maintained by Google, open-source communities, and third-party vendors.
      • All Google Cloud projects have access to these images and can use them to create instances.
    • Custom images
      • are available only to the Cloud project.
      • Custom images can be created from boot disks and other images.
  • Image families
    • help image versioning
    • helps to manage images in the project by grouping related images together, so that they can roll forward and roll back between specific image versions
    • always points to newest latest non-deprecated version
  • Linux images can be exported as a tar.gz file to Cloud Storage
  • Google Cloud supports images with Container-Optimized OS, an OS image for the CE instances optimized for running Docker containers

Instance Templates

  • Instance template is a resource used to create VM instances and managed instance groups (MIGs) with identical configuration
  • Instance templates define the machine type, boot disk image or container image, labels, and other instance properties
  • Instance templates are a convenient way to save a VM instance’s configuration to create VMs or groups of VMs later
  • Google Cloud has two Instance Template resources:
    • Global instance templates — can be reused in different regions. This is a global resource that is not bound to a zone or a region.
    • Regional instance templates — can be used in a specified region only. Useful for reducing cross-region dependency or achieving data residency requirements.
  • If some zonal resources are specified in an instance template for e.g. disks, which restricts the template to the zone where that resource resides.
  • Labels defined within an instance template are applied to all instances that are created from that instance template. The labels do not apply to the instance template itself.
  • Existing instance template cannot be updated or changed after it’s created

Instance Groups

Refer blog post @ Compute Engine Instance Groups

Snapshots

Refer blog post @ Compute Engine Snapshots

Startup & Shutdown Scripts

  • Startup scripts
    • can be added and executed on the VM instances to perform automated tasks every time the instance boots up.
    • can perform actions such as installing software, turning on services, performing updates, and any other tasks defined in the script.
  • Shutdown scripts
    • execute commands right before a VM instance is stopped or restarted.
    • can be useful allowing instances time to clean up or perform tasks, such as exporting logs, or syncing with other systems.
    • are executed only on a best-effort basis
    • have a limited amount of time to finish running before the instance stops i.e. 90 secs for on-demand and 30 secs for Spot/Preemptible instances
  • Startup & Shutdown scripts are executed using root user
  • Startup & Shutdown scripts can be provided to the VM instance using
    • local file, supported by gcloud only
    • inline using startup-script or shutdown-script option
    • Cloud Storage URL and startup-script-url or shutdown-script-url as the metadata key, provided the instance has access to the script
  • Graceful Shutdown (2025+) — allows configuring extended shutdown time for VMs in a MIG, giving workloads more time to complete in-flight requests during scale-in or updates.

Machine Image

  • A machine image is a Compute Engine resource that stores all the configuration, metadata, permissions, and data from one or more disks required to create a virtual machine (VM) instance.
  • Machine images can be used for VM backup, cloning, and replication across projects.

Sole Tenant Nodes

  • Sole-tenancy provides dedicated hosting only for the project’s VM and provides an added layer of hardware isolation
  • Sole-tenant nodes ensure that the VMs do not share host hardware with VMs from other projects
  • Each sole-tenant node maintains a one-to-one mapping to the physical server that is backing the node
  • Project has exclusive access to a sole-tenant node, which is a physical CE server and can be used to keep the VMs physically separated from VMs in other projects or to group the VMs together on the same host hardware
  • Sole-tenant nodes can help meet dedicated hardware requirements for bring your own license (BYOL) scenarios that require per-core or per-processor licenses

Projects on a multi-tenant host versus a sole-tenant node.

Bare Metal Instances

  • Bare metal instances (2024+) run directly on physical servers without a hypervisor layer.
  • Available in C4, C4A, C4D, Z3, and X4 machine series.
  • Ideal for workloads that require direct hardware access, specialized hypervisors, or specific compliance requirements.
  • Can attach disks and use VPC networking just like regular VM instances.
  • Cannot be live migrated during host maintenance events.

Preventing Accidental VM Deletion

  • Accidental VM deletion can be prevented by setting the property deletionProtection on an instance resource esp. for VMs running critical workloads and need to be protected
  • Deletion request fails if a user attempts to delete a VM instance for which the deletionProtection flag is set
  • Only a user granted with compute.instances.create permission can reset the flag to allow the resource to be deleted.
  • Deletion prevention does not prevent the following actions:
    • Terminating an instance from within the VM (such as running the shutdown command)
    • Stopping an instance
    • Resetting an instance
    • Suspending an instance
    • Instances being removed due to fraud and abuse after being detected by Google
    • Instances being removed due to project termination
  • Deletion protection can be applied to both regular and Spot VMs.
  • Deletion protection cannot be applied to VMs that are part of a managed instance group but can be applied to instances that are part of unmanaged instance groups.
  • Deletion prevention cannot be specified in instance templates.

Cost Optimization

  • Committed Use Discounts (CUDs) — discounts for committing to use a specific amount of resources for 1 or 3 years.
    • Resource-based CUDs — commit to a specific amount of vCPUs and memory in a region. 1-year: ~20% off, 3-year: ~45% off.
    • Compute Flexible CUDs (Flex CUDs) — spend-based commitments that apply across Compute Engine, GKE, and Cloud Run. 1-year: 28% off, 3-year: 46% off. No need to specify machine type or region.
  • Sustained Use Discounts (SUDs) — automatic discounts for running instances for a significant portion of the month. Available for N2, N2D, N1, C2, M1, M2 series. Not available for newer 4th-gen series (C4, N4, etc.) which are covered by Flex CUDs instead.
  • Spot VMs — up to 60-91% discount for interruptible workloads.
  • Rightsizing Recommendations — Compute Engine provides machine type recommendations based on workload utilization to help optimize costs.

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. Your company hosts multiple applications on Compute Engine instances. They want the instances to be resilient to any Host maintenance activities performed on the instance. How would you configure the instances?
    1. Set automaticRestart availability policy to true
    2. Set automaticRestart availability policy to false
    3. Set onHostMaintenance availability policy to migrate instances
    4. Set onHostMaintenance availability policy to terminate instances
  2. A company needs to run a fault-tolerant batch processing workload at the lowest possible cost. The workload can tolerate interruptions and does not have a fixed completion deadline. Which VM provisioning model should they use?
    1. Standard on-demand VMs
    2. Preemptible VMs
    3. Spot VMs
    4. Sole-tenant VMs
  3. What is the key advantage of Spot VMs over legacy Preemptible VMs in Google Cloud?
    1. Spot VMs are cheaper than Preemptible VMs
    2. Spot VMs can be live migrated during maintenance
    3. Spot VMs have no 24-hour maximum runtime limit
    4. Spot VMs are covered by a Service Level Agreement
  4. Your organization requires that VM memory is encrypted in use to protect sensitive data processing. Which Compute Engine feature should you enable?
    1. Shielded VM
    2. Confidential VM
    3. Customer-Managed Encryption Keys (CMEK)
    4. Customer-Supplied Encryption Keys (CSEK)
  5. Which 4th-generation machine series is powered by Google’s custom Axion Arm processor and offers up to 65% better price-performance than comparable x86 instances?
    1. C4
    2. C4A
    3. N4
    4. C4D
  6. A team needs a Compute Engine machine type that allows independently configuring vCPUs and memory for their specific workload needs. Which machine series supports custom machine types? (Choose TWO)
    1. C4
    2. N4
    3. N4D
    4. C4A
    5. H4D
  7. What is Google Titanium in the context of Compute Engine?
    1. A type of SSD storage
    2. A machine type family
    3. A custom-designed architecture that offloads networking and storage tasks to dedicated hardware
    4. A security feature for VM encryption
  8. Which storage type is recommended as the boot disk for newer Compute Engine machine series like C4 and N4?
    1. Standard Persistent Disk
    2. SSD Persistent Disk
    3. Hyperdisk Balanced
    4. Local SSD

References

GCE Instance Groups – MIG, Autoscaling & Spot VMs

~ Last updated on : ~ jayendrapatil

Google Cloud – Compute Engine Instance Groups

  • An instance group is a collection of virtual machine (VM) instances that can be managed as a single entity.
  • Compute Engine offers two kinds of VM instance groups
    • Managed instance groups (MIGs)
      • allows app creation with multiple identical VMs.
      • workloads can be made scalable and highly available by taking advantage of automated MIG services, including: autoscaling, autohealing, regional (multiple zones) deployment, and automatic updating
    • Unmanaged instance groups
      • allows load balance across a fleet of self managed nonidentical VMs

Managed instance groups (MIGs)

  • A MIG creates each of its managed instances based on the instance template and specified optional stateful configuration
  • Managed instance group (MIG) is ideal for scenarios
    • Stateless serving workloads, such as a website frontend
    • Stateless batch, high-performance, or high-throughput compute workloads, such as image processing from a queue
    • Stateful applications, such as databases, legacy applications, and long-running batch computations with check pointing
Use a managed instance group to build highly available deployments for stateless serving, stateful applications, or batch workloads.

Health Checking

  • Managed instance group health checks proactively signal to delete and recreate instances that become UNHEALTHY.
  • Load balancing health checks help direct traffic away from non-responsive instances and toward healthy instances; these health checks do not cause Compute Engine to recreate instances.
  • Health checks used to monitor MIGs are similar to the health checks used for load balancing, with some differences in behavior.

High Availability & Autohealing

  • Managed instance groups maintain high availability of the applications by proactively maintaining the number of instances and keeping the instances available, which means in RUNNING state.
  • Application-based autohealing improves application availability by relying on a health checking signal that detects application-specific issues such as freezing, crashing, or overloading.
  • If a health check determines that an application has failed on a VM, the MIG automatically recreates that VM instance.
  • A MIG automatically recreates an instance that is not RUNNING. However, relying only on VM state may not be sufficient and should include check for application freezes, crashes, or runs out of memory.
  • MIGs support repair in alternate zone, allowing a VM to be recreated in a different zone if the original zone is experiencing issues.

Regional or Zonal groups

  • Zonal MIG,
    • deploys instances to a single zone.
  • Regional MIG
    • deploys instances to multiple zones across the same region
    • provides higher availability by spreading application load across multiple zones,
    • protects the workload against zonal failure
    • offer more capacity, with a maximum of 2,000 instances per regional group.

Target Distribution Shape (Regional MIGs)

  • Regional MIGs support configurable target distribution shapes to control how instances are distributed across zones:
    • EVEN (default) – maintains the same number of VMs across zones (differs by at most 1). Recommended for highly available serving workloads.
    • BALANCED – prioritizes creating VMs where resources are available while distributing as evenly as possible. Recommended for highly available serving or batch workloads.
    • ANY – picks zones to maximize resource acquisition and utilization of unused reservations. Recommended for batch workloads.
    • ANY_SINGLE_ZONE – creates all VMs within a single zone chosen based on hardware support, reservations, and resource availability. Recommended with compact placement policies for workloads requiring extensive VM-to-VM communication.
  • Proactive instance redistribution (enabled by default with EVEN shape) automatically rebalances VMs across zones when capacity becomes available.

Load Balancing

  • MIGs work with load balancing services to distribute traffic across all of the instances in the group.
  • Google Cloud load balancing can use instance groups to serve traffic by adding instance groups to a target pool or to a backend service.

Scalability & Autoscaling

  • MIGs provides scalability and supports autoscaling that dynamically adds or removes instances in response to increases or decreases in load.
  • Autoscaling policy determines how the group would scale which includes scaling based on CPU utilization, Cloud Monitoring metrics, load balancing capacity, or, for zonal MIGs, by using a queue-based workload like Pub/Sub
  • Autoscaler continuously collects usage information based on the selected utilization metric, compares actual utilization to the desired target utilization, and uses this information to determine whether the group needs to remove instances (scale in) or add instances (scale out).
  • Cool down period
    • is known as the application initialization period
  • Stabilization period
    • For scaling in, the autoscaler calculates the group’s recommended target size based on peak load over the last 10 minutes which is called the Stabilization period
    • Using the stabilization period, the autoscaler ensures that the recommended size for the managed instance group is always sufficient to serve the peak load observed during the previous 10 minutes.
  • Predictive autoscaling
    • helps to optimize your MIG for availability,
    • the autoscaler forecasts future load based on historical data and scales out a MIG in advance of predicted load, so that new instances are ready to serve when the load arrives.
  • Schedule-based autoscaling
    • allows setting minimum required capacity for recurring time windows (e.g., business hours, weekends).
    • supports cron-like schedules to proactively scale up before anticipated load increases.
    • can be combined with other autoscaling signals (CPU, load balancing, monitoring metrics) — the autoscaler uses the signal that results in the largest number of VMs.
  • Scale-in controls
    • allow limiting the rate at which autoscaler removes VMs to prevent sudden capacity drops.
    • configured as a maximum number of VMs or a percentage of group size that can be removed within a specified time window.
    • helps prevent overly aggressive scale-in during temporary load drops.
  • Autoscaler mode
    • ON – autoscaler scales both out and in based on recommended size.
    • ONLY_SCALE_OUT – autoscaler only increases group size, never reduces it automatically.

Automatic Updating

  • MIG automatic updater supports a flexible range of rollout scenarios to deploy new versions of the software to instances in the MIG such as rolling updates and canary updates.
  • Speed and scope of deployment can be controlled as well as the level of disruption to the service.
  • All-instances configuration (AIC) allows overriding instance template properties (like metadata or labels) across all VMs without changing the template itself.
  • One-click OS image upgrades simplify the process of updating VM images across the group.

Stateful Workloads Support

  • MIGs can be used for building highly available deployments and automating operation of applications with stateful data or configuration, such as databases, DNS servers, legacy monolith applications, or long-running batch computations with checkpointing.
  • Uptime and resiliency of such applications can be improved with autohealing, controlled updates, and multi-zone deployments, while preserving each instance’s unique state, including customizable instance name, persistent disks, and metadata.
  • Stateful MIGs preserve each instance’s unique state (instance name, attached persistent disks, metadata, and IP addresses) on machine restart, recreation, auto-healing, and update events.
  • Stateful IP addresses – allows preserving internal and/or external IP addresses across VM lifecycle events.

Spot VM Instance Groups

  • MIG supports Spot VMs (the recommended replacement for preemptible VMs), which provide significant discounts of up to 60-91% off on-demand pricing.
  • Unlike legacy preemptible VMs, Spot VMs have no maximum 24-hour runtime limit unless specifically configured.
  • Spot VMs can be preempted (stopped or deleted) at any time when Compute Engine needs the resources, but there is no fixed expiration time.
  • When Spot VMs in a MIG are preempted, the group repeatedly tries to recreate those VMs using the specified instance template when resources become available.
  • When using instance flexibility (multiple machine types in a MIG), the MIG automatically selects machine types with the lowest observed preemption rates.
  • Termination action can be set to STOP (default) or DELETE for each Spot VM.
📝 Note: Preemptible VMs are still supported but Google recommends using Spot VMs instead. Spot VMs are the latest version of preemptible VMs with no 24-hour maximum runtime. Legacy preemptible VMs may still appear in certification exams.

Instance Flexibility

  • Instance flexibility allows specifying multiple machine types suitable for a workload in a single MIG.
  • Compute Engine automatically selects and provisions VMs using any of the specified machine types based on current capacity and quota availability.
  • Helps improve the likelihood of getting resources, especially for Spot VMs or specialized hardware.
  • For Spot VMs, the MIG automatically selects machine types with the lowest observed preemption rates to minimize disruption.

Standby Pool (Suspended and Stopped VMs)

  • MIGs support a standby pool that allows VMs to be suspended or stopped while remaining part of the group.
  • Suspended/stopped VMs are pre-initialized and can be quickly resumed during scale-out, reducing cold-start latency.
  • Helps reduce costs when pausing applications during off-peak hours while maintaining quick scale-out capability.
  • VMs can be manually suspended or stopped, or automated as part of MIG lifecycle policies.

Resize Requests

  • Resize requests provide all-or-nothing capacity provisioning for MIGs, particularly useful for GPU workloads.
  • Ensures that either all requested VMs are created successfully or none are, preventing partial deployments.
  • Useful for ML/AI training workloads that require a specific number of accelerator VMs to start together.

Containers

  • MIG supports the deployment of containers to container-optimized OS that includes docker, if the instance template used specifies a container image.

Network and Subnet

  • Instance template, used with MIG, defines the VPC network and subnet that member instances use.
  • For auto mode VPC networks, the subnet can be omitted ; this instructs GCP to select the automatically-created subnet in the region specified in the template.
  • If VPC network is omitted, GCP attempts to use the VPC network named default.

Unmanaged instance groups

  • Unmanaged instance groups can contain heterogeneous instances that can be arbitrarily added and removed from the group.
  • Unmanaged instance groups do not offer autoscaling, autohealing, rolling update support, multi-zone support, or the use of instance templates and are not a good fit for deploying highly available and scalable workloads.
  • Use unmanaged instance groups, if load balancing needs to be added to groups of heterogeneous instances, or needs self managed instances

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. Your company’s test suite is a custom C++ application that runs tests throughout each day on Linux virtual machines. The full
    test suite takes several hours to complete, running on a limited number of on-premises servers reserved for testing. Your company
    wants to move the testing infrastructure to the cloud, to reduce the amount of time it takes to fully test a change to the system,
    while changing the tests as little as possible. Which cloud infrastructure should you recommend?

    1. Google Compute Engine unmanaged instance groups and Network Load Balancer.
    2. Google Compute Engine managed instance groups with auto-scaling.
    3. Google Cloud Dataproc to run Apache Hadoop jobs to process each test.
    4. Google App Engine with Google Stackdriver for logging.
  2. Your company has a set of compute engine instances that would be hosting production-based applications. These applications
    would be running 24×7 throughout the year. You need to implement the cost-effective, scalable and high availability solution even
    if a zone fails. How would you design the solution?

    1. Use Managed instance groups with Spot VMs across multiple zones
    2. Use Managed instance groups across multiple zones
    3. Use managed instance groups with instances in a single zone
    4. Use Unmanaged instance groups across multiple zones
  3. A company runs a batch processing workload using a MIG. The workload is fault-tolerant and can withstand VM preemption. They want to minimize costs. Which configuration should they use?
    1. Regional MIG with EVEN distribution and standard VMs
    2. Zonal MIG with standard VMs and autoscaling
    3. Regional MIG with ANY distribution shape and Spot VMs
    4. Regional MIG with BALANCED distribution and preemptible VMs
  4. You are designing a highly available web application that needs to survive a zone failure without degraded performance. The application serves traffic across multiple zones. Which MIG configuration is most appropriate?
    1. Regional MIG with ANY_SINGLE_ZONE target distribution shape
    2. Regional MIG with EVEN target distribution shape and overprovisioned capacity
    3. Zonal MIG with autoscaling enabled
    4. Regional MIG with ANY target distribution shape
  5. Your team wants to ensure that the autoscaler does not aggressively remove VMs when there is a temporary drop in traffic, to avoid affecting long-running user sessions. What should you configure?
    1. Increase the stabilization period to 30 minutes
    2. Set the autoscaler mode to ONLY_SCALE_OUT
    3. Configure scale-in controls to limit the rate of VM removal
    4. Use predictive autoscaling with schedule-based scaling
  6. A company needs to run a large ML training job that requires exactly 8 GPU VMs to start simultaneously. They cannot proceed with partial provisioning. Which MIG feature should they use?
    1. Autoscaling with minimum instances set to 8
    2. Schedule-based autoscaling
    3. Resize requests for all-or-nothing provisioning
    4. Instance flexibility with multiple machine types