Google Cloud Platform interview questions

The correct statements are that App Engine Standard can scale to zero with automatic scaling and min_instances: 0, runs in a sandbox restricting capabilities like local filesystem writes, and requires choosing from supported runtime versions. Custom runtimes via Dockerfile are a feature of App Engine Flexible, not Standard.

Google Cloud Run is a managed compute platform that runs stateless containers and can automatically scale the number of serving instances down to zero when there is no incoming traffic.

60 minutes (5400 seconds)

GCP IAM has three role types. (1) Basic (a.k.a. primitive) roles — Owner, Editor, Viewer — are coarse, project-wide grants that predate fine-grained IAM. They are convenient but over-broad (Editor can change almost anything; Owner can also manage IAM), so they are discouraged for anything beyond small sandboxes or initial setup. (2) Predefined roles are service-specific, Google-curated bundles of permissions that follow least privilege — e.g. roles/storage.objectViewer, roles/bigquery.dataEditor, roles/pubsub.subscriber. These are the default choice: pick the narrowest predefined role that covers the task. (3) Custom roles are sets of individual permissions you assemble yourself when no predefined role fits the need precisely; they give the tightest least-privilege control but carry maintenance cost — you must update them as services add or rename permissions. Rule of thumb: avoid basic roles in production, prefer the narrowest predefined role, and create a custom role only when predefined roles are too broad or don't exist for the exact permission set you need.

In the Google Cloud operations suite (formerly Stackdriver), the service that collects metrics, dashboards, and alerting policies is Cloud Monitoring, while the service that ingests, stores, and lets you query log entries is Cloud Logging.

App Engine supports three scaling modes: automatic scaling (instances scale with traffic and latency targets), manual scaling (fixed instance count), and basic scaling (on-demand instances that shut down when idle). Predictive scaling is not a recognized App Engine scaling mode.

The primary, autoscaling compute abstraction is Google Cloud Functions—a serverless, event-driven execution environment where Google automatically provisions and scales compute resources in response to HTTP requests or cloud events, so you deploy code without managing servers or clusters.

The two supported runtime generations are 1st generation (Gen 1) and 2nd generation (Gen 2). Gen 2 is built on top of Cloud Run and Eventarc, offering enhanced performance, longer request timeouts (up to 60 minutes), larger instance sizes, up to 1,000 concurrent requests per instance, and broader event-source support compared to Gen 1.

Cloud Run is the best fit. It runs any container image, autoscales on request concurrency, scales down to zero when idle, and is fully managed with no node pool or control plane to operate. GKE can autoscale but is a full Kubernetes cluster — more operational surface than a single HTTP API needs, and standard node pools do not scale to zero. Cloud Functions is event/function-shaped rather than container-native. Pick the lightest service that satisfies the workload: container + request-driven + no ops points to Cloud Run.

BigQuery's split of storage from compute means storage and query compute scale and bill independently. Table data lives at rest in Google's distributed storage with no running cluster behind it, and a query allocates compute as slots on demand, then releases them. You never pre-size a fixed cluster to hold the data, and storage capacity is not capped by how much compute you buy. This is the opposite of a traditional MPP warehouse where data sits on always-on compute-node disks. The payoff is no idle cluster cost and elastic query compute.

True. Sustained-use discounts are automatic and commitment-free: the longer an eligible Compute Engine VM runs within a billing month, the larger the discount Google applies to that usage, with nothing to opt into. Committed-use discounts are the opposite trade — you commit upfront to a 1- or 3-year term for a steady amount of resources or spend, and in return get a deeper discount, but you pay for the commitment whether you use it or not. SUDs reward unplanned steady usage at no risk; CUDs reward a predictable baseline with a bigger discount and a contractual obligation.

A new revision is created from the v2 image but receives 0% of traffic; 100% still flows to api-001 until you explicitly shift traffic

Firestore is a serverless, horizontally-scaling NoSQL document database; Cloud SQL is managed relational (MySQL/PostgreSQL/SQL Server). Choose Firestore when you want automatic scaling with no instance to size, a flexible/evolving schema of documents and collections, real-time listeners and offline sync for mobile/web clients, and an access pattern dominated by key/document lookups. You give up rich relational features: multi-table SQL joins, complex ad-hoc queries and aggregations, and strong normalized-schema constraints — Firestore queries must be backed by indexes and avoid cross-collection joins, so you denormalize. Choose Cloud SQL when you need relational integrity, joins, transactions across many tables, complex reporting/analytics queries, or you are running an existing app that expects SQL. The trade there is operational and scaling: you size and manage an instance (CPU/RAM/disk), vertical scaling has a ceiling, and read scale-out means replicas rather than transparent horizontal scaling. Rule of thumb: document/real-time/elastic and lookup-shaped data fits Firestore; relational, join-heavy, transactional data fits Cloud SQL.

TrueTime makes it possible. It is a global clock built on GPS and atomic clocks that returns time as a tightly-bounded interval with known uncertainty. Spanner assigns each transaction a commit timestamp and waits out that uncertainty window before acknowledging, guaranteeing that a transaction starting after another commits gets a later timestamp. This delivers external, linearizable consistency across regions without routing every write through one coordinator and without eventual-consistency conflict resolution. It is why Spanner can offer relational, strongly-consistent SQL that still scales horizontally.

Service-account JSON keys are long-lived static secrets that stay valid until revoked, so a leaked or committed key is a standing breach. Workload Identity replaces them with short-lived tokens exchanged at runtime. On GKE it binds a Kubernetes service account to a Google service account, so pods get scoped credentials with no key mounted. Workload Identity Federation does the same for workloads outside GCP — AWS, on-prem, or CI exchange their own identity for a GCP token with no exported key. It changes how a workload authenticates, not what it is authorized to do, so you still grant least-privilege roles.

About 7/365 of the table — the filter on the partition column prunes to 7 daily partitions, so only those bytes are scanned and billed

Pub/Sub redelivers the message (default subscriptions are at-least-once), so it will be processed again — subscribers must be idempotent to tolerate duplicates

The member is allUsers, which grants read to anyone on the internet — it should be serviceAccount:[email protected] for the app's identity only

A GCP VPC network is global: a single VPC spans every region without needing VPNs or peering to connect regions, and it provides one routing domain and one firewall-rule namespace across the whole network. Subnets, by contrast, are regional: each subnet lives in one region and owns an IP range (CIDR) used by resources in that region. The practical consequence is that you can run resources in us-central1 and europe-west1 inside the same VPC, give each region its own regional subnet/CIDR, and they communicate over Google's private backbone using internal IPs with no inter-region VPN — firewall rules and routes defined at the VPC level apply globally. This simplifies multi-region architecture: one VPC, per-region subnets, internal connectivity by default. A related consequence is IP planning — because subnets are regional and own non-overlapping ranges, you allocate distinct CIDR blocks per region up front to avoid conflicts and leave room to grow. (Some load balancers and managed services are global too, which pairs naturally with the global VPC.)

The request flows edge-inward through the load balancer's chained components. First the global anycast IP and forwarding rule draw the user to the nearest Google edge POP. The forwarding rule hands off to a target HTTP(S) proxy, which terminates the connection and TLS. The proxy consults the URL map, which matches host and path to choose a backend service. The backend service applies its load-balancing policy and health checks to select a healthy backend. Finally the backend — a serverless NEG for Cloud Run or a managed instance group — serves the request.

False. App Engine Flexible cannot scale to zero instances — the minimum allowed value for min_num_instances is 1. This is because Flexible runs on Compute Engine VMs that are costlier and slower to start than Standard's lightweight instances, so the platform always keeps at least one VM alive. App Engine Standard, by contrast, supports min_instances: 0 and can fully scale to zero when idle.

True. App Engine's Cron Service sets the X-Appengine-Cron header internally, and the platform strips X-Appengine-* headers from external requests before they reach your handler. A handler that sees this header can trust the request came from the Cron Service. Google still recommends adding a secret token in the cron URL as defense-in-depth, but the header alone is a reliable signal.

The correct order is: Cloud Run provisions a new container instance → the Node.js process and Functions Framework initialize → module-scope global code executes → the exported entry point function is invoked with the request → the HTTP response is returned. Global code runs during module load, which happens once per instance, before any individual request handler is called.

Architecture Overview

Upload and Orchestration Layer (Cloud Run Services)

A Cloud Run service in each region serves as the API gateway. It accepts the upload via a signed-URL flow: the client requests an upload URL from the service, which generates a Cloud Storage signed URL with a short TTL, and the client uploads directly to a regional Cloud Storage bucket. This avoids streaming 2 GB through the Cloud Run container. The service then enqueues a render task onto Pub/Sub (or Cloud Tasks for per-task rate limiting) and returns immediately to the client with a job ID. A WebSocket or long-poll endpoint (or Firebase Realtime Database / Firestore listener) lets the client track progress.

Render Layer (Cloud Run Jobs)

The actual rendering is performed by Cloud Run jobs, not services. Rationale: render workloads are batch processes with no HTTP listener, can run longer than the service request timeout, and benefit from job-level retries and parallelism. Each render engine type gets its own job template:

• CPU-bound engine (e.g., CAD renderer): --concurrency is not applicable to jobs; instead, run one task per job execution, set CPU allocation to the maximum (e.g., 8 vCPU), memory to a modest 4 GiB, and set --task-timeout to a value below the SLA ceiling (e.g., 25 min for the 30-min SLA tier).
• Memory-bound engine (e.g., large PowerPoint with embedded media): Set memory to 16–32 GiB with 2–4 vCPU, and cap --parallelism so that concurrent tasks do not exceed available memory on the underlying node.
• Legacy crash-prone engine: Isolated in its own Cloud Run job with its own revision, a tight --task-timeout (e.g., 5 min), --max-retries=3, and a separate service account with minimal IAM scope. A wrapper script inside the container captures exit codes and writes a structured failure event to Pub/Sub. Because it is a separate job, a crash or OOM cannot consume the quota or instances of the healthy engines.

Large Image and Cold-Start Strategy

The 4–8 GB render-engine images are the biggest cold-start risk. Strategy:

1. Multi-stage Docker builds strip build tooling and debug symbols, targeting a distroless or Alpine base where the engine allows it. This can often cut image size by 40–60%.
2. Separate runtime data from the image: Ship only the engine binary in the image; download fonts, templates, and reference data from Cloud Storage at startup (mounted via Cloud Storage FUSE) or bundle them in a smaller companion layer.
3. Warmup during business hours: Set --min-instances on the API gateway service to 1 (or 2 for HA) during 06:00–20:00 local time via a scheduled Cloud Workflow that updates the service config, and drop to 0 outside business hours. For jobs, cold starts are less latency-sensitive (the client is async-waiting), but we can pre-trigger a no-op warmup job every 15 minutes during peak hours to keep the container layer cache warm on at least one node.
4. If image size remains problematic, split the monolithic image into a base image (engine binary, ~2 GB) stored in Artifact Registry with a regional replica in each deployment region, and a thin per-revision config layer.

Concurrency, Autoscaling, and Cost

• Cloud Run services (API gateway): --concurrency=80 (default), --min-instances=0 off-hours, --min-instances=2 peak hours for low-latency API responses. --max-instances capped per region to control blast radius.
• Cloud Run jobs: scale via --parallelism and --task-count. A Cloud Scheduler + Cloud Workflows orchestration submits batch job executions every minute, pulling available tasks from a Firestore-backed queue. When the queue is empty, no job is submitted — idle cost is zero.
• Use Cloud Run CPU allocation = always-on CPU only for jobs that need background processing within the container; for the API gateway, CPU is only billed during request handling (request-based CPU), which is cheaper for spiky traffic.
• Committed Use Discounts on the memory and vCPU for the predictable business-hours baseline, and scale-to-zero for everything else.

Multi-Region DR Design

Active-passive with warm standby in a second region. Rationale: active-active for render workloads doubles storage and compute cost and introduces cross-region job-deduplication complexity. Instead:

• Primary region (e.g., us-central1): API gateway, Pub/Sub, Cloud Storage primary bucket, Cloud Run jobs.
• Secondary region (e.g., europe-west1): API gateway deployed but scaled to --min-instances=0; Pub/Sub subscription with a dead-letter topic replicated; Cloud Storage bucket with turbo replication (or a CMEK-encrypted dual-region bucket) so RPO ≤ 5 min.
• Traffic failover: An external HTTP(S) Load Balancer with serverless NEGs to both regional Cloud Run services. Health checks probe the API gateway; on failure, the LB routes to the secondary. DNS is not needed for failover — the LB handles it in seconds, meeting RTO ≤ 15 min.
• In-flight job recovery: When a job fails or the region goes down, the Pub/Sub message is not acknowledged (or the Cloud Task retries). The secondary region's job execution picks up the same Pub/Sub subscription (or a replica), re-renders, and writes results to the secondary bucket. Idempotent job IDs prevent double-notification: the worker checks Firestore for a completion record before rendering.

Encryption Design

• In transit: All traffic uses TLS 1.2+ (Cloud Run enforces HTTPS). Signed URLs for Cloud Storage uploads/downloads use HTTPS. Inter-service calls use Google-managed mTLS via VPC connector or private services.
• At rest: CMEK (Customer-Managed Encryption Keys) via Cloud KMS on all Cloud Storage buckets, Artifact Registry, and Cloud Run revisions. Keys are rotated every 90 days. For the most sensitive customer data, CSEK (Customer-Supplied Encryption Keys) can be used on the upload bucket so even Google cannot read the raw files.
• Key replication: KMS key rings are deployed in both regions with the same key material (imported via EKM or replicated key rings) so the secondary region can decrypt objects without a cross-region KMS call.

Architecture Design

High-Level Flow

Pub/Sub (ingest topic) → Cloud Run (enrich+score service) → Pub/Sub (result topic)
                              ↓
                     Memorystore (Redis) — dedup
                              ↓
                     Cloud Spanner — user history
                              ↓
                     Vertex AI Endpoints — ML scoring

Cloud Run Service Configuration

• Service, not job: Each event is a request-response cycle. Cloud Run services are the right abstraction.
• Concurrency = 8: Each instance handles 8 concurrent requests. At 50k events/s, this yields ~6,250 concurrent requests. With each request taking ~150 ms (enrichment + scoring), we need ~6,250 × 0.15 = ~940 in-flight requests, which at concurrency 8 means ~118 instances. Set --max-instances=300 (with quota increase) to absorb bursts. Concurrency=1 would require ~6,250 instances — wasteful and quota-prohibitive. Concurrency=80 (default) would cause CPU contention on the Spanner/Vertex AI client threads, degrading P99.
• CPU = always-allocated (--cpu-boost or --no-cpu-throttling): The service makes synchronous gRPC calls to Spanner and Vertex AI; CPU throttling during I/O wait would inflate latency beyond the 200 ms budget.
• Memory = 1 GiB: The service is stateless aside from a small in-memory LRU cache (512 MB) for hot user IDs. Spanner results and Vertex AI responses are not buffered in memory.
• Request timeout = 250 ms: Set above the 200 ms P99 SLA to allow tail events to complete, but low enough that Pub/Sub push retries quickly rather than hanging.
• Min-instances = 0: Cost is zero when idle. Cold starts add ~2–5 s for the first request, but Pub/Sub push will retry, and the first batch of events will simply be delayed by one cold-start cycle — acceptable given the at-least-once model.

Pub/Sub Subscription Model

• Push delivery to the Cloud Run service endpoint. Rationale: push delivery lets Pub/Sub manage flow control and backpressure automatically — if Cloud Run returns 429 or 503, Pub/Sub slows down. Pull would require a separate poller and adds latency.
• Ack deadline = 30 s: Pub/Sub push waits for the HTTP response. A 200 means ack; a non-2xx or timeout means nack and redelivery. 30 s is generous enough for the 250 ms request timeout plus retries, but short enough that a failed region's messages are redelivered to another region within RTO.
• Dead-letter topic: max_delivery_attempts=10. After 10 failed deliveries, the message moves to a DLQ topic. A separate Cloud Run service consumes the DLQ, writes the payload to BigQuery for analysis, and can replay via a Pub/Sub publish back to the ingest topic after fixing the root cause.

Deduplication Strategy

• Primary: Memorystore (Redis) with SETNX + TTL. Each event carries a unique transaction_id. The worker does SET transaction_id NX EX 300 (5-minute TTL). If the key already exists, the event is a duplicate — skip scoring, but still publish the prior result (retrieved from a short-lived Redis result cache) to the result topic so downstream consumers are not blocked.
• Fronting LRU cache: An in-process LRU cache (Caffeine / functools.lru_cache) with 10k entries and 60-second TTL catches the hottest duplicates without a Redis round-trip. This keeps dedup latency under 1 ms for the common case.
• Fallback: If Redis is unavailable (connection error, failover), the worker falls back to a Spanner INSERT … ON CONFLICT DO NOTHING on a processed_events table keyed by transaction_id. This is slower (~5–10 ms) but correct. The circuit breaker for Redis (separate from the Vertex AI one) trips after 5 consecutive failures, switching all traffic to Spanner-based dedup.

Circuit Breaker and Vertex AI Fallback

• Sliding-window latency tracker: Each worker instance maintains a ring buffer of the last 100 Vertex AI response latencies. If the P99 of this window exceeds 500 ms, the circuit opens.
• Open state: The worker routes scoring to the rules-based fallback scorer (a lightweight in-process function using thresholds from Spanner user history: velocity, geo-distance, amount). The result is tagged score_engine=fallback so downstream consumers know the confidence level is lower. A Cloud Monitoring custom metric and alert fire immediately.
• Half-open state: Every 30 seconds, the worker sends 1% of traffic to Vertex AI (probe requests). If 10 consecutive probes return under 200 ms, the circuit closes and full traffic resumes.
• Budget enforcement: The fallback scorer runs in <5 ms, so the 200 ms P99 budget is easily met during degradation. The enrichment (Spanner lookup, ~10 ms) + fallback scoring (~5 ms) + dedup (~1 ms) + Pub/Sub publish (~5 ms) = ~21 ms total.
• Shared circuit state across instances: The circuit state is also written to Redis (or a lightweight Cloud Spanner counter) so that when one instance detects degradation, all instances switch quickly rather than each independently discovering the problem. However, each instance can also trip locally to avoid a Redis dependency in the critical path.

Poison-Message Handling

• Detection at ingress: The worker validates the event schema immediately upon deserialization. If the JSON is malformed, required fields are missing, or the transaction_id is absent, the worker publishes the raw event to the DLQ topic and returns HTTP 200 (ack) — this prevents Pub/Sub from endlessly redelivering the poison message.
• Unscorable events: If the Vertex AI endpoint returns a structured error (e.g., feature vector out of range), the event is published to a quarantine topic (distinct from the DLQ) with the error reason. A human-in-the-loop review service consumes the quarantine topic.
• Timeout = poison: If a single event causes three consecutive request timeouts (250 ms each), the worker publishes it to the DLQ and acks the original message. This prevents a pathological event from consuming retry budget indefinitely.

Multi-Region Failover

• 3-region deployment: us-central1, europe-west1, asia-east1. Each region has its own Cloud Run service, Memorystore instance, and Spanner instance (Spanner is multi-region by nature — use a nam-eur-asia3 config for global consistency).
• Pub/Sub topology: A single global ingest topic with regional push subscriptions — one push endpoint per region. Pub/Sub delivers messages to whichever region's subscription is healthiest. Use Cloud Pub/Sub message ordering with a partition key (user_id) to ensure ordering per user.
• Traffic routing: An external HTTP(S) Load Balancer with serverless NEGs to each regional Cloud Run service. Health checks probe a /health endpoint that verifies Spanner, Redis, and Vertex AI connectivity. If a region fails health checks, the LB stops routing to it, and Pub/Sub push messages to that endpoint will fail and be redelivered to the other regions' subscriptions after the ack deadline (30 s) expires.
• In-flight event safety: Because Pub/Sub operates with at-least-once and ack-deadline redelivery, events being processed in a failed region are not lost — they will be redelivered. The deduplication layer in the receiving region prevents double-processing. RTO = ack deadline + cold start ≈ 35 s, well within any reasonable target.