App Engine

App Engine enables you to build and host applications on the same systems that power Google applications. App Engine offers fast development and deployment; simple administration, with no need to worry about hardware, patches or backups; and effortless scalability.

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 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 App Engine – PaaS & Serverless Apps

~ Last updated on : ~ jayendrapatil

⚠️ Important: Google Recommends Cloud Run for New Projects

As of 2025, Google officially recommends Cloud Run over App Engine for new projects. Cloud Run offers greater flexibility, container support, GPU access, multi-region load balancing, and lower pricing for idle instances. App Engine remains fully supported for existing applications, but Google has established an App Engine Migration Center to help customers transition to Cloud Run.

Google Cloud App Engine

  • App Engine helps build highly scalable applications on a fully managed serverless platform
  • App Engine provides PaaS and helps build and deploy apps quickly using popular languages or bring your own language runtimes and frameworks.
  • App Engine allows to scale the applications from zero to planet scale without having to manage infrastructure
  • 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 is well suited to applications that are designed using a microservice architecture
  • App Engine creates a default bucket in Cloud Storage for each app creation
  • App Engine supports two generations of runtimes — first-generation (legacy bundled services) and second-generation (standard Cloud Client Libraries)

App Engine Environments

App Engine provides two environments:

  • Standard Environment — runs in a secure sandbox, supports specific language runtimes, scale-to-zero capable, faster instance startup
  • Flexible Environment — runs in Docker containers on Compute Engine VMs, supports any language via custom runtimes, minimum 1 instance always running

Refer blog post Standard vs Flexible Environment

Supported Runtimes (2025-2026)

  • App Engine follows a runtime lifecycle with stages: General Availability → End of Support → Deprecated → Decommissioned
  • Current Standard Environment Runtimes:
    • Java: Java 25 (preview), Java 21, Java 17
    • Python: Python 3.14, 3.13, 3.12, 3.11, 3.10
    • Node.js: Node.js 24, 22, 20
    • Go: Go 1.26, 1.25, 1.24, 1.23, 1.22
    • PHP: PHP 8.5, 8.4, 8.3, 8.2
    • Ruby: Ruby 4.0, 3.4, 3.3, 3.2
  • Deprecated Runtimes (Jan 31, 2026): Python 2.7, Java 8, Go 1.11, PHP 5.5 — these first-generation runtimes are deprecated and will be decommissioned on January 31, 2027
  • First-generation runtimes with legacy bundled services (Memcache, Task Queues, Users API) should be migrated to second-generation runtimes using Cloud Client Libraries

App Engine Scaling

  • App Engine can automatically create and shut down instances as traffic fluctuates, or a number of instances can be specified to run regardless of the amount of traffic
  • App Engine supports the following scaling types, which controls how and when instances are created:
    • Basic (Standard Only)
      • creates instances when the application receives requests.
      • each instance will be shut down when the application becomes idle.
      • is ideal for work that is intermittent or driven by user activity.
    • Automatic
      • creates instances based on request rate, response latencies, and other application metrics.
      • thresholds can be specified for each of these metrics, as well as a minimum number instances to keep running at all times.
      • supports configuring target_cpu_utilization, target_throughput_utilization, min_instances, max_instances, min_pending_latency, and max_pending_latency
    • Manual
      • specifies the number of instances that continuously run regardless of the load level.
      • allows tasks such as complex initializations and applications that rely on the state of the memory over time.

Managing Traffic

App engine allows traffic management to an application version by migrating or splitting traffic.

Traffic Migration

  • Traffic migration smoothly switches request routing
  • Gradually moves traffic from the versions currently receiving traffic to one or more specified versions
  • Standard environment allows you to choose to route requests to the target version, either immediately or gradually.
  • Flexible environment only allows immediate traffic migration

Traffic Splitting

  • Traffic splitting distributes a percentage of traffic to versions of the application.
  • Allows canary deployments or conduct A/B testing between the versions and provides control over the pace when rolling out features
  • Traffic can be split to move 100% of traffic to a single version or to route percentages of traffic to multiple versions.
  • Traffic splitting is applied to URLs that do not explicitly target a version.
  • Traffic split is supported by using either an IP address or HTTP cookie.
  • Default behaviour for splitting traffic is to do it by IP.
  • Setting up IP address traffic split is easier, but a cookie split is more precise
  • For traffic splitting, execute gcloud app deploy --no-promote to make a new version of the application available and then run gcloud app services set-traffic to start sending the new version traffic. Use --splits flag with two versions and weight

App Engine Networking

  • Ingress Settings — control where incoming traffic can originate: all traffic, internal only, or internal + Cloud Load Balancing
  • VPC Connectivity — App Engine standard supports connecting to a VPC using Serverless VPC Access connectors or Direct VPC Egress (preview)
  • Custom Domains — supported via App Engine settings or by using Cloud Load Balancing for advanced routing (recommended for production)
  • Firewall Rules — allow or deny traffic from specified IP ranges
  • Identity-Aware Proxy (IAP) — supported for controlling access to App Engine applications

Migration to Cloud Run

  • Google recommends evaluating Cloud Run for new projects as it provides more flexibility, lower pricing, and advanced features like GPU support
  • The App Engine Migration Center provides comprehensive guidance for transitioning
  • Key advantages of Cloud Run over App Engine:
    • Container-based deployments (any language, any framework)
    • GPU support for AI/ML workloads
    • Multi-region load balancing
    • Sidecar containers
    • Lower cost for idle minimum instances
    • Committed use discounts (CUDs)
    • Services in the same project can be deployed to different regions
    • Cloud Run Invoker IAM role for fine-grained access control
  • Migration paths:
    • Standard environment → Deploy directly to Cloud Run from source
    • Flexible environment → Containerize and deploy to Cloud Run
    • Apps using legacy bundled services should first migrate off those services

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 website hosted on App Engine standard environment. You want 1% of your users to see a new test version of the website. You want to minimize complexity. What should you do?
    1. Deploy the new version in the same application and use the –migrate option.
    2. Deploy the new version in the same application and use the –splits option to give a weight of 99 to the current version and a weight of 1 to the new version.
    3. Create a new App Engine application in the same project. Deploy the new version in that application. Use the App Engine library to proxy 1% of the requests to the new version.
    4. Create a new App Engine application in the same project. Deploy the new version in that application. Configure your network load balancer to send 1% of the traffic to that new application.
  2. You have created an App engine application in the us-central region. However, you found out the network team has configured all the VPN connections in the asia-east2 region, which are not possible to move. How can you change the location efficiently?
    1. Change the region in app.yaml and redeploy
    2. From App Engine console, change the region of the application
    3. Change the region in application.xml within the application and redeploy
    4. Create a new project in the asia-east2 region and create app engine in the project
  3. Your team is deploying a new Python application. You need a serverless platform that supports scale-to-zero, container deployments, and multi-region load balancing. Which Google Cloud service should you use?
    1. App Engine Standard Environment
    2. App Engine Flexible Environment
    3. Cloud Run
    4. Google Kubernetes Engine
  4. You are running a legacy Python 2.7 application on App Engine first-generation runtime. The runtime is deprecated as of January 31, 2026. What is the recommended migration approach?
    1. Continue running on the deprecated runtime as it will be supported indefinitely
    2. Migrate to App Engine flexible environment with Python 2.7
    3. Migrate the application to a second-generation runtime (Python 3.x) and replace legacy bundled services with Cloud Client Libraries, or migrate to Cloud Run
    4. Move the application to Compute Engine with Python 2.7
  5. Your application on App Engine needs to perform background processing tasks between requests. Which configuration should you use?
    1. Automatic scaling with default settings
    2. Basic scaling with idle_timeout set to maximum
    3. Manual scaling, which allows continuous CPU access between requests
    4. Deploy to App Engine flexible environment only
  6. You want to deploy an application that requires services in multiple regions within the same project. Which platform should you choose?
    1. App Engine Standard — deploy services to different regions in the same project
    2. App Engine Flexible — configure multi-region deployment in app.yaml
    3. Cloud Run — services in the same project can be deployed to different regions
    4. App Engine — use traffic splitting across regions

App Engine Standard vs Flexible – Differences & When to Use

~ Last updated on : ~ jayendrapatil

Google Cloud – App Engine Standard vs Flexible Environment

📢 Important Updates (2024-2026)

  • Legacy Runtimes Deprecated (Jan 31, 2026): Python 2.7, Java 8, Go 1.11, and PHP 5.5 first-generation runtimes have been deprecated. Existing apps continue to run but new deployments are blocked.
  • Second-Generation Runtimes: Standard environment now uses gVisor-based sandboxing with significantly fewer restrictions than the first-generation sandbox.
  • Cloud Run Recommended: Google recommends Cloud Run as the preferred serverless platform for new projects, combining the best of both App Engine environments.
  • VPC Connectivity: Standard environment now supports VPC access via Direct VPC egress and Serverless VPC connectors.

Application Execution

  • Standard environment
    • Application instances run in a sandboxed environment using second-generation runtimes (gVisor-based containers) for supported languages: Go, Java, Node.js, PHP, Python, and Ruby.
    • Second-generation runtimes (current) provide significantly relaxed restrictions compared to the original sandbox:
      • Can write to the /tmp directory (in-memory filesystem)
      • Can use any language-native libraries and system calls supported by gVisor
      • Supports network access including VPC connectivity
      • Background threads supported within request lifecycle
    • First-generation sandbox (deprecated Jan 2026) had strict restrictions:
      • Only allowed a limited set of binary libraries
      • App could not write to disk
      • Limited CPU and memory options
      • Did not support SSH debugging, background processes, or Cloud VPN
    • Supported Languages: Go (up to 1.26), Java (up to 25), Node.js (up to 24), PHP (up to 8.5), Python (up to 3.14), Ruby (up to 4.0)
  • Flexible environment
    • Application instances run within Docker containers on Compute Engine virtual machines (VM).
    • Supports custom runtimes or source code written in any programming language via Docker containers.
    • Allows selection of any Compute Engine machine type for instances, providing access to more memory and CPU (up to 80 vCPU and 6.5GB per vCPU).
    • Supports SSH debugging into instances.

Accessing External Services

  • Standard environment
    • Second-generation runtimes: Use Google Cloud Client Libraries (recommended) for accessing services like Firestore, Cloud Storage, etc. These libraries are portable across all Google Cloud platforms.
    • First-generation runtimes: Used legacy bundled services (google.appengine APIs) – these are still available on second-gen runtimes for Java, Python, Go, and PHP for backward compatibility but are not recommended for new apps.
  • Flexible environment
    • Legacy google.appengine APIs are not available.
    • Uses Google Cloud Client Libraries, making the application more portable.

Scaling

  • Standard Environment
    • Rapid scaling with scale-to-zero capability — can scale from zero instances up to thousands very quickly.
    • Uses a custom-designed autoscaling algorithm.
    • Supports three scaling types: automatic, basic, and manual scaling.
    • Configurable: max/min instances, target CPU utilization, target throughput utilization, max concurrent requests, and pending latency.
  • Flexible Environment
    • Must have at least one instance running for each active version (cannot scale to zero).
    • Uses the Compute Engine Autoscaler.
    • Can take longer to scale up in response to traffic compared to Standard.
    • Supports automatic and manual scaling only.

Health Checks

  • Standard environment
    • Performs automatic readiness and liveness checks on instances.
    • If an instance consistently fails checks, App Engine terminates and replaces it with a new instance.
  • Flexible environment
    • Instances are health-checked using configurable health check endpoints.
    • Health check results are used by the load balancer to determine whether to send traffic to an instance and whether it should be autohealed.

Networking & Connectivity

  • Standard environment
    • VPC connectivity supported via Direct VPC egress (Preview) or Serverless VPC Access connectors.
    • Supports Shared VPC for cross-project networking.
    • Direct VPC egress supports: network tags, Public NAT, dual-stack subnets.
    • Supports configurable ingress settings (internal-only, internal-and-Cloud-Load-Balancing, all traffic).
    • App Engine firewall rules available for access control.
  • Flexible environment
    • Instances run on Compute Engine VMs within the project’s VPC network directly.
    • Full network access including SSH and Cloud VPN support.
    • Configurable ingress settings and firewall rules available.

Traffic Migration

  • Standard environment
    • Allows routing requests to the target version either immediately or gradually (traffic splitting).
    • Supports splitting traffic by IP address, cookie, or random.
  • Flexible environment
    • Supports both immediate and gradual traffic migration.
    • Supports traffic splitting by IP address or cookie.

Single Zone Failures

  • Standard environment
    • Applications are single-zoned; all instances live in a single availability zone.
    • In the event of a zone failure, the application starts new instances in a different zone in the same region and the load balancer routes traffic to the new instances.
    • Latency spike can be observed due to loading requests and Memcache flush.
  • Flexible environment
    • Applications use Regional Managed Instance Groups with instances distributed among multiple availability zones within a region.
    • In the event of a single zone failure, the load balancer stops routing traffic to that zone.
    • Provides higher availability compared to Standard environment.

Deployment

  • Standard Environment
    • Deployments are generally faster — instance startup time is in seconds for auto-scaling.
    • Deploys from source code only (no container image support).
    • Uses app.yaml for all configuration.
  • Flexible Environment
    • Instance startup time in minutes (not seconds).
    • Deployment time is longer due to Docker image building.
    • Supports custom runtime Docker containers.
    • Uses app.yaml for configuration.

Compute Resources

  • Standard Environment
    • Predefined instance classes: F1 (384MB/600MHz), F2 (768MB/1.2GHz), F4 (1.5GB/2.4GHz), F4_1G (3GB/2.4GHz) for automatic scaling.
    • B1, B2, B4, B4_1G, B8 (up to 3GB/4.8GHz) for basic and manual scaling.
    • No GPU support.
  • Flexible Environment
    • Any Compute Engine machine type — up to 80 vCPU and 6.5GB RAM per vCPU.
    • Much greater resource flexibility.
    • No GPU support (use Cloud Run or Compute Engine for GPU workloads).

Pricing

  • Standard Environment
    • Billed per instance-hour based on instance class.
    • Includes a generous free tier (28 instance-hours/day for F1, 8 instance-hours/day for B1).
    • No per-request fees.
    • No committed use discounts (CUDs) available.
  • Flexible Environment
    • Billed based on vCPU, memory, and persistent disk resources of the underlying Compute Engine VMs.
    • No free tier.
    • Minimum one instance always running (cannot scale to zero).

Cloud Run — The Recommended Alternative

Cloud Run is the latest evolution of Google Cloud Serverless and is officially recommended by Google for new projects. It combines the best features of both App Engine environments:

  • Scale-to-zero like Standard environment
  • Container flexibility like Flexible environment (any language, any library)
  • GPU support — one GPU per instance configurable
  • Sidecar containers — run multiple containers per service
  • Volume mounts — mount Cloud Storage buckets directly
  • Multi-region load balancing — deploy services across regions
  • Committed Use Discounts (CUDs) available
  • Up to 8 vCPU and 32GB memory per instance
  • IAM-based access control with Cloud Run Invoker role
  • Configurable health checks — startup and liveness probes
  • Direct VPC egress (GA) with full VPC Flow Logs support

Google provides a comprehensive migration guide from App Engine Standard to Cloud Run and from Flexible to Cloud Run.

Summary Comparison Table

Feature Standard Environment Flexible Environment
Instance startup Seconds Minutes
Scale to zero Yes No (min 1 instance)
Custom runtimes No (predefined only) Yes (Docker)
Supported languages Go, Java, Node.js, PHP, Python, Ruby Any (via Docker)
SSH access No Yes
VPC connectivity Yes (Direct VPC egress / connectors) Yes (native VPC)
Max compute F4_1G (3GB/2.4GHz) Any CE machine type
Background processes Limited (within request lifecycle) Yes
Write to disk Yes (/tmp only, in-memory) Yes (ephemeral disk)
Free tier Yes No
Health checks Automatic Configurable
Traffic splitting IP, cookie, random IP, cookie
High availability Single zone (auto-recovers) Multi-zone (regional MIG)

Google Cloud - App Engine Standard vs Flexible Environment

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’re writing a Python application and want your application to run in a sandboxed managed environment with the ability to scale up in seconds to account for huge spikes in demand. Which service should you host your application on?
    1. Compute Engine
    2. App Engine Flexible Environment
    3. Kubernetes Engine
    4. App Engine Standard Environment
  2. A Company is planning the migration of their web application to Google App Engine. However, they would still continue to use their on-premises database. How can they setup application?
    1. Setup the application using App Engine Standard environment with Cloud VPN to connect to database
    2. Setup the application using App Engine Flexible environment with Cloud VPN to connect to database
    3. Setup the application using App Engine Standard environment with Cloud Router to connect to database
    4. Setup the application using App Engine Flexible environment with Cloud Router to connect to database

    Note: With second-generation runtimes, Standard environment can now connect to VPC using Direct VPC egress or Serverless VPC connectors, making option A potentially valid for newer deployments. However, for direct Cloud VPN connectivity, Flexible environment remains the straightforward choice.

  3. A startup wants to deploy a containerized application written in Rust with minimal operational overhead and the ability to scale to zero during periods of inactivity. Which Google Cloud service should they use?
    1. App Engine Standard Environment
    2. App Engine Flexible Environment
    3. Cloud Run
    4. Google Kubernetes Engine
  4. Your team is running an application on App Engine Standard environment using Python 2.7 runtime. Google has deprecated first-generation runtimes. What is the recommended migration path?
    1. Migrate directly to Compute Engine
    2. Migrate to the latest Python 3 runtime on App Engine Standard or migrate to Cloud Run
    3. No action needed; the application will continue running indefinitely
    4. Migrate to App Engine Flexible environment
  5. Which of the following is TRUE about App Engine Standard environment with second-generation runtimes? (Choose TWO)
    1. Applications can connect to VPC networks using Direct VPC egress
    2. Applications can use any programming language via custom Docker containers
    3. Applications can scale to zero instances when there is no traffic
    4. Applications support SSH access for debugging
    5. Applications require at least one instance always running
  6. A company wants to deploy a web application that requires GPU access for AI inference with automatic scaling and minimal infrastructure management. Which service should they use?
    1. App Engine Standard Environment
    2. App Engine Flexible Environment
    3. Cloud Run
    4. Compute Engine with managed instance groups
  7. Which App Engine environment provides multi-zone high availability by distributing instances across multiple zones in a region?
    1. Standard Environment with automatic scaling
    2. Standard Environment with manual scaling
    3. Flexible Environment
    4. Both Standard and Flexible environments

Frequently Asked Questions

What is the difference between App Engine Standard and Flexible?

Standard environment runs in a sandbox with automatic scaling to zero, supports specific language runtimes, and has free daily quota. Flexible environment runs in Docker containers on Compute Engine VMs with custom runtimes, no free tier, and minimum 1 instance.

Can App Engine scale to zero?

App Engine Standard can scale to zero instances when there’s no traffic, meaning you pay nothing during idle time. Flexible environment requires at least one instance running at all times.

Should I use App Engine or Cloud Run?

Cloud Run is recommended for new applications — it offers container-based serverless with scale-to-zero, any language/binary support, and per-request pricing. App Engine is still valid for existing apps but Cloud Run provides more flexibility.

References