Question 1

How do you approach an open-ended cloud design question in an interview?

Accepted Answer

Clarify requirements before designing: expected scale, latency targets, availability and recovery objectives, data residency and compliance, budget, team skills, and what already exists. Then state assumptions, sketch a high-level design, and go deeper where the interviewer probes, naming trade-offs at each decision rather than presenting one answer as obviously correct. The most common failure is jumping to services in the first thirty seconds. Interviewers are assessing whether you gather requirements, so asking two or three sharp questions — "what is the read to write ratio?", "is this a hard 99.99% or an aspiration?" — is worth more than any specific architecture.

Question 2

What are the pillars of the Google Cloud Architecture Framework?

Accepted Answer

Operational excellence, security and compliance, reliability, cost optimisation, performance optimisation, and sustainability. They are the axes along which you evaluate a design, and improving one usually costs something on another — which is why explicit trade-offs matter more than a single "best" architecture. The value in using the framework is that it gives you a checklist so you do not present a design that is technically elegant and operationally unmaintainable. Naming which pillar you are trading away in a given decision is what a senior interviewer wants to hear.

Question 3

Design a URL shortener on GCP for one billion redirects per month.

Accepted Answer

Writes are rare and reads dominate, so optimise for read latency. Generate short codes with a counter encoded in base62 or a hash with collision check. Store the mapping in Firestore or Bigtable keyed by short code. Serve redirects from Cloud Run behind a global external Application Load Balancer, with Memorystore caching hot codes and Cloud CDN caching redirects at the edge where the mapping is immutable. Publish click events to Pub/Sub and land them in BigQuery for analytics rather than counting synchronously. The two decisions being tested are separating the read path from the analytics path — never increment a counter in the redirect request — and recognising that an immutable mapping is CDN-cacheable, which removes almost all traffic from your compute. Naming both is what distinguishes the answer.

Question 4

Design a video streaming platform on GCP.

Accepted Answer

Upload directly to Cloud Storage with signed URLs so bytes never pass through your servers. Trigger transcoding through Pub/Sub into the Transcoder API or Cloud Run jobs, producing multiple bitrates and HLS or DASH segments written to an output bucket. Serve through Media CDN with signed cookies for entitlement. Keep metadata in Cloud SQL or Firestore, recommendations in Vertex AI with Vector Search, and stream playback events through Pub/Sub and Dataflow into BigQuery. The design decisions that matter are direct-to-storage upload, asynchronous transcoding rather than blocking a request, signed cookies rather than signed URLs because a player fetches hundreds of segments, and Media CDN rather than Cloud CDN at streaming scale. Each is a specific, defensible choice.

Question 5

Design a multi-tenant SaaS platform on GCP.

Accepted Answer

Choose the isolation model first: shared schema with a tenant column and row-level security for many small tenants; schema or database per tenant for a middle ground; project or instance per tenant for the strongest isolation and the highest cost. Then design tenant-aware identity, per-tenant rate limiting and quotas to prevent noisy neighbours, per-tenant cost attribution through labels, and a data model that allows restoring one tenant without affecting others. Per-tenant restore is the requirement that most often forces a stronger isolation model than the team initially wants, and noisy-neighbour control is the second. Naming both as design drivers, rather than picking shared-schema by default, is what shows real multi-tenant experience.

Question 6

Design a system to process 10 million IoT sensor readings per minute.

Accepted Answer

Devices publish to Pub/Sub, optionally through IoT gateway software, with an ordering key per device where sequence matters. Dataflow reads the stream, validates and enriches, windows for aggregates, and writes raw readings to Bigtable keyed by deviceId and reversed timestamp for low-latency lookups, plus aggregates and raw events to BigQuery for analytics. Alerting rules run in the stream, and Cloud Storage holds long-term archive with lifecycle tiering. The row-key design in Bigtable is the specific technical decision being probed — a raw timestamp prefix creates a hotspot. Splitting the serving store from the analytics store, rather than trying to serve device lookups from BigQuery, is the other differentiator.

Question 7

Design a globally available e-commerce checkout with strong consistency.

Accepted Answer

Spanner for orders, inventory and payments, because it gives relational semantics with strong consistency across regions and horizontal write scaling. Cloud Run behind a global Application Load Balancer for the API, Memorystore for cart and session state, Cloud Tasks for rate-limited calls to payment and logistics partners, and Pub/Sub for order events consumed idempotently by fulfilment and notification services. Use a transactional outbox or Spanner change streams so events cannot diverge from the database. Spanner is genuinely justified here by the strong-consistency-plus-global requirement, and being able to say why — inventory decrement cannot tolerate stale reads across regions — is the point. The dual-write problem and its solution is the second thing interviewers listen for.

Question 8

How do you design for a 99.99% availability target?

Accepted Answer

That allows about 52 minutes of downtime per year, so every layer needs redundancy: multi-zone or multi-region compute behind a global load balancer, a database with automatic failover, no single points of failure, health checks and automated recovery, progressive delivery with fast rollback, and rehearsed disaster recovery. It also requires operational maturity — good alerting, runbooks and an on-call rotation — because most downtime comes from changes, not hardware. The insight that scores is that availability is limited by your deployment process as much as by infrastructure. A perfectly redundant system that ships a bad change with no canary will not reach four nines, and saying so shows you understand where outages actually come from.

Question 9

What is the difference between RTO and RPO, and how do they drive design?

Accepted Answer

Recovery time objective is how long you can be down; recovery point objective is how much data you can afford to lose. A near-zero RPO requires synchronous replication, which constrains geography and adds write latency. A short RTO requires automated failover and rehearsed procedures. Both cost money, so they should be set by the business, not by engineering preference. The practical mapping on GCP is Cloud SQL HA for near-zero RPO within a region, cross-region read replicas for a non-zero RPO with regional protection, and Spanner multi-region for both. Naming that mapping turns an abstract answer into a design.

Question 10

Design a disaster recovery strategy and explain the options.

Accepted Answer

Backup and restore is cheapest with the longest RTO. Pilot light keeps a minimal core running in a second region, scaled up on failover. Warm standby runs a reduced-capacity copy continuously. Hot standby or active-active runs full capacity in both, giving the shortest RTO and highest cost. Choose based on the business RTO and RPO, and rehearse whichever you pick. The line that matters is that an untested DR plan has an unknown RTO, which is equivalent to not having one. Naming a rehearsal cadence, and the fact that you would actually fail over rather than simulate it, is what separates a real plan from a document.

Question 11

Design a real-time analytics dashboard for millions of events per hour.

Accepted Answer

Events into Pub/Sub, Dataflow for windowed aggregation with event-time processing and late-data handling, writing pre-aggregated results to BigQuery and hot metrics to Bigtable or Memorystore for sub-second dashboard reads. The dashboard queries materialised views or the aggregate tables, never raw events. A batch reconciliation job recomputes aggregates daily to correct for late or duplicated data. The two things being tested are never querying raw data from a dashboard, and having a batch path that corrects the streaming path — the lambda-style reconciliation. Streaming aggregates drift over time, and a design without reconciliation will silently produce wrong numbers.

Question 12

How would you design a system to stay within a fixed monthly budget?

Accepted Answer

Choose an architecture with a low cost floor — serverless that scales to zero rather than always-on capacity; set hard quotas rather than relying on budget alerts; cap autoscaling maxima; use lifecycle policies and retention limits on storage and logs; commit only to the measured baseline; and build a cost dashboard with anomaly alerting so drift is caught in days, not at month end. The distinction to make explicit is that quotas enforce and budgets only notify. A design that meets a hard budget needs enforcement points, and naming which specific quotas you would set — regional CPU, BigQuery bytes billed per user, max instances — is the concrete answer.

Question 13

Design a data platform for a company with both operational and analytical needs.

Accepted Answer

Keep them separate. Operational stores — Cloud SQL, AlloyDB, Spanner or Firestore — serve the application. Change data capture through Datastream or change streams, plus event streams through Pub/Sub, feed a BigQuery warehouse with raw, curated and aggregate layers built by Dataform. Governance through policy tags, row-level security and Data Catalog. Analysts and dashboards query the warehouse, never the operational database. The rule to state plainly is that analytical queries must never hit the production database, because an unconstrained query can take down the application. Naming CDC rather than nightly extracts is the modern part, since it reduces both latency and source load.

Question 14

How do you decide between a monolith and microservices on GCP?

Accepted Answer

Start with a well-structured monolith unless you have a specific reason not to — it is simpler to develop, test, deploy and debug. Split into services when independent scaling, independent deployment cadence, team autonomy or technology diversity genuinely require it. Each service adds network calls, failure modes, observability burden and operational surface. The honest position — that microservices are an organisational solution to a team-scaling problem more than a technical one — is what senior interviewers respect. Recommending microservices for a five-person team is a red flag, not a demonstration of ambition.

Question 15

How do you handle the CAP theorem trade-off in a GCP design?

Accepted Answer

Under a network partition you must choose availability or consistency. Spanner and Cloud SQL choose consistency — they will refuse rather than serve stale or divergent data. Firestore is strongly consistent for reads. Bigtable with multi-cluster routing chooses availability with eventual consistency. Choose per data type: money and inventory need consistency, a recommendation panel does not. The nuance worth adding is that Spanner's availability is extremely high in practice because Google's network makes partitions rare, so the theoretical trade-off is less painful than the theorem implies. Applying the choice per data path rather than per system is the mature framing.

Question 16

Design an API platform serving external developers.

Accepted Answer

Apigee or API Gateway in front for authentication, API key and OAuth handling, quota and rate limiting per consumer, versioning and developer portal. Backend services on Cloud Run or GKE behind an internal load balancer. Cloud Armor at the edge, Secret Manager for credentials, structured logs and per-consumer metrics for usage analytics and billing, and a documented deprecation policy with versioned endpoints. The design elements external developers actually care about are versioning and deprecation policy, which are governance decisions rather than infrastructure ones. Naming them alongside the technical stack shows you have run a platform rather than just built an API.

Question 17

How would you architect for data residency requirements in multiple countries?

Accepted Answer

Use regional resources with the organisation policy constraint gcp.resourceLocations to prevent deployment outside permitted regions. Partition data by jurisdiction, either separate projects and regional deployments per country or a partitioned data model with enforced routing. Use Assured Workloads where a formal control package exists, keep audit logs regional, and ensure backups and replicas also stay in region. Backups and replicas are the part most designs forget: a multi-region bucket or a cross-region replica silently moves data out of jurisdiction. Enforcing residency with an organisation policy rather than by convention is the control that actually holds.

Question 18

Design a chat or messaging application backend on GCP.

Accepted Answer

Firestore for message storage with real-time listeners so clients receive updates without polling, or a WebSocket tier on GKE with Memorystore pub/sub for fan-out at higher scale. Cloud Run for the REST API, Firebase Authentication for identity, Cloud Storage with signed URLs for media, Pub/Sub for notification fan-out to FCM, and BigQuery for analytics fed asynchronously. The decision to justify is Firestore listeners versus a self-managed WebSocket tier: Firestore removes enormous connection-management work but costs per operation, which becomes significant with very chatty groups. Naming that crossover is the trade-off the interviewer is after.

Question 19

How do you design for regulatory audit and traceability?

Accepted Answer

Enable Admin Activity and selective Data Access audit logs, export them via an aggregated organisation sink to a locked, separate project with retention policies that cannot be shortened, and restrict access with deny policies. Make infrastructure changes flow only through reviewed pipelines so intent is recorded in Git, use Binary Authorization so deployed artefacts are attested, and keep Cloud Asset Inventory exports for point-in-time state. The property auditors want is that the record cannot be altered by the people it records, which is why log separation plus locked retention matters more than log volume. Linking every production change to a reviewed commit is the other half of traceability.

Question 20

Design a batch processing system that runs nightly over terabytes of data.

Accepted Answer

Land raw data in Cloud Storage partitioned by date in a columnar format. Orchestrate with Cloud Composer expressing dependencies, retries and backfills. Process with Dataflow or Dataproc Serverless, or transform in BigQuery with Dataform if the work is SQL-shaped. Use Spot or FlexRS capacity since the work is delay-tolerant, write outputs idempotently keyed by partition so a rerun replaces rather than duplicates, and alert on data freshness and record-count reconciliation. Idempotent, partition-keyed writes are the design decision that makes reruns safe, which is what you need at 3am when a job fails halfway. Choosing Spot capacity because the workload tolerates interruption is the cost decision that follows from the workload shape.

Question 21

How would you design a system that must handle a 100x traffic spike during a sale?

Accepted Answer

Pre-scale rather than relying purely on reactive autoscaling — minimum instances, warmed caches, and reservations or committed capacity for the peak window. Put as much as possible behind Cloud CDN so the origin sees a fraction of traffic. Protect downstream systems with rate limits, queues and circuit breakers. Load test at the target scale beforehand, and have a degradation plan: which features you disable to protect checkout. The graceful-degradation plan is the senior element — deciding in advance that recommendations and reviews are switched off before checkout is affected. Reactive autoscaling alone cannot handle an instantaneous 100x, which is why pre-scaling and load testing are non-negotiable.

Question 22

How do you design a system to be observable from the start?

Accepted Answer

Instrument with OpenTelemetry so metrics, traces and structured logs share context. Define SLIs and SLOs per user-facing operation before launch. Emit structured logs with request, tenant and version identifiers. Add deployment markers to dashboards. Build the runbook alongside the service, and make the first alert a symptom-based SLO burn-rate alert rather than a CPU threshold. Defining the SLO before launch is the discipline that changes design decisions, because you have to decide what "working" means. Teams that add observability after the first outage always find they cannot answer the question they most need to.

Question 23

Design a machine learning platform for a company adopting AI.

Accepted Answer

Governed data in BigQuery and Cloud Storage with policy tags; features defined once in Vertex AI Feature Store; experimentation in Workbench with no public IPs; training as versioned Vertex AI Pipelines triggered from CI; a Model Registry with lineage; automated evaluation gates including slice metrics before promotion; deployment to endpoints with traffic splitting or batch prediction; Model Monitoring for skew and drift triggering retraining; and everything inside a VPC Service Controls perimeter provisioned with Terraform. The evaluation gate before promotion and the feature store solving training-serving skew are the two elements that distinguish a platform from a collection of notebooks. Automated retraining without a gate is a way to deploy a worse model automatically, which is worth calling out.

Question 24

How do you decide where to put a cache, and what are the risks?

Accepted Answer

Cache as close to the consumer as possible for the biggest saving — CDN at the edge for static and cacheable responses, application-level cache in Memorystore for computed results and sessions, and database-level caching last. The risks are stale data, cache stampedes when a hot key expires, and correctness bugs when invalidation is missed. Naming the stampede mitigation — TTL jitter, single-flight repopulation, or proactive refresh — is what shows you have operated a cache rather than added one. The other point is that a cache hides the real load, so losing it can take down the origin.

Question 25

How would you design a system where one component is much less reliable than the rest?

Accepted Answer

Isolate it: put a queue in front so its slowness does not propagate, add a circuit breaker so repeated failures fail fast rather than exhausting connections, set aggressive timeouts, use bulkheads so its thread or connection pool cannot starve others, and design a degraded mode where the rest of the system works without it. The failure being prevented is cascading failure, where one slow dependency consumes all threads or connections and takes down the whole service. Naming bulkheads and timeouts specifically, rather than just "add retries", is important — retries alone make a slow dependency worse.

Question 26

How do you design an idempotent API?

Accepted Answer

Accept an idempotency key from the client, store it with the result of the first successful execution, and return that stored result on retry rather than re-executing. Make the underlying operation naturally idempotent where possible — upsert rather than increment — and ensure the key store and the business change commit together. The transactional coupling is the subtle part: if you record the idempotency key outside the transaction that performs the work, a crash between the two produces either a duplicate or a lost operation. Naming that requirement is the mark of someone who has implemented it correctly.

Question 27

What is the strangler fig pattern and how would you apply it on GCP?

Accepted Answer

Incrementally replace a legacy system by routing specific functionality to new services while the rest continues to run on the old one, growing the new system until the old can be removed. On GCP, put a global load balancer in front with a URL map routing paths to either the legacy backend — reachable via an internet NEG or hybrid NEG — or to new Cloud Run services. The URL map plus internet NEG is the concrete GCP mechanism, and it is what makes the pattern practical rather than theoretical. The organisational requirement is deciding the slice order by business value and risk, not by what is technically easiest.

Question 28

How do you handle schema evolution across services?

Accepted Answer

Use a schema registry or Pub/Sub schemas to enforce compatibility; make changes additive — new optional fields are safe, removals and type changes are not; version the contract explicitly; consumers ignore unknown fields; and expand-and-contract for anything breaking, deploying producers and consumers in a compatible order. The ordering rule is what people get wrong: for an additive change, deploy consumers first so they tolerate the new field, then producers. Being able to state the deploy order rather than just "make it backwards compatible" is the applied version of the answer.

Question 29

Design a notification system supporting email, SMS and push at scale.

Accepted Answer

Producers publish notification events to Pub/Sub. A router service applies user preferences, quiet hours and deduplication, then enqueues per-channel work in Cloud Tasks so each provider is rate-limited independently. Channel workers on Cloud Run call the providers with retries and circuit breakers, writing delivery status to Firestore. Templates live in a versioned store, a dead-letter topic captures failures, and delivery events stream to BigQuery for analytics. Cloud Tasks per channel is the key decision because each provider has different rate limits and failure behaviour, and a shared queue lets one slow provider block the others. Deduplication and quiet hours are the product requirements that most technical answers omit.

Question 30

How would you architect a system to minimise vendor lock-in?

Accepted Answer

Prefer portable abstractions where the cost is low — containers, Kubernetes, PostgreSQL-compatible databases, open formats like Parquet and Iceberg, OpenTelemetry — and isolate provider-specific services behind interfaces. But accept lock-in deliberately where a managed service delivers disproportionate value, such as BigQuery, and document that decision rather than pretending it is portable. The honest position is that avoiding all lock-in means rejecting the managed services that make cloud worth using, so the goal is deliberate, documented lock-in with a known exit cost. Presenting portability as a free good is the weaker answer.

Question 31

How do you design for a hard latency requirement, say 50 milliseconds at the 99th percentile?

Accepted Answer

Put compute close to users with a global load balancer and multi-region deployment; cache aggressively at the edge; keep the request path short with few sequential network hops; use a low-latency data store such as Memorystore or Bigtable rather than a query engine; avoid cold starts with minimum instances; and measure end to end from the client, not just server-side. Measuring from the client is the point that changes designs, because server-side p99 excludes DNS, TLS handshake and network time that dominate for distant users. A design that meets the target on the server and misses it for real users has failed.

Question 32

How do you evaluate whether to build or buy a capability?

Accepted Answer

Compare total cost of ownership including engineering time to build and maintain, opportunity cost of not building something differentiating, time to market, and the risk of the vendor. Build what differentiates your business; buy or use managed services for everything else. Reassess when scale changes the economics. The framing that scores is differentiation: nobody wins by building their own message queue, and the engineering cost of maintaining one is invisible until it breaks. Being willing to say "we should not build this" is a senior contribution.

Question 33

Design a system for processing financial transactions with exactly-once semantics.

Accepted Answer

Accept the request with an idempotency key, persist it transactionally with the transaction record in Spanner, and return the stored result on retry. Use the transactional outbox or change streams so downstream events cannot diverge from the committed state. Make every consumer idempotent on the transaction identifier, use a saga with explicit compensation for multi-step flows, and reconcile against the ledger in batch daily. The core point is that exactly-once end to end is achieved through idempotency plus transactional state, not through a messaging guarantee. Daily reconciliation is the control that catches whatever the design missed, and financial systems always have one.

Question 34

How do you approach capacity planning on GCP?

Accepted Answer

Measure current utilisation and growth rate, model demand including seasonal peaks, identify the binding constraint per component, then check quotas — regional CPU, IP addresses, API rate limits — well before you need them, because increases take days. Use reservations for guaranteed capacity at known peaks and autoscaling for the variable portion, and load test at the target. Quotas are the constraint people forget, and they fail at exactly the wrong moment — during the traffic spike you planned for. Naming quota review as part of capacity planning, rather than only instance sizing, is a practical differentiator.

Question 35

How would you design a system with strict data deletion requirements?

Accepted Answer

Know where every copy lives — primary store, replicas, backups, caches, logs, analytics warehouse, exports — and design deletion to reach all of them. Use crypto-shredding where physical deletion from backups is impractical: encrypt per subject with a key you can destroy. Set lifecycle policies so data expires by default, and log deletion actions for proof. Crypto-shredding is the technique that solves the backup problem, since you cannot selectively delete one record from an immutable backup. Naming it, and naming logs and analytics copies as places data hides, is what makes the answer complete rather than aspirational.

Question 36

How do you design a system that degrades gracefully?

Accepted Answer

Identify the critical path — the operations that must work — and the non-essential features. Put timeouts and circuit breakers on non-critical dependencies so they fail fast, serve stale cached data when a dependency is down, use feature flags to disable expensive features under load, and shed load with rate limiting rather than letting everything slow down equally. Load shedding is the counter-intuitive part: refusing some requests quickly is better than serving all of them slowly, because slow requests hold resources and cause cascading failure. Deciding in advance what to shed is a design decision, not an incident-time one.

Question 37

What questions would you ask before choosing a database on GCP?

Accepted Answer

What is the data shape and are the query patterns known in advance; what is the read and write volume and ratio; is strong consistency required and at what scope; what are the latency requirements; does it need to scale writes horizontally; what are the availability and recovery objectives; what are the residency constraints; and what does the team already know how to operate. The last question is the one candidates omit and interviewers value, because a technically optimal database the team cannot operate is a worse choice than a familiar one. Query patterns being known in advance is the specific question that separates Firestore or Bigtable from a relational store.

Question 38

How would you review someone else's GCP architecture?

Accepted Answer

Check it against the framework pillars: is there a single point of failure; is identity least-privilege with no basic roles or exported keys; is data encrypted and access-controlled at the right granularity; what is the cost shape and are there enforcement points; can it be deployed and rolled back safely; is it observable with defined SLOs; and does it match the team's operational capability. The last check is the one that most reviews miss: a design that requires operational maturity the team does not have will fail regardless of its technical merit. Framing review as fit-for-team as well as fit-for-purpose is a senior perspective.

Question 39

How do you handle a requirement you believe is wrong?

Accepted Answer

Ask what problem it is meant to solve and what happens if it is not met, quantify the cost of meeting it, and propose the alternative that solves the underlying problem more cheaply. If the requirement is confirmed after that discussion, implement it and document the trade-off rather than quietly building something else. Interviewers ask this to see whether you push back constructively and then commit. The specific example that works well is a stated 99.99% requirement that turns out to be aspirational — quantifying what the fourth nine costs usually changes the conversation productively.

Question 40

Design the complete architecture for a fintech application in India handling payments and KYC.

Accepted Answer

Cloud Identity federated with the corporate IdP and enforced MFA; folders per environment with organisation policies restricting regions to India, forbidding external IPs and service-account keys; Shared VPC with a documented IP plan, Cloud NAT egress and default-deny egress rules; VPC Service Controls around all data services. Cloud Run or GKE behind a global Application Load Balancer with Cloud Armor and managed certificates as the only ingress, IAP for internal tools. Spanner for the transaction ledger with change streams, Cloud SQL for supporting services, Memorystore for sessions and rate limits, Cloud Storage with CMEK, versioning, soft delete and locked retention for KYC documents accessed only through signed URLs. Sensitive Data Protection to classify and tokenise PII, BigQuery with policy tags and row-level security for analytics fed by change streams and Pub/Sub. Audit logs including Data Access exported to a locked separate project. Terraform-managed infrastructure, attested container supply chain with Binary Authorization, per-environment CI identities via Workload Identity Federation, and SLO-based alerting with rehearsed DR and a tested incident-response plan. The closing scenario. What makes it senior is enforcing residency and configuration with organisation policy rather than convention, solving the dual-write problem with change streams, protecting KYC documents with locked retention against both accidents and attackers, and treating rehearsed DR and incident response as part of the architecture rather than operations paperwork.

GCP Architecture & System Design Interview Questions and Answers

How to use this set