Top 50 GCP Interview Questions (2026)

GCP (Google Cloud Platform) is Google's public cloud. It rents out on-demand infrastructure and managed services: virtual machines, managed Kubernetes, serverless containers and functions, object and block storage, managed databases, a data warehouse, networking, and machine learning tools, all billed by usage.

You build on it by creating a project, enabling the APIs you need, and controlling access with IAM. Teams pick GCP for its data and analytics stack (BigQuery), for Kubernetes (Google created it), and for a clean project-based way to organize resources and billing.

GCP organizes everything in a tree: an organization at the top (tied to your domain), then folders to group things by team or environment, then projects that actually hold resources like VMs and buckets. Resources sit inside projects.

The hierarchy matters because IAM policies and organization policies flow down it. A role granted at the folder level applies to every project inside it, so you set broad policy high up and narrow, specific grants lower down. It's the backbone of how access and billing are structured.

A project is the base organizing unit in GCP. Every resource you create lives in a project, and the project holds the enabled APIs, IAM policies, and billing link for those resources. It has a name, a globally unique project ID, and a project number.

It matters because it's the boundary for access and cost. You isolate workloads by project (dev in one, prod in another), which keeps a mistake in one from touching the other and makes billing and permissions clean to reason about.

A region is a geographic area, like us-central1 or europe-west1. Each region contains several zones, like us-central1-a and us-central1-b, and a zone is a single, failure-isolated deployment area within that region.

The design rule follows from this: put replicas across multiple zones so a single zone outage doesn't take you down, and across regions if you need to survive a whole region failing or serve users closer to them. Zonal resources live in one zone; regional resources are spread across zones automatically.

IAM (Identity and Access Management) controls who can do what on which resource. The model is a binding: you grant a role (a set of permissions) to a member (a user, group, or service account) on a resource. The answer to 'can this identity do this action here' comes from those bindings plus inheritance down the hierarchy.

The principle to state is least privilege: grant the narrowest role that gets the job done, at the lowest level that's needed, rather than handing out broad Owner or Editor roles. That's what keeps a compromised identity from touching everything.

There are three kinds. Basic roles (Owner, Editor, Viewer) are broad and legacy, and you avoid them in production because they're too coarse. Predefined roles are curated by Google for a specific service (like Storage Object Viewer), and they're the everyday choice. Custom roles are ones you build from a hand-picked list of permissions when no predefined role fits.

The guidance is to reach for predefined roles first and drop to a custom role only when you need a tighter set. Basic roles are a smell in a real environment because they grant far more than most workloads need.

A service account is an identity for an application, VM, or workload, not a person. Code uses it to authenticate to GCP APIs. A user account belongs to a human who logs into the console. The difference is who or what is acting: service accounts are for machines, user accounts for people.

You attach a service account to a resource like a Compute Engine VM or a Cloud Run service, grant it a least-privilege role, and the workload gets short-lived credentials automatically. That's far safer than shipping a human's credentials or a long-lived key file with the app.

Compute Engine is GCP's infrastructure-as-a-service: virtual machines you provision and manage yourself. You pick a machine type (CPU and memory), a boot image, a zone, disks, and networking, and you're responsible for the OS and what runs on it.

It's the most flexible and the most hands-on option. You reach for it when you need full control of the machine, custom software, or a lift-and-shift of an existing workload, and you accept managing patching, scaling, and availability yourself.

Four common options, from most control to most managed: Compute Engine (raw VMs you manage), GKE (managed Kubernetes for orchestrated containers), Cloud Run (serverless stateless containers that scale to zero), and Cloud Functions (event-driven functions for small pieces of code).

The choice is about how much you want to manage versus control. Take a VM when you need the whole machine, GKE when you're running many containerized services that need orchestration, Cloud Run when you have a container and want it to just run and scale, and Cloud Functions for glue code triggered by an event.

Cloud Run runs your stateless container and handles the rest: it scales up with traffic, scales to zero when idle, and charges only for the time it spends handling requests. You give it a container image and it gives you an HTTPS endpoint, with no servers or clusters to manage.

You use it for web services, APIs, and event handlers that are stateless and containerized, especially when traffic is spiky or low, since scale-to-zero means you pay nothing while idle. It's the sweet spot between a raw VM and a full Kubernetes cluster for a single service.

Cloud Functions is GCP's function-as-a-service: you write a small piece of code, deploy it, and it runs in response to an event, an HTTP request, a file landing in a bucket, a message on Pub/Sub, without you managing any server. It scales automatically and you pay per invocation and runtime.

It's the right tool for small, event-driven tasks: resize an image when it's uploaded, process a message off a queue, run a lightweight webhook. For a full application with many routes and its own container, Cloud Run is usually the better fit.

Cloud Storage is object storage for unstructured data: files, images, videos, backups, logs. You put objects into buckets, each addressed by a globally unique name, and access them over HTTPS. It's not a filesystem or a database; it's for blobs.

Storage classes trade cost against access frequency: Standard for hot, frequently-read data; Nearline for data accessed about monthly; Coldline for quarterly; and Archive for rarely-touched, long-term retention. Colder classes are cheaper to store but cost more to retrieve, so you match the class to how often you'll read the data.

Cloud Storage is object storage: buckets of files reached over an API, accessible from anywhere, not attached to a single VM. A persistent disk is block storage: a virtual disk you attach to a Compute Engine VM, formatted with a filesystem, behaving like a hard drive for that machine.

So you'd keep uploads, backups, and static assets in Cloud Storage, and use a persistent disk for a VM's boot volume or a database's data directory that needs low-latency block access. They solve different problems, object versus block.

A VPC (Virtual Private Cloud) is your private, software-defined network on GCP. It holds subnets, controls IP ranges, and connects your resources, VMs, GKE nodes, and more, so they can talk to each other and to the internet under rules you set.

A distinctive GCP trait is that VPCs are global: one VPC spans all regions, and its subnets are regional. That means resources in different regions can sit in the same VPC and communicate over Google's private network without you stitching networks together per region.

Firewall rules allow or deny traffic to and from resources based on direction (ingress or egress), protocol and port, and a source or target. You target resources by network tags or by service account, which is cleaner than listing IPs. The rules are stateful, so a return packet for an allowed connection is automatically permitted.

By default a VPC denies inbound and allows outbound, and you add rules with priorities where a lower number wins. A common pattern is denying broadly and allowing narrowly: open port 443 to a tagged web tier, and only allow the database port from the app tier's tag.

BigQuery is GCP's serverless data warehouse. You load or stream data into tables and run SQL analytics over huge datasets without provisioning or managing any servers. It separates storage from compute, so each scales on its own and you pay for storage plus the data your queries scan.

It's built for analytics, not transactions: fast aggregation across billions of rows for dashboards, reporting, and data science, not for high-frequency single-row reads and writes. That's what a relational database like Cloud SQL is for.

Cloud SQL is a managed relational database service: fully managed MySQL, PostgreSQL, or SQL Server. Google handles patching, backups, replication, and failover, and you use it like a normal transactional database for an application's reads and writes.

The difference from BigQuery is the workload. Cloud SQL is OLTP: many small, fast transactions, an app's live data. BigQuery is OLAP: heavy analytical queries scanning large volumes. You often run both, an app on Cloud SQL, and analytics on data exported into BigQuery.

gcloud is the command-line tool for GCP. You use it to create and manage resources, VMs, buckets, clusters, IAM bindings, from a terminal or a script, instead of clicking through the console. It's part of the broader Cloud SDK, which also includes gsutil for Cloud Storage and bq for BigQuery.

It matters for interviews because scripting and automation lean on it, and reproducible infrastructure is built from commands and configs, not console clicks. Knowing gcloud config for switching projects and accounts is the everyday starting point.

GKE (Google Kubernetes Engine) is GCP's managed Kubernetes. It runs the Kubernetes control plane for you (the API server, scheduler, etcd) and provisions the worker nodes, so you get a working cluster without building and patching the control plane by hand.

It handles the operational parts that are painful to run yourself: control-plane upgrades, node auto-repair and auto-upgrade, cluster and Pod autoscaling, and integration with GCP load balancing, IAM, and logging. You still write your own Kubernetes manifests; GKE just runs the cluster reliably underneath.

In Standard mode you manage the node pools: you choose machine types, node counts, and autoscaling, and you pay for the node VMs whether or not Pods fully use them. You get full control and can tune the nodes.

In Autopilot mode Google manages the nodes entirely. You just deploy workloads, and you're billed for the CPU and memory your Pods request, not for whole node VMs. It trades some flexibility for less operational work and tighter cost-to-usage, which suits teams that want Kubernetes without managing infrastructure.

Workload Identity lets a Kubernetes service account in GKE act as a GCP service account, so Pods can call GCP APIs with proper IAM permissions without a service account key file mounted in the cluster. You bind the Kubernetes service account to the GCP one, and Pods get short-lived credentials automatically.

You use it because static key files are a security liability: they leak, they don't rotate, and they're hard to audit. Workload Identity is the recommended way for GKE workloads to authenticate to GCP, replacing the old pattern of copying a key into a Secret.

GCP splits load balancers by traffic type and reach. A global external Application Load Balancer handles HTTP and HTTPS worldwide from a single anycast IP, routing by URL and terminating TLS. Network Load Balancers handle TCP and UDP at layer 4. There are internal load balancers for traffic that stays inside your VPC, and passthrough versus proxy variants depending on whether the LB terminates the connection.

The practical choices: a global external Application Load Balancer for a public web app that needs one IP and content-based routing across regions, and an internal load balancer for backend service-to-service traffic. Picking the right one comes down to layer 7 versus layer 4, external versus internal, and global versus regional.

Cloud NAT gives VMs and GKE nodes that have no external IP a way to reach the internet for outbound connections (pulling packages, calling external APIs) while staying unreachable from the outside. It's a managed network address translation service, so there's no NAT gateway VM for you to run.

You need it when you keep instances private for security, no public IP, but they still need to make egress calls. Without Cloud NAT, a private VM can talk inside the VPC and to Google APIs via Private Google Access, but not to the general internet.

Private Google Access lets VMs without external IPs reach Google APIs and services (Cloud Storage, BigQuery, and others) over Google's internal network instead of the public internet. You enable it on a subnet, and private instances can then call those APIs without a public IP or Cloud NAT.

It's part of keeping workloads private: instances stay off the public internet but still use managed services. Pair it with Private Service Connect or VPC Service Controls when you need tighter isolation of which services can be reached and from where.

A managed instance group (MIG) runs a set of identical Compute Engine VMs from an instance template. It keeps the desired number running (recreating failed ones via autohealing), supports rolling updates to a new template, and can autoscale based on CPU utilization, load balancer serving capacity, or a custom metric.

Autoscaling watches the chosen signal and adds or removes VMs between a min and max you set. Combined with a load balancer and health checks, a MIG is how you run a self-healing, scalable VM-based service, the Compute Engine equivalent of what a Deployment plus HPA does in Kubernetes.

Spot VMs are Compute Engine instances offered at a steep discount because GCP can reclaim them at short notice when it needs the capacity. They can be shut down at any time, so they're not for anything that must stay up continuously.

You use them for fault-tolerant, interruptible work: batch processing, CI runners, rendering, data pipelines, and stateless workers that can restart cleanly if a VM disappears. The pattern is designing the job to checkpoint or retry, then running the bulk of the fleet on Spot to cut cost hard.

Sustained use discounts apply automatically to Compute Engine when a VM runs for a large part of the month; the longer it runs, the bigger the automatic discount, with no commitment. Committed use discounts are a deal you opt into: you commit to a certain amount of vCPU and memory (or spend) for one or three years in exchange for a larger, predictable discount.

The strategy is layering: cover your steady baseline load with committed use discounts for the best rate, let sustained use discounts help on top, and run interruptible bursty work on Spot VMs. Right-sizing first, so you're not committing to waste, comes before any of it.

IAM conditions add rules to a role binding so it only applies when the condition is true. You can gate access by request time (a temporary grant that expires), by resource attributes (only buckets whose name starts with a prefix), or by other context. The binding grants the role only when the condition matches.

They tighten least privilege beyond just picking a narrow role: you can give someone Storage Admin, but only on resources tagged for their team, or only until the end of the week. It turns a broad grant into a scoped, sometimes time-limited one.

Secret Manager is the dedicated service: you store secrets (API keys, passwords, certificates) there, version them, and grant access with IAM per secret. Applications fetch a secret at runtime using their service account, so nothing sensitive lives in code, images, or environment files checked into a repo.

The practices that matter: least-privilege IAM on each secret so only the workload that needs it can read it, versioning so you can rotate without breaking running services, and audit logging of who accessed what. Never bake a credential into a container image or commit it to source control.

Cloud Monitoring (part of the operations suite, formerly Stackdriver) collects metrics from GCP resources and your apps, drives dashboards and alerting policies, and runs uptime checks. Cloud Logging collects, stores, and lets you query logs from services and applications, with log-based metrics and export to BigQuery or Cloud Storage for retention.

Together they're your observability layer: metrics to notice a problem and alert on it, logs to see the detail of what happened, and traces (via Cloud Trace) to follow a request across services. Setting up alerting policies on the signals that reflect user impact is the part interviewers care about.

Pub/Sub is GCP's managed messaging service. Publishers send messages to a topic, and subscribers receive them from subscriptions, decoupled and asynchronous. It scales to high throughput, buffers bursts, and delivers at least once, so a slow or failed consumer doesn't lose messages or block the producer.

You reach for it to decouple services, absorb spikes, and fan out events: an order service publishes an event, and billing, inventory, and email services each consume it independently. It's the backbone for event-driven architectures and streaming pipelines feeding Dataflow or BigQuery.

Terraform is the common choice: you declare the resources you want (VMs, buckets, IAM bindings, networks) in config, and terraform plan then apply reconciles reality to that config. GCP's own tool is Cloud Deployment Manager, and newer options include the Config Connector for managing GCP resources through Kubernetes, but Terraform dominates in practice.

The value is reproducibility and review: infrastructure lives in version control, changes go through pull requests where the plan is inspected before apply, and you can stand up an identical environment from the same code. Store Terraform state remotely (a GCS bucket) with locking so a team doesn't corrupt it.

First build the container and push it to Artifact Registry, then run gcloud run deploy to point the service at that image. Cloud Run creates a new revision and, by default, sends traffic to it. You can also split traffic between revisions to do a gradual rollout and watch metrics before shifting everything.

If the new revision misbehaves, rollback is fast: route traffic back to the previous revision with a traffic update, no rebuild required, because Cloud Run keeps prior revisions. That revision model is what makes deploy and rollback on Cloud Run low-risk.

Cloud CDN caches your content at Google's edge locations close to users, so cacheable responses are served from the edge instead of traveling back to your origin every time. That cuts latency for users and load on your backends. You enable it on a backend of an external Application Load Balancer.

It fits because the load balancer is already the front door for your app; turning on Cloud CDN makes that front door cache static assets and cacheable responses. You control what's cached with cache-control headers and cache keys, and the origin only sees requests that miss the cache.

IAM answers 'who can do what'. Organization policies answer 'what's allowed to exist or happen at all', regardless of who's asking. They're guardrails set at the org, folder, or project level: block external IPs on VMs, restrict which regions resources can be created in, disallow service account key creation, and more.

The difference is direction. IAM grants capabilities to identities; org policies constrain configurations across the whole hierarchy. You use org policies to enforce company-wide rules that even a project Owner can't override, which is how platform teams keep hundreds of projects compliant.

Two main options. Cloud VPN builds an encrypted IPsec tunnel over the public internet between your on-prem gateway and GCP; it's quick to set up and cheaper, but throughput per tunnel is limited and it rides shared internet paths. Cloud Interconnect gives a private physical connection: Dedicated Interconnect is a direct link into Google's network, and Partner Interconnect goes through a service provider, both offering higher, more consistent bandwidth and lower latency without touching the public internet.

The choice follows the requirement. Use Cloud VPN for modest bandwidth, quick standup, or a backup path. Use Interconnect when you need large, steady throughput and predictable latency, for example heavy data transfer or a production hybrid setup. Pair either with Cloud Router so routes are exchanged dynamically over BGP instead of being maintained by hand.

Start from the resource hierarchy as an isolation and policy tool. Group by environment and team using folders (a prod folder, a non-prod folder, per-department folders), and give each workload and environment its own project so blast radius, IAM, quotas, and billing stay separated. A shared VPC in a host project lets many service projects use one network without each managing its own.

Set broad guardrails high up with organization policies and IAM at the folder level, then grant specific access per project. This is the landing-zone idea: a repeatable, policy-enforced structure so new teams get compliant projects by default. The failure to avoid is one giant project holding everything, where a single bad IAM grant or quota hit touches unrelated workloads.

Shared VPC lets several projects share one central VPC hosted in a host project: network admins manage the network centrally while service projects deploy resources into its subnets. It's for one organization wanting centralized network control across many projects.

VPC Peering connects two separate VPCs (often across projects or organizations) so their resources can reach each other over private IPs, but each side keeps its own network administration and there's no transitive peering. Use Shared VPC for centralized control inside your org, and peering to connect otherwise-independent networks. For hub-and-spoke at scale, Network Connectivity Center or a transit design replaces a mesh of peerings.

VPC Service Controls draw a security perimeter around managed services like Cloud Storage and BigQuery, so data can't move across the boundary even if credentials are valid. Inside the perimeter, services can talk to each other; a request from outside, or an attempt to copy data out, is blocked regardless of IAM.

The threat they address is data exfiltration: a stolen credential, a misconfigured IAM grant, or a malicious insider trying to read a bucket and send it elsewhere. IAM controls identity; VPC Service Controls add a network-style boundary around the data itself, so the two together give defense in depth.

Start from the requirement, not the architecture: what RTO and RPO does the business actually need, because true active-active multi-region is expensive. Common tiers are multi-zone within one region (handles a zone failure, cheap), a warm standby in a second region (failover in minutes), and active-active across regions (highest availability, hardest because of data replication).

On GCP, use a global external Application Load Balancer to route users to the nearest healthy region, and pick data services deliberately: multi-region Cloud Storage buckets, and Spanner when you genuinely need globally-consistent, horizontally-scalable relational data. The hard part is always the data: replication latency, consistency, and conflict handling. Rehearse failover, because an untested failover plan usually fails when it's needed.

Cloud Spanner is a fully managed relational database that scales horizontally while keeping strong (external) consistency and SQL, across regions if you want. It solves the usual trade-off where you had to give up either relational consistency or horizontal scale.

It's the right choice when you genuinely need both: a relational schema with transactions and joins, and scale or global distribution beyond what a single Cloud SQL instance handles. It's the wrong choice when Cloud SQL fits, because Spanner costs more and has design constraints (schema and primary-key design matter a lot to avoid hotspots). Reach for it on real global-scale relational needs, not by default.

Layer the controls. Use Workload Identity so Pods authenticate to GCP without key files, run a private cluster so nodes have no public IPs, and restrict control-plane access with authorized networks. Enforce least-privilege Kubernetes RBAC, apply NetworkPolicies (default-deny, then allow) to segment Pod traffic, and keep nodes patched with auto-upgrade.

Then add supply-chain and runtime protection: Binary Authorization so only signed, approved images can deploy, image and vulnerability scanning in Artifact Registry, restrictive Pod security standards, and audit logging. The mindset is defense in depth, no single control is enough, and the cluster is a high-value target because it can reach the rest of your GCP environment.

The GCP answer for consistent Kubernetes across environments is GKE Enterprise (formerly Anthos): run GKE on-prem or in other clouds with one control plane, config management (Config Sync from a Git repo), and policy enforcement, so clusters stay consistent wherever they run. Containers and Kubernetes are the portability layer, since a manifest runs the same on any conformant cluster.

The honest senior take is to question whether you need it. Multi-cloud adds real complexity, networking, identity, data gravity, duplicated tooling, so you take it on for concrete reasons: regulatory data residency, avoiding lock-in for a specific critical workload, or an existing on-prem estate. Adopting multi-cloud without a driving requirement usually costs more than it saves.

A common shape: events land in Pub/Sub as the ingestion buffer, Dataflow (managed Apache Beam) processes the stream (parse, enrich, window, aggregate) with autoscaling and exactly-once semantics, and results land in BigQuery for analytics or in Cloud Storage or Bigtable depending on the access pattern. The same Beam pipeline can run in batch or streaming mode.

The design choices that matter: Pub/Sub decouples producers from the pipeline and absorbs bursts, Dataflow handles late and out-of-order data with windowing and watermarks, and BigQuery gives serverless SQL over the output. For lower-cost batch or where you already run Spark, Dataproc is the alternative to Dataflow. Match the sink to how the data will be read.

Measure first: use billing exports to BigQuery and labels on resources to attribute spend to teams and services, because cutting blind hurts reliability. Then work the big levers: right-size over-provisioned VMs, use autoscaling to match capacity to demand, buy committed use discounts for steady baseline load, run interruptible work on Spot VMs, and move cold data to Nearline, Coldline, or Archive storage classes.

The reliability guardrail matters: don't cut redundancy that protects availability, and watch BigQuery query cost by setting per-query byte limits and partitioning or clustering tables so queries scan less. The biggest wins are usually killing waste, idle resources, forgotten dev environments, oversized disks, rather than degrading production.

BigQuery on-demand pricing charges by bytes scanned, so the goal is scanning less. Partition tables (usually by date) so a query touches only the relevant partitions, cluster on the columns you filter and join on so related data sits together, and select only the columns you need rather than SELECT *, since scanning is column-based. Avoid re-scanning by materializing common results.

On the pricing model, on-demand suits spiky, unpredictable usage, while capacity-based (slot reservations) gives predictable cost for steady heavy workloads. Set custom quotas or per-query maximum-bytes-billed as a guardrail so one runaway query can't blow the budget. Partitioning plus clustering plus tight column selection is where most of the savings and speed come from.

Define RPO and RTO first, then match tools to them. For data: persistent disk snapshots on a schedule, automated Cloud SQL backups plus point-in-time recovery, cross-region replication or multi-region buckets for Cloud Storage, and exports of critical datasets. Store backups in a separate project or region so one compromised environment can't destroy both the data and its backups.

For recovery: keep infrastructure as code so you can rebuild an environment from Terraform, script and rehearse the restore, and test it regularly because an untested backup is a guess. The DR pattern (backup-and-restore, pilot light, warm standby, or active-active) follows from the RTO and RPO the business will pay for, not the other way round.

Cloud Audit Logs record who did what, where, and when. Admin Activity logs (config changes) are on by default and free; Data Access logs (reads and writes of data) must be enabled and can be high volume. Together they give a trail for security investigations, compliance, and figuring out what changed before an incident.

The practices that matter: enable Data Access logging on sensitive services, export logs to a locked-down bucket or BigQuery in a separate security project so they can't be tampered with, set retention to meet compliance, and alert on suspicious actions like a new owner grant or a firewall opened wide. Logs you can't trust or query aren't much use, so treat the log pipeline as part of the security design.

discovery and a strategy per workload, the classic options are rehost (lift-and-shift to Compute Engine, fastest, least benefit), replatform (move to managed services like Cloud SQL or GKE with light changes), and refactor (re-architect for cloud-native, most benefit, most effort) comes first. Pick per app based on value and risk, not one blanket approach.

Then sequence it: set up the landing zone (org, projects, networking, IAM, guardrails) first, migrate low-risk workloads to build confidence, handle data migration deliberately (Storage Transfer Service, Database Migration Service, or Transfer Appliance for huge datasets), and plan cutover with a rollback path. Migrate in waves with validation at each step rather than a big-bang move, because a staged migration is where you catch the surprises safely.

Clarify first: expected traffic and spikes, is it stateless, what data does it need, latency and availability targets, and budget. Then lay out a typical shape: a global external Application Load Balancer with Cloud CDN at the front, the app running on Cloud Run or GKE (Cloud Run for a single stateless service, GKE when there are many services to orchestrate), a managed database (Cloud SQL, or Spanner for global scale), Cloud Storage for user uploads and static assets, and Memorystore for caching hot reads.

For the operational wrapper: keep instances stateless so they scale horizontally and push state to the managed data services, spread across zones (and regions if the availability target needs it), use IAM and service accounts with least privilege, secrets in Secret Manager, and observability with Cloud Monitoring, Logging, and Trace. The structure that scores is clarify, pick services with reasons, make it stateless and multi-zone, then secure and observe it, each choice justified by the requirements you asked for.