Question 1

What is Cloud Run?

Accepted Answer

Cloud Run is a fully managed serverless platform that runs stateless containers. You supply a container image that listens on the port given by the PORT environment variable; Cloud Run handles provisioning, TLS, scaling from zero to thousands of instances, and billing per 100 milliseconds of usage. It supports HTTP, gRPC, WebSockets and event-driven invocation. The framing that scores is "any language, any library, as long as it is in a container and listens on a port" — that container freedom is what distinguishes it from Cloud Functions and from App Engine standard. Mentioning that it is built on Knative-compatible APIs shows depth.

Question 2

What is a Cloud Run revision?

Accepted Answer

A revision is an immutable snapshot of a service's container image plus its configuration — environment variables, CPU and memory, concurrency, scaling bounds, service account. Every deployment creates a new revision, and traffic is then assigned to revisions by percentage, which is what makes canary releases and instant rollback trivial. Immutability is the whole design. Because you cannot mutate a revision, "rollback" is just moving 100% of traffic back to the previous revision — it takes seconds and requires no rebuild. That is the answer interviewers want when they ask how you would recover from a bad deploy.

Question 3

How does Cloud Run concurrency work and why does it matter?

Accepted Answer

Concurrency is the maximum number of simultaneous requests a single container instance will handle, defaulting to 80 and configurable up to 1000, or 1 to force one request per instance. Higher concurrency means fewer instances for the same traffic, which lowers cost and reduces cold starts, but requires your application to be genuinely thread-safe and to have enough CPU and memory headroom. This is the single biggest difference from AWS Lambda, which is strictly one request per instance. The tuning insight: if your handler is I/O-bound, raise concurrency; if it is CPU-bound, lower it, because many concurrent CPU-bound requests on one instance just queue behind the CPU limit and inflate latency.

Question 4

What is a cold start on Cloud Run and how do you reduce it?

Accepted Answer

A cold start is the latency incurred when a request arrives and no warm instance exists, so Cloud Run must pull the image, start the container and wait for the app to be ready. You reduce it by setting minimum instances above zero, shrinking the image, deferring heavy initialisation, using startup CPU boost, and raising concurrency so fewer new instances are needed. The cost trade-off is the point: minimum instances remove cold starts but you pay for idle instances continuously, which partly defeats scale-to-zero. Startup CPU boost is the detail that marks recent experience — it temporarily grants extra CPU during startup, which helps JIT-heavy runtimes like Java and .NET considerably.

Question 5

What is the difference between "CPU always allocated" and "CPU allocated only during request processing"?

Accepted Answer

By default, CPU is only allocated while a request is being handled, so background work between requests is throttled almost to a stop and you are billed only for request time. With CPU always allocated, the instance keeps CPU for its whole lifetime, which is required for background processing, in-process schedulers, or streaming work outside a request, and is billed for the full instance lifetime. This explains a very common bug: an async task started in a request handler appears to hang or never complete, because CPU was withdrawn the moment the response was sent. Recognising that symptom immediately is a strong signal.

Question 6

What is the difference between Cloud Run services and Cloud Run jobs?

Accepted Answer

A service handles requests and scales on incoming traffic; it must listen on a port and is expected to run indefinitely. A job runs a container to completion — a batch task, migration or scheduled processing — with configurable task count, parallelism, retries and a task timeout, and does not serve traffic. The array-job capability is worth naming: a job can run many tasks in parallel, each receiving a CLOUD_RUN_TASK_INDEX, which makes it a natural fit for sharded batch work without any orchestration. Before jobs existed, people abused services with long timeouts, which is the anti-pattern to contrast against.

Question 7

How does Cloud Run autoscale?

Accepted Answer

Cloud Run scales instance count based on incoming request rate and the configured concurrency, plus CPU utilisation. It can scale to zero when idle and up to a configurable maximum, defaulting to 100. Scaling is very fast because it is starting containers rather than VMs, and you can set both minimum and maximum instances. The maximum-instances setting is a cost guardrail *and* a downstream protection: without it, a traffic spike can open thousands of connections to a Cloud SQL instance that only supports a few hundred, taking the database down. Naming that second reason is what makes the answer senior.

Question 8

How do you connect Cloud Run to a Cloud SQL database?

Accepted Answer

Either through the built-in Cloud SQL connection, which runs the Cloud SQL Auth Proxy for you over a Unix socket and authenticates with IAM, or over private IP through Direct VPC egress or a Serverless VPC Access connector. The service account needs roles/cloudsql.client, and connections should be pooled with a small per-instance pool because instance count multiplies connections. The connection-exhaustion arithmetic is the real question: max instances times pool size must stay below the database connection limit. Answering with pool sizing and max-instances together, rather than just naming the proxy, is what an interviewer is checking for.

Question 9

What is Serverless VPC Access and how does Direct VPC egress differ?

Accepted Answer

A Serverless VPC Access connector is a managed set of instances that bridges serverless products into your VPC so they can reach private IPs. Direct VPC egress is the newer approach where the Cloud Run service is given interfaces in your VPC directly, with no connector to size or pay for, giving lower latency, higher throughput and simpler scaling. The practical reason to prefer Direct VPC egress is that connectors had to be capacity-planned and became a bottleneck and a cost line of their own. Knowing the connector's throughput scaled with instance size and count — and that this was a real operational annoyance — signals genuine experience.

Question 10

How do you secure a Cloud Run service so only specific callers can invoke it?

Accepted Answer

Remove allUsers from the invoker role and grant roles/run.invoker only to the specific service accounts or groups that should call it. Callers then present a Google-signed ID token, which Cloud Run validates before the request reaches your container. For public services fronted by a load balancer, add Cloud Armor and optionally Identity-Aware Proxy. The key architectural point is that authentication happens *before* your code runs, so an unauthorised request never consumes your compute. For service-to-service calls the caller fetches an ID token from the metadata server with the target service URL as the audience — being able to describe that flow concretely is what distinguishes a strong answer.

Question 11

What is the Cloud Run request timeout and what is the maximum?

Accepted Answer

The default request timeout is 5 minutes and it can be raised to 60 minutes for services. Beyond that, the work does not belong in a request — it belongs in a Cloud Run job, a Pub/Sub-driven worker, or Workflows for orchestration. The design point to add is that a long HTTP request is fragile regardless of the platform limit: clients time out, load balancers drop connections, and retries duplicate work. The correct pattern is to accept the request, enqueue the work, return 202 with a status URL, and process asynchronously.

Question 12

How is Cloud Run billed?

Accepted Answer

In the request-based model you pay for vCPU and memory only while a request is being processed, rounded to 100 millisecond granularity, plus a per-request fee — so an idle service costs nothing. In the instance-based model, used when CPU is always allocated or minimum instances are set, you pay for the instance's whole lifetime with no per-request fee. The free tier makes small services genuinely free, which is why Cloud Run is such a strong default for low-traffic internal tools. The comparison to make is against a GKE node or an always-on VM, which cost the same whether they serve one request a day or a million.

Question 13

What is Eventarc and how does it relate to Cloud Run?

Accepted Answer

Eventarc routes events from more than 100 GCP sources — Cloud Storage finalise, Pub/Sub messages, Firestore changes, and any service with audit logs — to a target such as a Cloud Run service, in the standard CloudEvents format. It gives you a uniform event layer rather than per-service trigger plumbing. The reliability detail: Eventarc uses Pub/Sub underneath for many sources, so delivery is at-least-once and handlers must be idempotent. Audit-log-based triggers have noticeably higher latency than direct sources, which matters when someone expects sub-second reaction times.

Question 14

What is App Engine and how do the standard and flexible environments differ?

Accepted Answer

App Engine is GCP's original PaaS. The standard environment runs your code in a Google-managed sandbox with specific supported runtimes, scales to zero very quickly and has strict limits on what the code may do. The flexible environment runs your app in a container on Compute Engine VMs, supports any runtime and background processes, but does not scale to zero and has slower deployments. The current guidance to state plainly: for new work, Cloud Run supersedes App Engine flexible almost entirely and covers most of standard's use cases with more portability. App Engine remains relevant for existing applications and for teams that value its integrated services like Task Queues and traffic splitting.

Question 15

When would you still choose App Engine over Cloud Run?

Accepted Answer

When you already run on App Engine and migration has no business case; when you want the tightly integrated legacy services such as the App Engine Cron, Task Queue and Memcache APIs; or when the team wants to deploy source code with no container build step at all. Otherwise Cloud Run is the better default for portability and pricing. Interviewers ask this to see whether you recommend rewrites reflexively. Saying "it works, it is supported, and the migration cost is not justified" is a legitimate and mature engineering answer, provided you can also name what you would gain by moving.

Question 16

How do you do a blue-green or canary deployment on Cloud Run?

Accepted Answer

Deploy the new revision with --no-traffic and a tag, which gives it a unique testable URL without receiving production traffic. Validate against that URL, then shift traffic gradually with update-traffic — 5%, 25%, 100% — watching error rate and latency. Rollback is a single command pointing 100% of traffic back at the previous revision. The tagged-revision URL is the feature that makes this genuinely better than most alternatives: you can smoke-test the exact artefact that will serve production, in production, with zero blast radius. Automating the promotion on SLO metrics with Cloud Deploy is the natural follow-up.

Question 17

What are the Cloud Run container contract requirements?

Accepted Answer

The container must listen for HTTP on the port supplied in the PORT environment variable (default 8080) on 0.0.0.0, must start within the startup timeout, must be stateless because instances are ephemeral and the filesystem is in-memory, and must be built for linux/amd64 unless you explicitly target arm64. Two failures that come straight out of this contract: hardcoding port 3000 and getting a startup failure, and building on an Apple Silicon Mac without specifying the platform, producing an arm64 image that will not start. Naming the second one is an instant credibility marker.

Question 18

Is the Cloud Run filesystem writable?

Accepted Answer

The container filesystem is writable but it is in-memory, so anything written counts against the instance's memory limit and disappears when the instance is recycled. For durable storage use Cloud Storage; for a shared POSIX filesystem, Cloud Run supports mounting a Cloud Storage bucket or a Filestore share as a volume. The failure mode to name is a service that writes temporary files and is eventually OOM-killed, because the engineer assumed /tmp was disk. It looks like a memory leak and is actually accumulated temp files.

Question 19

How do you schedule recurring work on Cloud Run?

Accepted Answer

Use Cloud Scheduler to invoke a Cloud Run service endpoint or trigger a Cloud Run job on a cron schedule, authenticating with an OIDC token so the endpoint stays private. For workflows with several steps, dependencies and retries, use Workflows to orchestrate rather than chaining schedulers. The security detail that matters: attach a service account to the Cloud Scheduler job and grant it run.invoker, so the endpoint is not public. A cron endpoint left open to the internet is a classic finding in a security review.

Question 20

What is the difference between Cloud Run and Cloud Functions today?

Accepted Answer

They have converged: Cloud Functions 2nd gen is built on Cloud Run and Eventarc, so it inherits Cloud Run's concurrency, timeouts and scaling. The remaining difference is the developer experience — Cloud Functions deploys a function from source with the runtime and HTTP plumbing supplied for you, while Cloud Run deploys a container you control entirely. The honest summary is "Cloud Functions is a packaging convenience on top of Cloud Run". Choose functions for small event handlers where you do not want a Dockerfile, and Cloud Run when you need control over the image, want multi-endpoint services, or care about portability.

Question 21

How do you put a custom domain and CDN in front of Cloud Run?

Accepted Answer

Create a global external Application Load Balancer with a serverless network endpoint group pointing at the Cloud Run service, attach a Google-managed SSL certificate for your domain, enable Cloud CDN on the backend service, and add Cloud Armor for WAF and rate limiting. Cloud Run domain mappings also exist but are more limited and not available in every region. The load-balancer route is the production answer because it is the only one that gives you Cloud Armor, CDN, multi-region routing and IAP. Suggesting only the domain mapping signals you have only used Cloud Run for simple projects.

Question 22

What is Cloud Armor and why pair it with Cloud Run?

Accepted Answer

Cloud Armor is Google's WAF and DDoS protection applied at the load balancer, supporting IP allow and deny lists, geo-based rules, preconfigured OWASP Top 10 rule sets, rate limiting and bot management. Pairing it with Cloud Run means malicious traffic is dropped at the edge before it can spin up instances and cost you money. The cost-of-attack angle is the compelling one for serverless specifically: without a rate limit, an attacker can drive autoscaling and generate a bill. That connection between security control and financial exposure is exactly the reasoning senior interviewers look for.

Question 23

How do you pass secrets to a Cloud Run service?

Accepted Answer

Reference a Secret Manager secret directly in the service configuration, either as an environment variable or mounted as a file, and grant the service's service account roles/secretmanager.secretAccessor. You can pin a specific version or use "latest" — pinning is safer because rotating "latest" changes behaviour on the next instance start without a deploy. The anti-pattern to name is plain environment variables containing secrets, which are visible in the service description to anyone with viewer access and end up in deployment scripts and CI logs. The latest-versus-pinned nuance is a good detail that shows operational thinking.

Question 24

Your Cloud Run service shows high tail latency but low average latency. How do you investigate?

Accepted Answer

Check cold starts first — instance count churn against request rate — then look at concurrency saturation, where requests queue on an instance already at its concurrency limit with insufficient CPU. Use Cloud Trace to find where time is actually spent, check downstream dependencies such as a database connection pool, and look at whether the container is CPU-throttled between requests. The systematic answer distinguishes three distinct causes with different fixes: cold starts fixed with minimum instances, queueing fixed by lowering concurrency or raising CPU, and downstream latency fixed elsewhere entirely. Jumping straight to "add more instances" without diagnosing is the weak answer.

Question 25

What is a sidecar container on Cloud Run?

Accepted Answer

Cloud Run supports multiple containers in one service: one ingress container that serves traffic on the PORT, plus sidecars sharing the same network namespace and optional volumes. Typical uses are a logging or metrics agent, a proxy such as the Cloud SQL Auth Proxy, or an Envoy sidecar for a mesh. This capability materially narrowed the gap with Kubernetes, because "we need a sidecar" used to be a reason to choose GKE. Knowing that only one container can receive ingress traffic, and that all containers share the instance's CPU and memory allocation, is the detail that shows real use.

Question 26

How do you build container images for Cloud Run without writing a Dockerfile?

Accepted Answer

Use Cloud Buildpacks — gcloud run deploy --source . detects the language, builds an OCI image with sensible, patched base layers and pushes it to Artifact Registry automatically. Buildpacks also rebuild only the layers that changed and let you patch the OS layer without rebuilding the application. The security argument is the strong one: buildpack base images are maintained and patched by Google, whereas a hand-written Dockerfile pinned to an old base image quietly accumulates CVEs. The trade-off is less control, which matters for unusual native dependencies.

Question 27

What is Artifact Registry and why did it replace Container Registry?

Accepted Answer

Artifact Registry is the managed repository for container images and language packages — Maven, npm, Python, Go, Debian, RPM — with regional storage, fine-grained IAM per repository, CMEK support, and integrated vulnerability scanning. It replaced Container Registry, which was a thin layer over Cloud Storage with only bucket-level access control. The concrete improvement to name is per-repository IAM: with Container Registry you effectively controlled access with a GCS bucket policy, so separating team A's images from team B's was awkward. Regional repositories also reduce pull latency and egress compared with a multi-region bucket.

Question 28

How would you handle a long-running import triggered from a web request on Cloud Run?

Accepted Answer

Do not process it in the request. Accept the upload, write it to Cloud Storage, publish a message to Pub/Sub or create a Cloud Tasks task, and return 202 with a job identifier. A Cloud Run job or a push-subscription worker service then processes it with its own timeout and retry policy, and the client polls for status. This is a design-judgement question and the failure is answering "raise the timeout to 60 minutes". Interviewers want the queue-and-acknowledge pattern, idempotency on retries, and a status mechanism — the same pattern regardless of cloud.

Question 29

What is Cloud Tasks and how does it differ from Pub/Sub?

Accepted Answer

Cloud Tasks is a managed task queue giving you explicit per-task control: scheduled execution time, per-queue rate limiting and concurrency control, retry configuration per task, and deduplication by task name. Pub/Sub is a fan-out messaging system optimised for high-throughput streaming to many subscribers. The selection rule: use Cloud Tasks when you need to control the rate at which work hits a downstream system — protecting a legacy API or a database — and Pub/Sub when you need decoupled event distribution at scale. The named-task deduplication in Cloud Tasks is genuinely useful and often forgotten.

Question 30

What is Workflows and when would you use it instead of chaining services?

Accepted Answer

Workflows is a serverless orchestrator defined in YAML or JSON that calls HTTP endpoints and GCP APIs in sequence or parallel, with built-in retries, error handling, conditionals and long waits, and full execution history. Use it when a business process has multiple steps that must be observable and recoverable rather than buried in code across several services. The value over chaining Pub/Sub-triggered services is visibility: a failed workflow shows you exactly which step failed and with what payload, whereas a chain of event handlers requires you to reconstruct the flow from logs. Interviewers ask this to test whether you distinguish choreography from orchestration.

Question 31

How do you achieve multi-region high availability with Cloud Run?

Accepted Answer

Deploy the same service to two or more regions and put a global external Application Load Balancer in front with a serverless NEG per region. The load balancer routes each user to the nearest healthy region automatically and fails over if a region becomes unhealthy. Data must also be regional-aware — a multi-region database like Spanner, or Cloud SQL with cross-region replicas and a defined failover. The compute half is easy; the data half is the real question. Any answer that stops at "deploy in two regions" without addressing where the database lives and what happens to writes during a regional failure is incomplete, and interviewers push on exactly that.

Question 32

What are Cloud Run's main limits you should design around?

Accepted Answer

Request timeout up to 60 minutes; maximum concurrency 1000 per instance; memory up to 32 GiB and CPU up to 8 vCPU per instance depending on configuration; request and response size limits; in-memory filesystem counting against memory; and default maximum instances of 100, which is raisable. Instances are ephemeral and can be recycled at any time. The one that shapes architecture most is ephemerality — no local state, no in-process cache you can rely on, no sticky sessions without configuring session affinity. Naming that as a design constraint rather than a number is what makes the answer useful.

Question 33

What is session affinity on Cloud Run and should you use it?

Accepted Answer

Session affinity makes a best-effort attempt to route requests from the same client to the same instance using a cookie. It helps with in-memory caching or in-progress uploads, but it is not a guarantee — instances are still recycled — and it undermines even load distribution. The right recommendation is to design stateless and externalise session state to Memorystore or Firestore, treating affinity as an optimisation rather than a correctness mechanism. Any answer that relies on affinity for correctness is a design smell an interviewer will probe.

Question 34

How does Cloud Run handle traffic during a deployment?

Accepted Answer

A new revision is created and health-checked before traffic moves. By default the new revision receives 100% of traffic once it is serving, and the old revision continues handling its in-flight requests until they finish before being scaled down. Because revisions are separate sets of instances, there is no in-place restart and no dropped connections when the app handles SIGTERM properly. The application-side requirement is graceful shutdown: on SIGTERM, stop accepting new work, finish in-flight requests and exit before the termination grace period. Services that ignore SIGTERM drop requests during every deploy and every scale-down, which is a subtle and common source of 5xx blips.

Question 35

What does the Cloud Run "internal traffic only" ingress setting do?

Accepted Answer

It restricts the service to receive requests only from resources inside your VPC network, from VPC Service Controls perimeters, or from other supported internal sources — the public URL stops working from the internet. There is also an "internal and Cloud Load Balancing" option that additionally permits traffic arriving through a load balancer. The pattern to describe: internal-only for backend services, with the public entry point being a single load-balanced frontend protected by Cloud Armor and IAP. This is the network-level complement to IAM invoker restrictions, and defence in depth means using both.

Question 36

How do you observe a Cloud Run service in production?

Accepted Answer

Cloud Run automatically emits request logs, container stdout and stderr logs, and metrics for request count, latency percentiles, instance count, container CPU and memory utilisation and billable time. Add Cloud Trace for distributed tracing, Error Reporting for grouped exceptions, and define SLOs with alerting on error-budget burn rate. The metric that most teams forget is container memory utilisation against the limit, because OOM kills show up as opaque 5xx responses. Alerting on instance count hitting the configured maximum is the other one — it means you are silently shedding load.

Question 37

What is the difference between Cloud Run gen1 and gen2 execution environments?

Accepted Answer

The first-generation environment uses a lightweight sandbox with very fast cold starts but partial Linux compatibility. The second generation runs full Linux compatibility with network file system support, faster CPU and network throughput for sustained work, but somewhat slower cold starts. The selection rule: gen1 for short, spiky, latency-sensitive request handling; gen2 when you need full system-call compatibility, large memory, or sustained throughput such as media processing. Knowing gen2 is required for mounting network filesystems is the practical trigger.

Question 38

How do you migrate a monolith running on Compute Engine to Cloud Run?

Accepted Answer

Containerise it first and run it unchanged on Cloud Run if it is stateless and HTTP-based. Then fix what breaks: externalise session state and local file writes, remove background threads or move to CPU-always-allocated, put the database behind Direct VPC egress with pooled connections, and shorten startup time. Only then consider decomposing it into services — the container move and the decomposition are separate projects. Separating "lift into Cloud Run" from "break into microservices" is the mature answer. Teams that attempt both simultaneously typically fail, and interviewers ask this to see whether you sequence risky work or bundle it.

Question 39

What is the App Engine traffic-splitting feature?

Accepted Answer

App Engine can split traffic across versions of a service by IP address, by cookie, or randomly, with configured percentages, so you can run A/B tests and gradual rollouts. Cookie-based splitting gives a consistent experience per user, which IP-based splitting does not when users move networks. It is a good reminder that App Engine pioneered several patterns Cloud Run later adopted. The cookie-versus-IP distinction is the substantive part — random splitting breaks any test that requires a user to see a consistent variant.

Question 40

Design a serverless e-commerce backend on GCP. Which services and why?

Accepted Answer

Cloud Run for the API behind a global Application Load Balancer with Cloud CDN and Cloud Armor; Firestore or Cloud SQL for the transactional store depending on relational needs; Memorystore for sessions and hot catalogue caching; Pub/Sub for order events with Cloud Run push subscribers for fulfilment, email and analytics; Cloud Tasks for rate-limited calls to payment and logistics partners; Cloud Storage plus CDN for product images with signed URLs for private assets; Secret Manager for credentials; and BigQuery for analytics fed by Pub/Sub and Dataflow. The closing architecture question. The differentiators are naming Cloud Tasks specifically for rate-limited third-party calls, requiring idempotency on Pub/Sub consumers, and separating the transactional store from the analytics store rather than querying production for reports.

GCP Cloud Run & App Engine Interview Questions and Answers

How to use this set