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