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

~ Last updated on : ~ jayendrapatil

Google Cloud Compute Options

Compute Engine

  • provides Infrastructure as a Service (IaaS) in the Google Cloud
  • provides full control/flexibility on the choice of OS, resources like CPU and memory
  • 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
  • Usage anti-patterns
    • containerized applications – Choose App Engine, GKE, or Cloud Run
    • stateless event-driven applications – Choose Cloud Functions

App Engine

  • helps build highly scalable web and mobile backend applications on a fully managed serverless platform
  • Usage patterns
    • Rapidly developing CRUD-heavy applications
    • HTTP/S based applications
    • Deploying complex APIs
  • 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

Google Kubernetes Engine – GKE

  • provides a managed environment for deploying, managing, and scaling containerized applications using Google infrastructure.
  • Usage patterns
    • containerized applications or those that can be easily containerized
    • Hybrid or multi-cloud environments
    • Systems leveraging stateful and stateless services
    • Strong CI/CD Pipelines
  • Usage anti-patterns
    • non-containerized applications – Choose CE or App engine
    • applications requiring very low-level access to the underlying hardware like custom kernel, networking, etc. – Choose CE
    • stateless event-driven applications – Choose Cloud Functions

Cloud Run

  • provides a serverless managed compute platform to run stateless, isolated containers without orchestration that can be invoked via web requests or Pub/Sub events.
  • abstracts away all infrastructure management allowing users to focus on building great applications.
  • is built from Knative.
  • Usage patterns
    • Stateless services that are easily containerized
    • Event-driven applications and systems
    • Applications that require custom system and language dependencies
  • Usage anti-patterns
    • Highly stateful systems
    • Systems that require protocols other than HTTP
    • Compliance requirements that demand strict controls over the low-level environment and infrastructure (might be okay with the Knative GKE mode)

Cloud Functions

  • provides serverless compute for event-driven apps
  • Usage patterns
    • ephemeral and event-driven applications and functions
    • fully managed environment
    • pay only for what you use
    • quick data transformations (ETL)
  • Usage anti-patterns
    • continuous stateful application – Choose CE, App Engine or GKE
Credit @ https://thecloudgirl.dev/

Google Cloud Compute Options Decision Tree

Google Cloud Compute Options Decision Tree

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
    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 Functions

Google Cloud Compute Services Cheat Sheet

~ Last updated on : ~ jayendrapatil

Google Cloud Compute Services

Google Cloud - Compute Services Options

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
  • Preemptible VM is an instance that can be created and run at a much lower price than normal instances, however can be stopped at any time
  • 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.
  • 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 template 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

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
  • Support 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.

GKE

Node Pool

GKE
commands
–num-nodes scale cluster –size is deprecated

Google Cloud App Engine

~ 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 – Key Differences

~ 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

References