Cloud / Google Cloud Run Interview questions

Cloud Run is a fully managed serverless platform on Google Cloud that runs containers without you managing servers or clusters. You give it a container image (or source code) and it takes care of provisioning, HTTPS endpoints, scaling and patching of the underlying infrastructure.

It scales with traffic, including down to zero instances when nothing is calling the service, and you are billed only for the resources your code actually uses.

The unit of deployment is a standard container, so any language, framework or binary works as long as it follows the container contract. Cloud Run offers services for HTTP workloads, jobs for run-to-completion tasks and worker pools for continuous background processing.

Cloud Run has three workload types, each for a different execution pattern.

Services get a stable run.app URL and scale on incoming requests. Jobs run tasks until the container exits. Worker pools have no HTTP endpoint and keep instances running to process work from a queue or stream.

A revision is an immutable snapshot of a service: the container image plus its configuration, such as environment variables, memory, CPU, concurrency, timeout and service account. Cloud Run creates a new revision every time you deploy a new image or change any of those settings.

Revisions are named like my-service-00007-abc and each one can receive a share of traffic. Because they never change after creation, you can send traffic back to an older revision for an instant rollback.

Revisions that receive no traffic do not run instances, so keeping a few old ones around costs nothing in compute.

The container contract is the set of rules your container must follow to run correctly on Cloud Run. For services, the main ones are:

• Listen for requests on 0.0.0.0 at the port in the PORT environment variable (not on 127.0.0.1).
• Respond within the configured request timeout, otherwise the request ends with a 504.
• Be stateless, since instances start and stop at any time and local files vanish with them.
• Do not terminate TLS yourself; Cloud Run handles HTTPS and forwards plain HTTP to the container.

Jobs follow a different rule: the container must exit when the work is done, with exit code 0 meaning success.

Cloud Run injects PORT into the ingress container to tell your app which port to listen on. The default value is 8080, and you can change it with --port at deploy time.

Your code should read the variable instead of hard-coding a number. If the app listens somewhere else, Cloud Run cannot reach it and the revision fails its startup check.

import os
from flask import Flask
app = Flask(__name__)

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=int(os.environ.get("PORT", 8080)))

Push the image to a registry such as Artifact Registry, then deploy it with gcloud run deploy. You can also use the Cloud Console, Terraform or the Cloud Run Admin API.

gcloud run deploy orders-api \
  --image us-docker.pkg.dev/my-proj/apps/orders-api:1.4.0 \
  --region us-central1 \
  --memory 512Mi \
  --set-env-vars APP_ENV=prod

The command creates a new revision, waits for it to pass its startup check and then routes traffic to it. The output prints the service URL.

A Cloud Run job runs a container to completion instead of serving requests. A job is made of one or more tasks, and each task runs one container instance until it exits.

You control the number of tasks with --tasks, how many run at once with --parallelism, and failure handling with --max-retries and --task-timeout. Each task can read CLOUD_RUN_TASK_INDEX and CLOUD_RUN_TASK_COUNT to pick its slice of the data.

Jobs can be started manually, from Cloud Scheduler or from Workflows. They suit batch work like data imports, nightly reports and database migrations.

Concurrency is the maximum number of requests a single container instance handles at the same time. The default is 80 and the maximum is 1000, set with --concurrency.

When every instance is at its limit, Cloud Run starts more instances. Higher concurrency means fewer instances for the same traffic, which usually lowers cost, but your code must be safe for parallel requests.

Set it to 1 if the app is not thread-safe or each request needs most of the CPU.

A cold start is the extra latency a request sees when Cloud Run has no ready instance and must start one. The delay covers pulling the image layers, starting the container, running your initialization code and passing the startup check.

Cold starts happen after scale-to-zero, during traffic spikes that need new instances and after a new revision is deployed. Warm instances answer immediately.

Typical fixes are minimum instances, startup CPU boost, smaller images and lazy initialization of heavy dependencies.

--min-instances keeps a set number of instances ready even when there is no traffic. The default is 0, which allows scale-to-zero.

With a minimum of 1 or more, the first request does not wait for a container to start, which removes most cold starts for latency-sensitive APIs.

The trade-off is cost: idle minimum instances are still billed, at a lower idle rate under request-based billing, so use them only on services where latency matters.

--max-instances caps how many instances a service or revision can scale out to. The default limit is 100 and it can be raised through quota.

A cap protects things behind the service that cannot scale as fast, such as a Cloud SQL database with limited connections, and it puts a ceiling on spend if traffic or a bug creates a flood of requests.

If traffic needs more capacity than the cap allows, extra requests wait briefly and then fail with a 429.

Grant the roles/run.invoker role to allUsers. The deploy flag --allow-unauthenticated does this for you.

gcloud run services add-iam-policy-binding my-service \
  --member=allUsers --role=roles/run.invoker --region=us-central1

Without that binding, every request needs a valid Google-signed identity token. Note that an organization policy for domain-restricted sharing can block allUsers bindings, and the ingress setting must also allow traffic from the internet.

You can check the current state with gcloud run services get-iam-policy my-service. If allUsers is missing from the roles/run.invoker binding, the service is private. To close it again, remove that binding and callers will get 403 Forbidden unless they send a valid identity token.

roles/run.invoker gives a principal permission to call a Cloud Run service or job, and nothing else. It does not allow deploying, editing or reading configuration.

You grant it to the callers: a front-end service account, a Pub/Sub push subscription, a Cloud Scheduler job or allUsers for public services.

Deploying is covered by roles/run.developer or roles/run.admin, which keeps caller access and deploy access separate.

A common mistake is giving a caller roles/run.admin just to make requests work. That grants far more than needed. Scope run.invoker to a single service when possible rather than the whole project, so a leaked credential can only call what it was meant to call.

The request timeout is the longest time Cloud Run waits for your container to return a response. The default is 300 seconds (5 minutes) and it can be raised up to 3600 seconds with --timeout.

The clock includes container startup time when the request triggers a cold start. If the response is not sent in time, Cloud Run ends the request and returns 504.

Long work such as exports or large file processing is better moved to a job or queued with Cloud Tasks than stretched over a very long request.

Run gcloud run deploy --source . from your project folder. Cloud Run uses Cloud Build to turn the code into a container, stores the image in Artifact Registry and deploys it.

If the folder has a Dockerfile, it is used. Otherwise Google Cloud buildpacks detect the language (Go, Node.js, Python, Java, .NET, Ruby or PHP) and build the image for you.

This is handy for prototypes. For production, teams usually build in a CI pipeline and deploy a tagged image so every release is traceable.

A Cloud Run revision runs as a service account, and that identity decides what Google Cloud APIs the code can call: Cloud Storage, Secret Manager, Pub/Sub, Cloud SQL and so on.

By default it is the Compute Engine default service account, which often holds broad permissions. Create a dedicated service account per service and grant only the roles it needs, then set it with --service-account.

The same identity is used to fetch ID tokens when the service calls other private Cloud Run services.

Set them at deploy time with --set-env-vars KEY=VALUE. Use --update-env-vars to change a few and --remove-env-vars to drop one. Any change creates a new revision.

Cloud Run also supplies reserved variables such as PORT, K_SERVICE, K_REVISION and K_CONFIGURATION, which you cannot override.

Keep passwords and API keys out of plain env vars in config files. Reference them from Secret Manager instead.

Because every change creates a new revision, a typo in a variable can be reverted by sending traffic back to the previous revision. You can also load values from a YAML file with --env-vars-file, which is cleaner than a long command line when a service has many settings.

Cloud Run supports any language because it runs containers. If your app compiles to a Linux binary or runs in a Linux image, it can run there, including Rust, Elixir, Deno and custom runtimes.

For source deploys and Cloud Run functions, Google Cloud buildpacks have first-class support for Go, Node.js, Python, Java, Kotlin, .NET, Ruby and PHP.

The only real requirement is following the container contract: listen on PORT for services or exit on completion for jobs.

Yes. Cloud Run supports WebSockets, HTTP/2 and gRPC, including streaming calls.

A WebSocket connection counts as one long request, so it is limited by the request timeout (up to 60 minutes) and then closed. Clients should be written to reconnect automatically.

Each open connection uses one slot of the instance concurrency, so size concurrency and memory for the number of simultaneous sockets. Session affinity can help keep a client on the same instance across reconnects.

Worker pools run containers that continuously process work without receiving HTTP requests. They are meant for pull-based workloads such as Kafka, Pub/Sub pull or queue consumers.

Unlike services, a worker pool has no public URL and is not scaled by request load. You set the instance count manually or with an external autoscaler, and instances are billed while they run.

Worker pools also support Direct VPC egress and ingress, so private systems in your VPC can reach them on a private IP.

Cloud Run deploys containers, while Cloud Functions deploys functions written against a framework with a single entry point. Google has since folded the second generation into Cloud Run as Cloud Run functions, which build a function into a container and run it on Cloud Run.

Pick Cloud Run when you need a custom runtime or an existing container. Pick functions when a small handler is enough.

Choose Cloud Run for stateless HTTP, gRPC or batch workloads where you want no cluster to manage, scale-to-zero and per-use billing.

Choose GKE when you need Kubernetes features Cloud Run does not expose: StatefulSets, DaemonSets, custom operators and CRDs, fine-grained network policies, node-level tuning or complex multi-container scheduling.

Many teams start on Cloud Run and move a service to GKE only when a concrete limit appears.

A service listens for requests and stays available at a URL, scaling instances with traffic. A job runs its tasks to completion and then stops; it has no URL and does not wait for requests.

If an HTTP request would take longer than a user will wait, trigger a job and return immediately.

Cloud Run adds instances when incoming requests would push existing ones past their limit. It looks mainly at request concurrency and CPU utilization and starts more instances before they are fully saturated.

Scaling is bounded by --min-instances and --max-instances. With a minimum of zero, instances that stay idle are eventually shut down.

While a new instance starts, waiting requests are queued briefly. If capacity does not arrive in time, they fail with an error, so cold start time and concurrency both shape how smoothly a spike is absorbed.

For example, with concurrency 80 and a sudden jump to 400 simultaneous requests, Cloud Run needs roughly five instances and starts the missing ones immediately. Keeping startup short matters because those new instances only help once they pass the startup probe.

Under request-based billing (the default), CPU is allocated and billed only while the instance is processing requests, rounded up to the nearest 100 ms, plus a small per-request fee. Outside requests, CPU is throttled.

Under instance-based billing, CPU is always allocated and you pay for the whole lifetime of the instance, with no per-request fee.

Choose instance-based when the app does work outside requests or traffic is constant enough that the per-request fee adds up.

Cold starts come from image pull, container boot and app initialization, so you attack each part:

1. Set --min-instances to keep warm instances ready.
2. Enable startup CPU boost (--cpu-boost) so initialization gets extra CPU.
3. Use a smaller base image and fewer layers so the pull is faster.
4. Defer heavy work such as large model loads or cache warm-up until after the server is listening, or load lazily.
5. Reuse clients (database, HTTP) as globals instead of creating them per request.
6. Try the first generation execution environment if your app does not need full Linux compatibility, since it usually starts faster.

Measure first using startup latency in Cloud Monitoring, because the bottleneck is often application code rather than the platform.

The execution environment is the sandbox your container runs in. You choose it with --execution-environment.

If an app fails with a missing syscall or needs NFS or Cloud Storage volume mounts, use gen2. If you only serve HTTP and care about startup time, gen1 may be enough.

A service can send traffic to several revisions at once. You assign percentages that add up to 100, and Cloud Run distributes requests accordingly.

gcloud run services update-traffic orders-api \
  --to-revisions orders-api-00012-xyz=90,orders-api-00013-abc=10

Use --to-latest to send all traffic to the newest revision. Revisions can also get tags, which create a dedicated URL for testing a revision directly without giving it any percentage of live traffic.

Splitting is per request, not per user, unless you enable session affinity so a client tends to stay on the same revision.

A typical use is a 90/10 split between a stable and a new revision while you compare error rates. Percentages apply to the whole service, so a revision at 10% still gets about one request in ten even if it has a tag URL as well.

Deploy the new revision without sending it traffic, test it through a tag URL, then shift traffic in steps.

1. Deploy with --no-traffic --tag canary.
2. Test the tagged URL with real calls and smoke tests.
3. Send a small share, for example 5%, using update-traffic --to-revisions.
4. Watch error rate and latency in Cloud Monitoring.
5. Increase to 25%, 50% and then 100% if the metrics stay healthy.

gcloud run deploy api --image IMAGE --no-traffic --tag canary

If metrics worsen, set the previous revision back to 100% and the canary disappears from live traffic immediately.

Send traffic back to the last good revision. Because revisions are immutable, this takes effect within seconds and needs no rebuild.

gcloud run services update-traffic orders-api \
  --to-revisions orders-api-00012-xyz=100

Find the revision name with gcloud run revisions list --service orders-api. If the service was pinned to --to-latest, a rollback also needs traffic pinned to a named revision, otherwise the next deploy will take traffic again.

Check the result by calling the service and confirming the old behavior is back. Afterwards, fix the bug, deploy a new revision with --no-traffic and promote it deliberately, so the same problem does not return through an automatic deploy to latest.

Keep the target service private and let callers authenticate with Google-signed ID tokens.

1. Remove public access so the target requires authentication.
2. Grant the caller's service account roles/run.invoker on the target service.
3. In the caller, fetch an ID token from the metadata server with the target URL as the audience.
4. Send it as Authorization: Bearer TOKEN.

import google.auth.transport.requests, google.oauth2.id_token, requests
target = "https://billing-abc123-uc.a.run.app"
token = google.oauth2.id_token.fetch_id_token(google.auth.transport.requests.Request(), target)
r = requests.get(target + "/invoices", headers={"Authorization": f"Bearer {token}"})

Cloud Run checks the token signature, audience and IAM permission before the request reaches your code.

Store secrets in Secret Manager and reference them from the service rather than baking them into the image or plain env vars.

The service account needs roles/secretmanager.secretAccessor. Pin a numbered version for repeatable deployments. Using latest with a file mount lets you rotate a secret without a redeploy, while an env var secret only changes on new instances.

Never print secret values in logs and avoid putting them in the container image or build arguments, since both are easy to leak. Rotating a secret means adding a new version in Secret Manager and then deploying a revision that points to it, unless the service reads the latest version from a mounted file.

Cloud Run itself runs outside your VPC, so you add a path in. There are two options: Direct VPC egress and a Serverless VPC Access connector.

Both let the service reach private IPs such as a Memorystore Redis instance or an internal API. The --vpc-egress flag controls whether only private ranges or all outbound traffic goes through the VPC.

Use private-ranges-only to keep public API calls on the default path, or all-traffic when egress must pass through Cloud NAT with a fixed IP or through firewall rules.

flowchart LR
  A["Cloud Run instance"] -->|Direct VPC egress or connector| B["VPC subnet"]
  B --> C["Memorystore / Cloud SQL private IP"]
  B --> D["Cloud NAT with static IP"]
  D --> E["Third-party API allowlist"]

Both give Cloud Run outbound access to a VPC. The difference is how.

Direct VPC egress is the simpler default for new services. A connector still makes sense for older setups or where its behavior is already relied on.

There are two common routes.

1. Built-in connector over a unix socket: deploy with --add-cloudsql-instances PROJECT:REGION:INSTANCE. Your app connects to /cloudsql/PROJECT:REGION:INSTANCE.
2. Private IP: give the service VPC access and connect to the instance's private address like any other host.

The service account needs roles/cloudsql.client. Keep the database password in Secret Manager.

Remember that each instance opens its own pool. Cap --max-instances and pool size so total connections stay under the database limit.

For local development, the Cloud SQL Auth Proxy gives the same socket-style connection, so the connection string in code can stay almost identical between your laptop and Cloud Run. Use IAM database authentication where your engine supports it to avoid passwords entirely.

The --ingress setting decides which network paths can reach the service, before IAM is even checked.

Use internal-and-cloud-load-balancing when you want Cloud Armor or a custom domain in front and no direct run.app access. Ingress and IAM are separate layers, so a public service still needs allUsers as invoker.

Use internal for private backends that only other services in your project call, such as an internal pricing API. Changing ingress creates a new revision, so test the new value on a tagged revision before moving all traffic to it.

A global external Application Load Balancer with a serverless NEG adds features Cloud Run does not offer by itself.

• Cloud Armor for WAF rules and rate limiting.
• Cloud CDN to cache responses.
• A custom domain with managed certificates and a single anycast IP.
• Multi-region routing across Cloud Run services in different regions.
• Identity-Aware Proxy for user sign-in.

Pair it with --ingress internal-and-cloud-load-balancing so users cannot skip the load balancer through the run.app URL. For a simple internal tool, the default URL is enough.

One more reason is a stable set of anycast IP addresses, which partners sometimes need for firewall allowlists. Keep in mind the load balancer adds its own cost and one more hop to debug, so only add it when one of these features is required.

Once every allowed instance is at its concurrency limit, new requests cannot start more capacity. Cloud Run keeps them in a short queue, and if no slot opens in time they are rejected, usually with a 429.

Callers see errors even though the service is healthy, so it looks like an outage under load.

1. Raise --max-instances or the project quota if downstream systems can cope.
2. Raise --concurrency if the app can handle more parallel requests.
3. Speed up requests so slots free faster.
4. Buffer bursts with Cloud Tasks or Pub/Sub instead of direct calls.

A 504 means the container did not send a response within the request timeout. The clock includes container startup when the request triggered a cold start.

Common causes:

• Slow downstream calls with no client timeout, such as a database or third-party API.
• Heavy work done inline, like exports or image processing.
• A cold start that eats most of the timeout.
• Timeout left at the 300 second default while the work needs longer.

Fix it by adding timeouts and retries to downstream calls, moving long tasks to jobs or Cloud Tasks, and raising --timeout only when the work truly needs it.

The typical error says the container failed to start and listen on the expected port. Work through these checks:

1. Open the revision's logs in Cloud Logging and read the last lines before the crash.
2. Confirm the app listens on 0.0.0.0:$PORT, not 127.0.0.1 or a fixed port.
3. Run the image locally with docker run -e PORT=8080 -p 8080:8080 IMAGE.
4. Check for missing environment variables, secrets or permissions that crash the app at startup.
5. Verify the image is built for 64-bit Linux and the entrypoint is correct.
6. If startup is slow, extend the startup probe or enable CPU boost.

Most failures are a wrong bind address, a missing secret or a crash in startup code.

A service only runs when requests arrive, so events are delivered to it over HTTP.

Return a 2xx status only after the work is done, or the sender will retry. Make handlers idempotent since delivery is at least once. For continuous pull-based consumers, use a worker pool instead.

For example, an upload to a bucket can trigger Eventarc, which calls a Cloud Run service to generate thumbnails. If the handler returns a 5xx, the event is redelivered, so use a unique event or object ID to ignore duplicates and send repeated failures to a dead-letter topic.

When Cloud Run stops an instance, for example on scale-in or a new deploy, it sends SIGTERM to the container. You then have about 10 seconds before it sends SIGKILL.

Use that window to stop accepting new work, finish in-flight requests, flush buffers and close database connections.

process.on('SIGTERM', () => {
  server.close(() => { db.end().then(() => process.exit(0)); });
});

Anything that needs longer, such as a long job step, should be checkpointed so another instance can resume it.

Test this locally by running the container and sending docker stop, which also delivers SIGTERM. A handler that ignores the signal gets killed mid-request, which clients see as connection resets during deploys and scale-in. Log a short message when the handler starts so you can confirm it ran.

The container filesystem is writable but in-memory. Files you write count against the instance memory limit and disappear when the instance stops, and they are not shared between instances.

For data that must survive or be shared, use an external store:

• Cloud Storage, through the client library or a mounted bucket volume.
• NFS shares such as Filestore, mounted as a volume.
• A database such as Cloud SQL or Firestore for structured data.

Treat local disk as scratch space only, and delete temporary files after use so they do not exhaust memory.

A bucket mounted as a volume works through Cloud Storage FUSE, so it behaves like a folder but is not a full POSIX file system. It suits reading shared assets or writing finished output, and it is a poor fit for databases or heavy random writes.

Probes let Cloud Run check container health beyond just starting the process.

A startup probe decides when the instance is ready to receive traffic. The default is a TCP check on the container port. You can switch to an HTTP or gRPC check against a path such as /healthz, with delay, period and failure threshold settings.

A liveness probe runs after startup. If it keeps failing, Cloud Run restarts the container.

Use a startup probe for apps with slow initialization so no request arrives before caches or models are loaded, and a liveness probe to recover from deadlocks.

Keep the health endpoint cheap. It should confirm the process is alive, and for readiness it can check only local state. If it calls the database on every probe, a short database outage can make Cloud Run restart every healthy instance and make the incident worse.

Start with the defaults, then load test and adjust using metrics.

1. Run a load test, for example with hey or k6, at realistic traffic.
2. Watch CPU and memory utilization and request latency in Cloud Monitoring.
3. If CPU stays low and latency is fine, raise --concurrency so fewer instances serve the same load.
4. If latency climbs with load, lower concurrency or add CPU.
5. Match runtime settings: for example set worker threads in Gunicorn or the thread pool in Java to fit the concurrency value.

A single vCPU with high concurrency suits I/O-bound apps. CPU-bound work does better with more vCPUs and lower concurrency. Memory must fit all in-flight requests at once.

Costs come from CPU, memory and request counts, so reduce each where it is safe.

• Right-size CPU and memory using real utilization instead of guesses.
• Raise concurrency so fewer instances handle the same traffic.
• Keep request-based billing for bursty services and use min instances only where latency demands it.
• Set max instances as a guardrail against runaway spend.
• Cache responses with Cloud CDN to cut requests.
• Move batch work to jobs that run only when needed.
• Review committed use discounts for steady baseline load.

Check billing reports by service regularly, since a forgotten min-instances setting is a common small leak.

Cloud Run integrates with Google Cloud's observability tools without extra agents.

Set alerts on 5xx rate, p95 latency and instance count nearing the max. Write structured logs with a trace ID so one request can be followed across services.

A useful starting dashboard has request count, 5xx percentage, p50 and p95 latency, instance count and memory utilization on one page. Add a log-based metric for known error messages so recurring application failures show up as a chart instead of a search.

A request enters Google's front end, is authenticated and routed, and either lands on a ready instance or waits for a new one.

sequenceDiagram
  participant C as Client
  participant G as Google Front End
  participant R as Cloud Run Router
  participant I as Container Instance
  C->>G: HTTPS request
  G->>R: Check ingress and IAM
  alt Instance has free concurrency
    R->>I: Forward HTTP request
  else No capacity
    R->>I: Start new instance, queue request
    I-->>R: Startup probe passes
    R->>I: Forward queued request
  end
  I-->>C: Response before timeout

1. TLS terminates at Google's edge and the host is matched to the service.
2. Ingress and IAM checks run.
3. The router picks an instance with spare concurrency, or starts one and queues the request briefly.
4. The container handles the request and replies within the timeout.

Delays show up as cold start latency, a 429 when capacity is capped or a 504 when the response is late.

A source deploy chains several managed steps.

flowchart TD
  A["gcloud run deploy --source"] --> B["Upload source to Cloud Build"]
  B --> C{Dockerfile present?}
  C -->|Yes| D["Docker build"]
  C -->|No| E["Buildpacks detect language"]
  D --> F["Push image to Artifact Registry"]
  E --> F
  F --> G["Create new revision"]
  G --> H{Startup probe passes?}
  H -->|Yes| I["Route traffic to revision"]
  H -->|No| J["Revision fails, old one keeps serving"]

If the new revision fails its startup check, the previous revision keeps serving traffic, so a bad image does not cause downtime. With --no-traffic, the final routing step is skipped until you shift traffic yourself.

A single Cloud Run service lives in one region, so high availability across regions means deploying the same service in several regions and routing between them.

1. Deploy identical revisions to two or more regions, for example us-central1 and europe-west1.
2. Create a serverless NEG per region and attach them to one backend service on a global external Application Load Balancer.
3. Let the load balancer send users to the closest healthy region and fail over when one stops responding.
4. Use ingress internal-and-cloud-load-balancing so traffic always goes through the load balancer.

The data layer must match the design. Use multi-region or replicated stores such as Spanner, Firestore or multi-region buckets, or the stateless front end will fail over while its database does not.

Test failover regularly by draining one region and watching latency and error rates in the other.