Cloud / Google App Engine Interview questions

Google App Engine (GAE) is a fully managed Platform as a Service (PaaS) on Google Cloud for building and hosting web applications and APIs. You upload your code plus an app.yaml file, and Google handles servers, OS patching, load balancing and scaling.

Each Google Cloud project can hold one App Engine application, and its region is picked once and cannot be changed. Inside that application you create services, each with one or more versions running on instances.

It fits request-driven workloads such as REST backends, websites and mobile APIs. It is a weaker fit for non-HTTP protocols or workloads that need full control of the operating system.

App Engine has two environments: standard and flexible. You choose one per service, and different services in the same application can use different environments.

• Standard: your code runs in a Google-managed sandbox for a fixed list of languages. Instances start in seconds and can scale down to zero.
• Flexible: your app runs as a Docker container on Compute Engine VMs that Google manages. Any language works through a custom runtime, but at least one instance is always running.

Start with standard unless you need a custom binary, background processes or SSH access to the instance.

The standard environment runs your code in a sandboxed, Google-managed runtime for Python, Java, Node.js, PHP, Ruby and Go. You never see the VM, and Google patches the runtime and OS for you.

Instances start in seconds, so standard can scale from zero to many instances quickly and cost almost nothing when idle. The file system is read-only apart from /tmp, which lives in memory and counts against the instance's RAM.

Instance sizes are the F family (automatic scaling) and the B family (basic and manual scaling), billed per instance hour.

The flexible environment runs your application as a Docker container on Compute Engine VMs that App Engine provisions, health-checks and auto-heals. You select it with env: flex in app.yaml.

runtime: custom
env: flex
resources:
  cpu: 2
  memory_gb: 4

Because it is a real container, you can install native libraries, run background processes and SSH into an instance for debugging. The trade-offs are slower deploys and scale-up (minutes, not seconds) and a minimum of one running instance, so there is no scale-to-zero. Billing is based on vCPU, memory and disk.

app.yaml is the descriptor deployed with every service version. It tells App Engine which runtime to use and how the version should run and scale.

runtime: python313
service: api
entrypoint: gunicorn -b :$PORT main:app
instance_class: F2
automatic_scaling:
  max_instances: 5
env_variables:
  LOG_LEVEL: info

Typical settings are the runtime, entrypoint, instance class, scaling, handlers, environment variables, VPC access and the service account. If service is omitted, the version goes to the default service, and your first deployment must be that default service.

Because it ships with the code, changes to app.yaml take effect only on the next deploy. With several services, keep one file per service, for example api.yaml, and deploy it by name with gcloud app deploy api.yaml.

They form a hierarchy: application, service, version, instance.

• Service: one logical component, such as web or api, with its own app.yaml and its own URL like api-dot-PROJECT.REGION.r.appspot.com.
• Version: one deployed snapshot of a service. A service can hold many versions, and traffic settings decide which ones receive requests.
• Instance: the actual running unit that handles requests. App Engine creates and destroys instances based on the scaling settings.

So you deploy versions, you route traffic to versions, and App Engine scales instances.

The standard environment supports Python, Java, Node.js, PHP, Ruby and Go. The flexible environment covers the same languages and adds .NET, and also accepts any language through a custom Dockerfile.

Every runtime version has a lifecycle with end-of-support, deprecated and decommissioned dates, published on Google's runtime support schedule. The old first-generation runtimes such as Python 2.7, Java 8, Go 1.11 and PHP 5.5 are already past end of support and are scheduled for decommissioning.

The runtime is chosen with an ID in app.yaml, for example go126. App Engine may block redeployments on a runtime after its end of support date, so check the schedule before you start a new project.

Deployment is a handful of gcloud commands. Billing must be enabled and the App Engine Admin API and Cloud Build API must be on.

1. Install the Google Cloud CLI and run gcloud init to pick the project.
2. Create the App Engine application once per project: gcloud app create --region=us-central.
3. Add an app.yaml next to your code.
4. Run gcloud app deploy from that folder.
5. Open the result with gcloud app browse.

Files you list in .gcloudignore are not uploaded. Each deploy creates a new version, and by default it also takes traffic.

dispatch.yaml routes incoming requests to different services based on URL patterns. It applies to the whole application, not to a single service.

dispatch:
  - url: "*/api/*"
    service: api
  - url: "*/admin/*"
    service: admin

Without it, requests to your domain go to the default service. Rules match on host and path and are checked in order. Deploy them with gcloud app deploy dispatch.yaml.

A common use is splitting one domain into a web frontend and an API backend without separate hostnames. Dispatch and traffic splitting are different layers: dispatch picks the service, then splitting picks the version inside it. Re-check your rules after each change, since an overly broad pattern can send traffic to the wrong service.

cron.yaml defines scheduled jobs. At each scheduled time App Engine sends an HTTP GET request to a URL in your app, and your handler does the work.

cron:
  - description: nightly cleanup
    url: /tasks/cleanup
    schedule: every day 02:00
    timezone: Asia/Kolkata
    target: worker

target picks the service. Cron requests carry an X-Appengine-Cron: true header that is stripped from outside traffic, so a handler can trust it. The request timeout follows your scaling type. For targets outside App Engine, use Cloud Scheduler.

Keep cron handlers idempotent, because a job can run twice or be retried after a failure. If the work may exceed the request limit for your scaling type, let the cron handler enqueue Cloud Tasks and return quickly.

There are three: automatic, basic and manual. Standard supports all three, while flexible supports automatic and manual.

You can change the type later by redeploying with a different app.yaml. Automatic and basic scaling can both fall to zero instances when idle, while manual scaling never does because its instance count is fixed.

An instance class sets the CPU and memory of each standard environment instance, and the price per hour. Higher classes cost more.

• F family (F1, F2, F4, F4_1G) is used with automatic scaling. F1 is the smallest and the default.
• B family (B1 to B8) is used with basic and manual scaling.

instance_class: F2

The flexible environment has no instance classes. You set cpu, memory_gb and disk_size_gb under resources instead.

Start with the default and watch memory in Cloud Monitoring. If instances hit the soft memory limit and restart, move up a class. If CPU is the bottleneck, one larger class can be cheaper than many small instances.

Use handlers in app.yaml. static_dir maps a URL prefix to a folder, and static_files with upload maps a regex to files.

handlers:
- url: /static
  static_dir: static
  expiration: 7d
- url: /.*
  script: auto
  secure: always

Handlers are evaluated in order and the first match wins, so put the catch-all last. Static files are served by Google's infrastructure and do not use your instance hours. For large or user-uploaded content, use Cloud Storage with Cloud CDN.

For single-page apps, a common setup is a static handler for the build folder plus a final catch-all that returns index.html. Set expiration on fingerprinted assets so browsers and CDNs can cache them for a long time.

Add an env_variables block to app.yaml. The values are available to your code as normal environment variables and change only when you redeploy.

env_variables:
  APP_MODE: production
  CACHE_TTL: "300"

App Engine also sets built-ins such as PORT, GAE_SERVICE, GAE_VERSION and GOOGLE_CLOUD_PROJECT. Do not put passwords or API keys here, because app.yaml usually sits in source control. Use Secret Manager for those.

Values are strings, so quote numbers and booleans in the YAML to avoid surprises. Read them with os.environ in Python or process.env in Node.js. For per-environment values, keep a separate file such as app-staging.yaml and deploy the one you need.

App Engine sends request logs and anything written to stdout or stderr to Cloud Logging automatically.

gcloud app logs tail -s default
gcloud app logs read --service=api --limit=50

In the console, open Logs Explorer and filter on the gae_app resource type, adding severity>=ERROR to see only failures. Error Reporting groups repeated exceptions, and Cloud Trace shows where request time goes.

The default log bucket keeps entries for 30 days, so export or extend retention if you need more. Writing structured JSON to stdout lets Logging parse severity and fields, which makes filtering much easier. Log-based metrics and alerts can then notify you about error spikes.

It is Google's fully managed NoSQL document database and the successor to Cloud Datastore. App Engine apps commonly use it as their primary store.

Data is stored as entities of a given kind, each with a key and properties. Queries are strongly consistent, transactions are ACID, and capacity scales automatically.

Single-property indexes are built for you. Queries that filter or sort on several properties need a composite index, declared in index.yaml. It has no joins, so model data around your queries.

It is the identity your app uses when calling Google Cloud APIs. Its name is PROJECT_ID@appspot.gserviceaccount.com, and it is created with the App Engine application.

Historically it was granted the broad Editor role, which is far more than most apps need. A better practice is to create a dedicated service account with only the roles required and point the service at it:

service_account: my-app-sa@PROJECT_ID.iam.gserviceaccount.com

Also remember that the account used for deployment needs the right permissions, or a first deploy can fail with a permission error.

Mapping takes a few console steps:

1. Open App Engine > Settings > Custom domains and add the domain.
2. Verify that you own it, usually with a DNS TXT record.
3. Add the DNS records App Engine shows you: A and AAAA records for an apex domain, or a CNAME for a subdomain.
4. Wait for DNS to propagate and for the certificate to be issued.

App Engine provisions and renews a managed SSL certificate for the domain, so you do not run certbot yourself. For advanced needs such as a WAF or multi-service routing, put a Cloud Load Balancer in front.

Cloud Tasks is a managed queue for asynchronous work. Your app adds a task, and Cloud Tasks delivers it as an HTTP request to a handler, with retries.

It is used for things you do not want to do inside the user's request: sending emails, resizing images, calling slow third-party APIs. You control the dispatch rate, retry backoff and scheduled delivery time per queue.

The handler must return a 2xx status to confirm success. Anything else, including a timeout, triggers a retry. Task requests carry headers such as X-AppEngine-QueueName. Cloud Tasks replaces the legacy Task Queue API.

entrypoint is the command that starts your web server on newer App Engine runtimes. The server must listen on 0.0.0.0 at the port in the PORT environment variable, which is 8080 by default.

entrypoint: gunicorn -b :$PORT -w 2 --timeout 120 main:app

Runtimes have defaults, for example Node.js runs npm start, but setting it explicitly is safer. This is also where you tune the server, such as worker count and timeouts.

If the server binds to 127.0.0.1 or a hardcoded port, App Engine cannot reach it, and the deploy fails health checks or serves errors. Read the port from the variable instead of assuming 8080.

They are the original App Engine APIs from the first-generation runtimes: Memcache, Task Queue, Mail, Images, Blobstore, Search, URL Fetch and Users.

Some second-generation runtimes can still use them if you enable app_engine_apis: true in app.yaml and add Google's bundled-services library for your language.

They exist mainly to ease migration. Google steers new code toward standalone services: Memorystore instead of Memcache, Cloud Tasks instead of Task Queue, and Cloud Storage instead of Blobstore.

These calls add latency and are not available on every runtime, so check the migration guide for your language before depending on one in a new app.

A warmup request is a GET to /_ah/warmup that App Engine can send to a new instance before real users arrive, so your app can load code, open connections and fill caches.

You turn it on with inbound_services and add a handler for the path:

inbound_services:
- warmup

Warmups are best-effort. A user request can still hit an instance that is loading, so keep start-up work light as well. Basic and manual scaling use /_ah/start instead.

Treat warmup as an optimization, not a requirement. Without a handler you only lose the head start. Keep the handler quick, since a slow warmup delays the moment the instance can serve traffic.

Both run web apps, but they differ in how the app is packaged, how fast it scales and how much control you get.

Pick standard for spiky web traffic and low idle cost. Pick flexible when you need native binaries, a custom image or long-lived background work.

Check pricing early, too. Standard bills instance hours with some free daily usage, while flexible bills continuously for the CPU, memory and disk you allocate.

The difference is who decides how many instances run and how long a request may take.

Choose automatic for typical web traffic. Choose basic for sporadic jobs that run longer than ten minutes. Choose manual when you need instances that stay up and keep state in memory.

In practice most teams start with automatic scaling and use basic only for rare long-running work. Manual scaling is the least common choice today.

The scheduler watches CPU utilization, concurrent requests per instance and pending latency, which is how long a request waits for a free instance. It starts a new instance when a request would wait longer than max_pending_latency or when utilization crosses its target.

automatic_scaling:
  target_cpu_utilization: 0.65
  max_concurrent_requests: 20
  max_pending_latency: 200ms
  min_instances: 0
  max_instances: 10

It scales down when instances sit idle. max_instances is a hard cap: once reached, extra requests queue and may fail with 503 errors. Raise max_concurrent_requests only if your code is thread-safe and not CPU-bound.

To see what the scheduler is doing, watch the Instances and Pending Latency charts in Cloud Monitoring during a load test. Change one setting at a time and re-test, because CPU target, concurrency and latency settings interact.

min_instances is the number of instances App Engine always keeps running to serve traffic. min_idle_instances is a buffer of extra, idle instances kept on top of those already busy, ready to absorb sudden spikes.

Both stop the app from scaling to zero, so use them only on latency-sensitive services.

A typical customer-facing API uses min_instances: 1, plus a small min_idle_instances buffer only if traffic arrives in bursts. Batch and admin services usually keep both at zero.

Traffic splitting sends percentages of a service's traffic to different versions. It is used for canary releases and A/B tests.

gcloud app services set-traffic default \
  --splits v1=0.9,v2=0.1 --split-by cookie

Splitting applies to normal URLs. Version-specific URLs like v2-dot-default-dot-PROJECT... always reach that exact version.

Cookie splitting depends on the client sending the cookie, so API clients like curl or mobile SDKs will not stick unless they keep it. For machine-to-machine traffic, use random splitting or test through the version-specific URL. Splits are set per service, so each service can run its own canary.

By default a deploy makes the new version receive all traffic. With --no-promote, the version is deployed but receives none, so users keep seeing the old one.

gcloud app deploy --version=v2 --no-promote

You can test the new version at its own address, https://v2-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com. When you are happy, send it traffic:

gcloud app services set-traffic SERVICE --splits v2=1

This is the basis of safer releases. For automatic scaling, instances for the new version start when the first test request arrives, so you can also observe cold-start behaviour. Test versions still consume quota and may cost money, so delete the ones you no longer need. The --version flag sets the version ID, otherwise App Engine generates one from the date and time.

Rollback is just sending traffic back to the last good version, which is why you should not delete old versions right away.

1. List versions: gcloud app versions list.
2. Route all traffic back: gcloud app services set-traffic SERVICE --splits GOOD_VERSION=1.
3. If the old version uses basic or manual scaling and was stopped, start it first with gcloud app versions start.
4. Fix the bug, deploy under a new version ID, and delete the broken version later.

Never reuse a version ID for a new release, since that overwrites the version you wanted to roll back to.

Practice the rollback in staging so the commands are familiar during an incident. Keep the last two or three versions, and remember that an application has a limit on total versions, so clean up old ones on a schedule.

The region is fixed when you run gcloud app create --region. App Engine ties the application, its default Cloud Storage bucket and the default Firestore or Datastore location to that choice, and there is no command to relocate them.

The only route is to create a new project in the target region, deploy the code there, copy the data and switch DNS. Note that two regions use short names, us-central and europe-west.

So choose carefully at the start, based on where your users, databases and other services are.

If you must move, lower the DNS TTL in advance and plan a dual-write or short downtime window for the database. Recreate cron jobs, Cloud Tasks queues and secrets in the new project, because none of them travel with the app.

App Engine deploys source code on a set of language runtimes, while Cloud Run runs any container image. Both are serverless, scale to zero and support traffic splitting.

Google documents a path to move standard apps to Cloud Run. For new work, Cloud Run is usually the simpler start unless you rely on App Engine-specific features.

Neither wins everywhere. It depends on how much control you need versus how much operations work you accept.

Choose App Engine for web apps and APIs when you want the smallest ops burden. Choose GKE for microservice platforms, custom operators or stateful systems, and when you need to run the same manifests elsewhere.

Cost behaves differently too. App Engine charges for instances that are actually running, while a GKE Standard cluster has a baseline cost for its nodes even when the app is quiet. Autopilot narrows that gap by billing for pod resources.

Compute Engine is IaaS: you get virtual machines and manage the OS, runtime, patching and scaling groups. App Engine is PaaS: you hand over code and Google runs the rest.

Use Compute Engine when you need OS-level control or non-HTTP workloads.

A middle path is the flexible environment, which still runs on Compute Engine VMs but hides most of the VM management. Teams often keep Compute Engine for supporting pieces, such as a legacy agent that cannot be containerized.

The usual route is a Unix socket at /cloudsql/INSTANCE_CONNECTION_NAME, where the name looks like project:region:instance.

• Standard: connect to the socket path from your driver. No extra network setup is needed for a public-IP instance in the same project.
• Flexible: list the instance under beta_settings: cloud_sql_instances in app.yaml first.
• Private IP: add a Serverless VPC Access connector (standard) so the app can reach the private address.

The app's service account needs the Cloud SQL Client role. Keep the DB password in Secret Manager, and create the connection pool once at global scope so instances reuse it.

Remember that every instance has its own connection pool and Cloud SQL has a connection limit. With automatic scaling, set max_instances and a small pool size so the total stays under the database limit.

Standard environment apps run outside your VPC, so they need a bridge to reach private IPs such as Memorystore or an internal VM.

• Serverless VPC Access connector: reference it in app.yaml with vpc_access_connector. The connector runs on small VMs, so it adds cost.
• Direct VPC egress: a newer option, currently in Preview, that avoids a connector.
• Flexible environment: instances already live in a VPC network you choose.

vpc_access_connector:
  name: projects/PROJECT/locations/REGION/connectors/my-conn
  egress_setting: private-ranges-only

private-ranges-only sends only private-range traffic through the connector. Use all-traffic to also route internet traffic through the VPC, for example to use a static NAT IP.

Create the connector in the same region as the app, and make sure its IP range does not overlap other ranges in the VPC. Connector throughput depends on its instance count and machine type, so watch it if you push heavy traffic through it.

IAP sits in front of the app and checks who the user is before the request reaches your code. Users sign in with a Google identity, and IAP then checks IAM for the IAP-secured Web App User role.

Your app gets the verified identity in a signed header, x-goog-iap-jwt-assertion. As defense in depth, verify that JWT's signature and audience in your code instead of trusting plain email headers.

This gives you employee-only tools without writing a login system. Enable it from the console under Security > Identity-Aware Proxy.

Access is granted by adding users, groups or domains to the IAP role, so onboarding and offboarding happen in IAM instead of in your own database. Combine it with firewall rules if you also want to limit where requests can come from.

App Engine firewall rules allow or deny traffic by IP range before requests reach your instances. They apply to every service and version in the application.

gcloud app firewall-rules create 100 \
  --action=ALLOW --source-range=203.0.113.0/24
gcloud app firewall-rules update default --action=DENY

Rules run in priority order, and a lower number is checked first. The built-in default rule has the lowest priority and allows everything. A common pattern is to flip it to deny and allow only known ranges. If you do, remember to allow internal callers such as Cron, whose requests come from 0.1.0.2.

Test new rules carefully, because an overly strict default can lock out Cron or your own team. Firewall rules do not replace authentication, so use them together with IAP or application-level login.

Use Secret Manager. Keep passwords and API keys out of app.yaml, out of environment variables in source control and out of the repo.

1. Create the secret: gcloud secrets create db-password --data-file=-.
2. Grant the app's service account the Secret Manager Secret Accessor role.
3. Read the secret at start-up with the client library and keep it in memory.

Pin a version when you need predictable behaviour, or use latest to pick up rotations on the next instance start. Reading a secret on every request adds latency and cost.

Rotate a secret by adding a new version in Secret Manager and then redeploying or restarting instances. Audit logs show which identity read a secret, which helps during security reviews.

Instances come and go, and consecutive requests from one user can land on different instances. So never keep session data only in instance memory or in /tmp.

• Signed cookies: store small session data on the client, signed or encrypted.
• Memorystore for Redis: fast shared store, needs VPC access.
• Firestore or Cloud SQL: durable shared store, slower.

The flexible environment offers optional session affinity, but even then an instance can restart, so shared storage is still safer.

Whatever store you choose, give session records an expiry so abandoned sessions get cleaned up. Signed cookies are the cheapest option for simple apps, but keep them small because the browser sends them with every request.

Both deliver work asynchronously, but they model different things. Cloud Tasks is targeted work for one handler. Pub/Sub is an event stream for many subscribers.

Use Tasks for jobs like "send this email at 9am, 10 per second." Use Pub/Sub when several services react to one event.

They also combine well: a Pub/Sub message triggers a handler, which then enqueues rate-limited Cloud Tasks for the slow downstream calls.

App Engine ends the request and the client gets an error response. The limits depend on environment and scaling type.

Your own server can fail sooner. For example, Gunicorn kills a worker after 30 seconds by default, so raise --timeout in the entrypoint if needed. Cloud Tasks treats a timeout as a failure and retries, so make handlers idempotent. Move long jobs to a queue instead of holding a user request open.

Log request durations so you can spot handlers drifting toward the limit before users see failures. A client or a load balancer in front of App Engine may have its own shorter timeout, so check every hop.

A 503 usually means no instance could take the request. Work through it in this order:

1. Open Logs Explorer, filter gae_app with severity>=ERROR, and read the entries around the first 503.
2. Look for start-up failures: the process exits, a missing dependency, or the server not listening on $PORT.
3. Check the Instances and Latency charts for hitting max_instances or long pending latency.
4. Check memory: Exceeded soft memory limit restarts an instance, so raise the instance class.
5. Check Quotas for exhausted resources, and for flexible, check failing health checks.

Fixes follow the cause: correct the entrypoint, raise max_instances or min_instances, or increase concurrency or instance size.

A cold start is the delay while a new instance loads the runtime and your code. You can shorten it or hide it.

• Set min_instances: 1 (or min_idle_instances) so a warm instance is always waiting. This costs money.
• Enable warmup requests so initialization finishes before users arrive.
• Keep imports and initialization lean: avoid loading big datasets or every optional library at start-up, and slim down dependencies.
• Create clients and connection pools once at global scope for reuse.
• Use a larger instance class, since extra CPU speeds start-up.
• Lower max_pending_latency so new instances start earlier.

Measure before and after. Request logs and Cloud Trace show how long new instances take to start, so you can tell whether a change really helped or only moved the cost somewhere else.

Most savings come from matching instance count and size to real load.

• Right-size the instance class. Check memory usage and drop to a smaller F class if it fits.
• Let dev and test services scale to zero with min_instances: 0, and cap max_instances. New projects created after March 2025 default to a maximum of 20.
• Tune max_concurrent_requests so each instance does more work before another starts.
• Delete or stop old versions, since running basic or manual versions keep billing.
• Serve static content from Cloud Storage with Cloud CDN, and set cache headers.
• Create budgets and alerts to catch surprises early.

Treat the live version as blue and the new one as green. Both exist side by side, so switching and rollback are just traffic changes.

1. Deploy green without traffic: gcloud app deploy --version=green --no-promote.
2. Test it at green-dot-SERVICE-dot-PROJECT...appspot.com with real dependencies.
3. Switch: gcloud app services set-traffic SERVICE --splits green=1.
4. Keep blue for a while as the rollback target, then delete it.

For a gentler release, do a canary instead: split 5% to green with --split-by cookie, watch error rate and latency, then raise the share step by step.

Database changes need care here, because blue and green may run at the same time against one database. Make schema changes backward-compatible: add columns first, and remove old ones only after the cutover is stable.

A request passes through Google's front end, then routing, then an instance. The app only sees it at the end.

flowchart LR
  A[Client] --> B["Google front end: TLS, firewall, IAP"]
  B --> C{Static handler?}
  C -- Yes --> D["Served from static infrastructure"]
  C -- No --> E["dispatch.yaml picks service"]
  E --> F["Traffic split picks version"]
  F --> G{Free instance?}
  G -- Yes --> H["Instance runs app handler"]
  G -- No --> I["Queue or start new instance"]
  I --> H
  H --> J["Response and logs"]

1. TLS ends at the front end, where firewall rules and IAP are applied.
2. Matching static handlers are answered without touching an instance.
3. dispatch.yaml picks the service, and traffic splitting picks the version.
4. The scheduler hands the request to a free instance, or queues it while a new one starts.
5. The handler responds, and request logs go to Cloud Logging.

Two details matter in practice. A request that arrives while all instances are busy waits in a pending queue, and that waiting time is what the autoscaler watches. The front end also adds headers such as X-Forwarded-For, and internal headers from Cron or Tasks cannot be spoofed by outside callers, which is why handlers can trust them.

An instance is created by a scale-up or deploy, serves requests, then is shut down when it is no longer needed or when the platform recycles it.

flowchart TD
  A["Scale-up or deploy"] --> B["Runtime and code load"]
  B --> C["Warmup request, optional"]
  C --> D["Serving requests"]
  D --> E{Idle or recycled?}
  E -- No --> D
  E -- Yes --> F["SIGTERM sent"]
  F --> G["Short grace period"]
  G --> H["SIGKILL and instance removed"]

Loading is the cold start, and the first request may wait for it. After that the instance serves requests until it goes idle, hits a memory limit or is moved by maintenance.

On shutdown the app gets SIGTERM and only a few seconds before SIGKILL. So never rely on instance memory or local files for durable data, and flush work quickly.

Because instances are interchangeable, keep initialization idempotent and never depend on one instance surviving between requests. Memory leaks matter too: an instance that exceeds its memory limit is restarted, and the request in flight can fail.

The command packages your source, builds it remotely, creates a version and optionally moves traffic to it.

flowchart TD
  A["gcloud app deploy"] --> B["Read app.yaml and .gcloudignore"]
  B --> C["Upload source to Cloud Storage"]
  C --> D["Cloud Build builds the image"]
  D --> E["Image stored in the container registry"]
  E --> F["New version created"]
  F --> G["Instances start and pass health checks"]
  G --> H{--promote?}
  H -- Yes --> I["Traffic moves to new version"]
  H -- No --> J["Version waits at its own URL"]

1. The CLI validates app.yaml and skips files in .gcloudignore.
2. Source is uploaded to a Cloud Storage staging bucket.
3. Cloud Build builds a container, which is stored in Google's container registry.
4. App Engine creates the version and starts instances.
5. With promotion (the default), traffic moves over, otherwise it waits.

Deploy failures often trace to a disabled Cloud Build API or a service account without enough permissions.

Version IDs must be unique within a service, and without --version App Engine generates one from the date and time. Build logs are in Cloud Build history, which is the first place to look when a deploy stops before any instance starts.

Flexible instances are Compute Engine VMs, and Google restarts them roughly weekly to apply OS and security updates. This is routine maintenance, not a failure.

The consequences are practical. The local disk is ephemeral and wiped on restart. In-memory state is lost. An instance can disappear with only a short SIGTERM warning.

• Run at least two instances so one is always serving.
• Handle SIGTERM and finish or hand off in-flight work.
• Define readiness and liveness checks so traffic only reaches healthy instances.
• Keep state in Cloud SQL, Firestore, Memorystore or Cloud Storage.

Designing for this up front makes the app resilient to unexpected failures too.

In Cloud Logging you will see a new instance ID after each restart, so you can verify the behaviour. A load test during a redeploy is a good way to check your shutdown handling.

Treat it as a feature-by-feature mapping, then move traffic gradually. Google also offers an App Engine Migration hub, currently in Preview, that can help with standard services.

flowchart LR
  A["Inventory app.yaml and bundled APIs"] --> B["Containerize with Dockerfile or buildpacks"]
  B --> C["Replace App Engine specific features"]
  C --> D["Deploy to Cloud Run with no traffic"]
  D --> E["Test and shift traffic gradually"]
  E --> F["Retire old App Engine version"]

Deploy with gcloud run deploy --source ., copy over environment variables and service account, and confirm the app listens on $PORT. Use revision traffic splitting to cut over, and keep the old version until it is proven.

Plan the cutover around data. Databases, queues and secrets are usually shared, so most apps can run on both platforms side by side during the transition, which makes rollback as simple as shifting traffic back.