37 GCP Interview Questions and Answers

Google Cloud interviews test whether you can connect product requirements to resource boundaries, identity, networking, reliability, observability, and cost—not whether you have memorized a service catalog.

This guide covers 37 questions across Compute Engine, Cloud Run, GKE, IAM, VPC networking, BigQuery, Cloud Storage, Pub/Sub, and cost controls. Exact products, limits, prices, and availability change, so confirm implementation choices in the current documentation for the target region and account.

Table of Contents

1. GCP Fundamentals Questions
2. Compute Engine Questions
3. Serverless Compute Questions
4. GKE and Container Questions
5. IAM and Security Questions
6. Networking Questions
7. Data and Analytics Questions
8. Cost Optimization Questions

GCP Fundamentals Questions

Understanding GCP's organizational structure and core concepts is essential before diving into specific services.

How is GCP's resource hierarchy organized?

GCP organizes resources in a hierarchical structure that flows from organization to folders to projects to individual resources. This hierarchy determines how policies, permissions, and billing are inherited and applied throughout your cloud environment.

For a managed organization, the organization resource is the root and folders provide optional, nestable grouping. Projects are the base container for service resources and the attachment point for API enablement and a billing account. Some projects can exist under “No organization.” A Cloud Billing account is related to projects but is not simply the top of the Resource Manager hierarchy.

flowchart TB
    ORG["Organization"]
    FOLD["Folders (optional)"]
    PROJ["Projects"]
    RES["Resources<br/>(VMs, buckets, etc.)"]
 
    ORG --> FOLD
    FOLD --> PROJ
    PROJ --> RES

How does GCP's resource hierarchy differ from AWS?

Google Cloud and AWS use different governance units. A Google Cloud organization can contain nested folders and projects; AWS Organizations can contain roots, nested organizational units, and accounts. Google Cloud projects and AWS accounts are useful high-level comparison points, but they are not feature-for-feature equivalents.

In Google Cloud, IAM allow/deny policy and organization-policy inheritance can flow through organization, folders, and projects. Billing accounts are linked to projects and can fund projects across the hierarchy when permissions allow. In AWS, organization policies, identity policies, resource policies, account boundaries, and consolidated billing compose differently. Compare blast radius and governance workflows, not which hierarchy is “simpler.”

Key differences:

What are labels in GCP and how do you use them?

Labels are key-value pairs that you attach to GCP resources for organization, filtering, and cost allocation. Unlike the resource hierarchy which is structural, labels provide flexible metadata that can categorize resources across organizational boundaries.

You might label supported resources by environment, team, cost center, or application. Relevant labels can appear in detailed billing exports and resource listings, but support and propagation vary by service and charge. Govern allowed keys and values, and monitor coverage before relying on labels for complete allocation.

# Add labels when creating resources
gcloud compute instances create my-vm \
    --labels=env=prod,team=platform,cost-center=engineering
 
# Filter resources by label
gcloud compute instances list --filter="labels.env=prod"
 
# Labels appear in billing exports for cost allocation

What is the difference between regions and zones in GCP?

Regions are independent geographic areas containing multiple zones, while zones are isolated locations within a region. This hierarchy provides both geographic distribution and fault isolation for your applications.

A region such as us-central1 is a geographic area containing multiple zones. Zones are intended as separate failure domains with low-latency regional connectivity, but correlated regional or dependency failures remain possible. A resource's name tells you its scope only when the product documents it as zonal, regional, multi-regional, or global; “regional” does not imply that every service automatically replicates in the same way.

Choosing regions and zones:

• Deploy across multiple zones for high availability within a region
• Deploy across multiple regions for disaster recovery
• Choose regions close to your users for lower latency
• Consider data residency requirements for compliance

Compute Engine Questions

Compute Engine provides virtual machines in GCP, comparable to AWS EC2. Understanding VM options and configurations is fundamental for any GCP interview.

What are the different machine type families in Compute Engine?

Compute Engine groups machine series into general-purpose, storage-, compute-, network-, memory-, and accelerator-optimized families. Series and regional availability evolve, so an interview answer should start with workload measurements and constraints rather than a memorized generation list.

Compare architecture (x86 or Arm), vCPU/memory shape, single-thread and NUMA needs, network and storage throughput, local SSD, GPU/TPU, live-migration support, quotas, reservations, licenses, region, and price. Benchmark the actual application; a newer series or higher peak specification does not guarantee the best price-performance for every workload.

What are Spot VMs and when should you use them?

Spot VMs use spare capacity at discounted prices, but Compute Engine can stop or delete them at any time and capacity is not guaranteed. They have no Compute Engine SLA, do not support live migration or automatic restart after a host event, and the default preemption path offers only a best-effort shutdown period. Price and notice options vary, so inspect the current SKU and feature status.

Use them only when the system can tolerate lost capacity: checkpoint work, make retries idempotent, distribute across failure domains and provisioning models where needed, bound retry storms, and recreate instances through a managed controller. A database or user-facing worker is not automatically disqualified, but its architecture must meet durability and availability objectives despite abrupt loss.

# Create a Spot VM; use an instance template/MIG for automatic recreation
gcloud compute instances create spot-worker \
    --machine-type=n2-standard-4 \
    --provisioning-model=SPOT \
    --instance-termination-action=STOP

What is the difference between preemptible VMs and Spot VMs?

Spot VMs are the current version of the preemptible provisioning model. Legacy preemptible VMs still use the older 24-hour maximum runtime, while Spot VMs have no maximum runtime.

Spot VMs can use STOP or DELETE as the termination action, but neither Spot nor legacy preemptible VMs supports live migration or automatic restart after a host event. Do not interpret “no maximum runtime” as an availability promise: preemption can occur at any time.

What is live migration and why does it matter?

Live migration moves a supported running VM to another host during qualifying maintenance events, usually without requiring a reboot. It can still cause a temporary performance impact, and some configurations—including Spot/preemptible VMs, bare metal, and various accelerator or specialized shapes—must terminate instead.

Treat live migration as one infrastructure capability, not an application availability guarantee. Check the machine series, attached resources, maintenance policy, and notifications; design health checks, redundancy, graceful restart, and recovery for failures and events that cannot migrate.

When would you use sole-tenant nodes?

Sole-tenant nodes provide dedicated physical servers where only your VMs run, isolating your workloads from other customers at the hardware level. This physical isolation addresses compliance requirements and licensing considerations that shared infrastructure cannot satisfy.

Consider sole-tenant nodes when a verified licensing term, physical-isolation control, placement need, or measured performance requirement calls for dedicated hosts. They are not automatically required by an entire industry or compliance framework, and some BYOL programs use other mechanisms. Validate the license and control with the relevant owner. You pay for the reserved host capacity and a premium, so model utilization, zones, maintenance policy, availability, and migration constraints.

Serverless Compute Questions

GCP offers multiple serverless compute options, each suited to different use cases. Understanding when to use each is a common interview topic.

What is Cloud Run and when should you use it?

Cloud Run is a managed application platform for services, jobs, and functions. A service receives requests in container instances and can scale to zero by default; jobs run tasks to completion. Billing and scaling depend on the selected resource, configuration, minimum instances, and pricing mode, so “pay only while a request runs” is not a universal description.

Cloud Run suits HTTP services, event consumers, APIs, web applications, and run-to-completion work that fits its execution contract. A service can handle multiple concurrent requests per instance. Keep durable state in an external system, make request/event retries safe, and evaluate startup time, timeouts, CPU allocation, concurrency, regional availability, egress, identity, and cost.

# Cloud Run service configuration
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: api-service
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/minScale: "1"  # Avoid cold starts
        autoscaling.knative.dev/maxScale: "100"
    spec:
      containerConcurrency: 80  # Requests per instance
      containers:
        - image: us-central1-docker.pkg.dev/my-project/apps/api@sha256:IMAGE_DIGEST
          resources:
            limits:
              cpu: "2"
              memory: "1Gi"

When should I use Cloud Run services vs Cloud Run functions?

Cloud Functions was renamed Cloud Run functions. Current functions are built as containers and deployed as Cloud Run services; first-generation functions remain a distinct legacy generation. The useful choice is therefore between a general Cloud Run service workflow and a function-oriented source/entry-point workflow, not between unrelated infrastructures.

Use a service when you want to supply a container or source-built service and control its server, routes, concurrency, sidecars, and deployment shape. Use a function when an HTTP or CloudEvent handler is the natural unit and Functions Framework conventions reduce setup. Confirm supported runtimes, triggers, limits, retry policy, identity, and API generation for the target deployment.

How do you handle cold starts in Cloud Run?

Startup latency occurs when Cloud Run needs a new instance and the container must initialize. Measure the latency distribution under realistic concurrency, image pulls, dependency initialization, network calls, and regional conditions before choosing a mitigation.

Minimum instances can reduce scale-from-zero latency but are a best-effort floor, can restart, cost money, and do not prevent new-instance starts during scale-out. Optimize code and dependencies, avoid blocking remote initialization where possible, tune concurrency and startup CPU, and use startup probes to declare when a container can accept traffic. A probe gates traffic; it does not make initialization faster.

# Keep one idle instance to reduce scale-from-zero latency
gcloud run deploy my-service \
    --image=us-central1-docker.pkg.dev/my-project/apps/my-image@sha256:IMAGE_DIGEST \
    --min-instances=1 \
    --max-instances=100
 
# Startup probe ensures traffic waits for initialization
# In your service.yaml:
# startupProbe:
#   httpGet:
#     path: /healthz
#   initialDelaySeconds: 0
#   periodSeconds: 1
#   failureThreshold: 30

How do you process Cloud Storage uploads automatically?

Eventarc can deliver a Cloud Storage CloudEvent to a Cloud Run function or another supported target. This suits image processing, metadata extraction, and workflow initiation when the handler observes the event contract and regional trigger requirements.

Delivery can be retried or duplicated, and ordering is not a general guarantee. Avoid trigger loops, identify an object by bucket/name/generation, validate content and size, bound memory/time, and persist an idempotency result atomically if duplicate side effects matter. The following sketch prevents a prefix loop but is not a complete idempotency implementation.

// Cloud Run function triggered by a Cloud Storage CloudEvent
const sharp = require('sharp');
const { Storage } = require('@google-cloud/storage');
const functions = require('@google-cloud/functions-framework');
 
functions.cloudEvent('processImage', async cloudEvent => {
  const event = cloudEvent.data;
  const storage = new Storage();
  const bucket = storage.bucket(event.bucket);
  const file = bucket.file(event.name);
 
  // Skip if already processed (avoid infinite loops)
  if (event.name.startsWith('processed/')) return;
 
  const [buffer] = await file.download();
 
  const processed = await sharp(buffer)
    .resize(800, 600)
    .jpeg({ quality: 80 })
    .toBuffer();
 
  await bucket.file(`processed/${event.name}`).save(processed);
  console.log('Processed object', {
    bucket: event.bucket,
    name: event.name,
    generation: event.generation
  });
});

What is Cloud Run Jobs and how does it differ from Cloud Run services?

Cloud Run Jobs runs containers to completion without serving HTTP requests, designed for batch processing, data migrations, scheduled tasks, and other run-to-completion workloads. Unlike Cloud Run services which stay running to handle requests, Jobs execute once and terminate.

Jobs support multiple independent tasks and configurable parallelism, retries, and task timeouts. A retry means task code must be idempotent or deduplicate side effects. Execute jobs manually, through the Cloud Run Admin API, Workflows, or a scheduler with a narrowly scoped caller identity.

# Create a Cloud Run Job
gcloud run jobs create data-processor \
    --image=us-central1-docker.pkg.dev/my-project/apps/processor@sha256:IMAGE_DIGEST \
    --tasks=10 \
    --parallelism=5 \
    --max-retries=3
 
# Execute the job
gcloud run jobs execute data-processor
 
# Schedule with Cloud Scheduler
gcloud scheduler jobs create http daily-process \
    --schedule="0 2 * * *" \
    --uri="https://run.googleapis.com/v2/projects/my-project/locations/us-central1/jobs/data-processor:run" \
    --http-method=POST \
    --oauth-service-account-email=scheduler@my-project.iam.gserviceaccount.com

GKE and Container Questions

Google Kubernetes Engine is GCP's managed Kubernetes service and often receives significant focus in cloud interviews.

What is the difference between GKE Autopilot and Standard mode?

GKE offers Standard and Autopilot operating modes. Standard exposes node-pool lifecycle and more infrastructure choices. Autopilot has GKE provision and manage nodes, applies opinionated defaults and admission restrictions, and still leaves application, Kubernetes resource, identity, policy, data, and reliability responsibilities with the customer.

Autopilot billing is pod-based for general-purpose workloads but node-based, plus a management premium, when workloads select specific hardware. Compare supported workloads, ComputeClasses, accelerators, privileges, networking, maintenance, SLAs, reservations/commitments, utilization, and total cost instead of assuming Autopilot is always cheaper or Standard means fully manual patching.

# Create Autopilot cluster (simpler)
gcloud container clusters create-auto my-cluster \
    --region=us-central1
 
# Create Standard cluster (more control)
gcloud container clusters create my-cluster \
    --region=us-central1 \
    --num-nodes=3 \
    --machine-type=e2-standard-4 \
    --enable-autoscaling \
    --min-nodes=1 \
    --max-nodes=10

What is Workload Identity Federation for GKE and why use it?

Workload Identity Federation for GKE exchanges a Kubernetes workload identity for short-lived Google credentials without distributing service account key files. Enabling it creates the trust mechanism but grants no application permissions.

For supported APIs, prefer granting the Kubernetes ServiceAccount principal access directly to the target resource. IAM service account impersonation remains an alternative when a target API has federation limitations or an existing identity contract requires it. Use one identity per workload boundary and least-privilege resource-level roles where supported.

# Kubernetes ServiceAccount used as the workload identity
apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app
---
# Pod using the ServiceAccount
apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  serviceAccountName: my-app
  containers:
    - name: app
      image: us-central1-docker.pkg.dev/my-project/apps/my-app@sha256:IMAGE_DIGEST

# Grant the Kubernetes ServiceAccount principal direct project-level access.
# Prefer a narrower resource policy when the service supports it.
gcloud projects add-iam-policy-binding my-project \
    --role=roles/storage.objectViewer \
    --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/my-project.svc.id.goog/subject/ns/default/sa/my-app"

What are node pools in GKE and why would you use multiple pools?

Node pools are groups of nodes within a GKE cluster that share the same configuration—machine type, disk size, labels, and taints. A single cluster can have multiple node pools with different configurations, allowing you to optimize for different workload requirements.

You might have a general-purpose pool for most workloads, a high-memory pool for databases and caching, and a GPU pool for machine learning jobs. Node pools can scale independently and have different autoscaling configurations. Taints and tolerations ensure pods schedule to appropriate pools.

# Create cluster with default pool
gcloud container clusters create my-cluster \
    --num-nodes=3 \
    --machine-type=e2-standard-4
 
# Add high-memory pool for databases
gcloud container node-pools create high-mem-pool \
    --cluster=my-cluster \
    --machine-type=n2-highmem-8 \
    --num-nodes=2 \
    --node-taints=workload=database:NoSchedule
 
# Add GPU pool for ML workloads
gcloud container node-pools create gpu-pool \
    --cluster=my-cluster \
    --machine-type=n1-standard-8 \
    --accelerator=type=nvidia-tesla-t4,count=1 \
    --num-nodes=0 \
    --enable-autoscaling \
    --min-nodes=0 \
    --max-nodes=5

What is Artifact Registry and how does it differ from Container Registry?

Artifact Registry is GCP's universal package repository that stores container images, language packages (npm, Maven, Python), and OS packages. It replaces Container Registry with additional features and broader format support.

Container Registry is deprecated and was shut down for writes on March 18, 2025. A gcr.io hostname can now refer to a repository hosted by Artifact Registry, so the hostname alone does not prove the backend. Artifact Registry supports repository-level IAM, multiple formats, location choices, policies, audit logs, vulnerability scanning options, and remote or virtual repositories. New examples should use an Artifact Registry repository and immutable digest where release integrity matters.

# Create Docker repository in Artifact Registry
gcloud artifacts repositories create my-repo \
    --repository-format=docker \
    --location=us-central1 \
    --description="Docker images"
 
# Configure Docker authentication
gcloud auth configure-docker us-central1-docker.pkg.dev
 
# Push image (note the different domain)
docker tag my-image us-central1-docker.pkg.dev/my-project/my-repo/my-image:v1
docker push us-central1-docker.pkg.dev/my-project/my-repo/my-image:v1

How do you implement a rolling update strategy in GKE?

Rolling updates gradually replace old Pods, but the strategy alone does not guarantee availability. Capacity/quota, readiness semantics, dependency compatibility, termination behavior, disruption budgets, topology, load-balancer draining, database changes, and rollback safety all affect the result.

maxSurge and maxUnavailable bound Deployment rollout counts relative to desired replicas. maxUnavailable: 0 can preserve the available-Pod count only if the cluster can schedule and make surge Pods ready; it does not guarantee throughput or successful requests. Use a truthful readiness probe, graceful termination, compatible releases, progress deadlines, observability, and an exercised rollback or roll-forward path.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # One extra pod during update
      maxUnavailable: 0  # Never reduce below desired count
  template:
    spec:
      containers:
        - name: app
          image: us-central1-docker.pkg.dev/my-project/apps/my-app@sha256:IMAGE_DIGEST
          readinessProbe:
            httpGet:
              path: /health
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 5

IAM and Security Questions

Identity and Access Management is fundamental to GCP security. Interviewers often probe deeply into IAM concepts and best practices.

How does GCP IAM work?

GCP IAM evaluates which principal can perform which permission on a resource through allow and deny policies, principal access boundaries, and other controls. Allow bindings associate principals with roles at supported resource scopes; inherited policies contribute to the effective result down the Resource Manager hierarchy.

Principals can be Google accounts, service accounts, Google groups, or domains. Roles are collections of permissions—predefined roles cover common use cases, while custom roles let you define precise permission sets. The principle of least privilege guides IAM design: grant only the permissions necessary for each principal's function.

# Grant a predefined role at project level
gcloud projects add-iam-policy-binding my-project \
    --member="user:developer@example.com" \
    --role="roles/compute.instanceAdmin"
 
# Grant at resource level (more restrictive)
gcloud storage buckets add-iam-policy-binding gs://my-bucket \
    --member="serviceAccount:my-app@my-project.iam.gserviceaccount.com" \
    --role="roles/storage.objectViewer"

What is the difference between basic, predefined, and custom roles?

Google Cloud IAM documents three role types: basic, predefined, and custom. The type does not guarantee least privilege; inspect the actual permissions and scope.

Basic roles (formerly called primitive roles: Owner, Editor, and Viewer) are broad and include many permissions across services. Avoid granting them by default. Predefined roles bundle permissions for common service responsibilities. Custom roles can narrow a stable permission set when no predefined role fits, but they require lifecycle ownership as APIs and permissions evolve.

# Create custom role with specific permissions
gcloud iam roles create limitedStorageReader \
    --project=my-project \
    --title="Limited Storage Reader" \
    --description="Can only list and read objects" \
    --permissions=storage.objects.get,storage.objects.list

What are service accounts and when should you use them?

Service accounts are identities for applications and services rather than human users. They can be attached to Compute Engine or Cloud Run resources, impersonated by authorized callers, or used where a product supports service identities. GKE workloads can often use their federated Kubernetes identity directly instead.

Some services create default service accounts, and historical or organization-dependent defaults can grant broader roles than a workload needs. Create dedicated identities along trust and deployment boundaries, inspect effective permissions, and constrain who may attach or impersonate them. Prefer attached service accounts, Workload Identity Federation, and short-lived credentials over downloaded keys.

# Create dedicated service account
gcloud iam service-accounts create my-app-sa \
    --display-name="My Application Service Account"
 
# Grant specific permissions
gcloud projects add-iam-policy-binding my-project \
    --member="serviceAccount:my-app-sa@my-project.iam.gserviceaccount.com" \
    --role="roles/storage.objectViewer"
 
gcloud projects add-iam-policy-binding my-project \
    --member="serviceAccount:my-app-sa@my-project.iam.gserviceaccount.com" \
    --role="roles/pubsub.publisher"
 
# Attach to Compute Engine instance (no key needed)
gcloud compute instances create my-vm \
    --service-account=my-app-sa@my-project.iam.gserviceaccount.com \
    --scopes=cloud-platform

How do you implement service account impersonation?

Service account impersonation lets you temporarily act as a service account without downloading its key. This is useful for local development, CI/CD pipelines, and administrative tasks where you need elevated permissions temporarily.

The caller needs the permissions required for the selected impersonation flow, commonly through roles/iam.serviceAccountTokenCreator on the target service account. Credentials are short-lived and audit logs can identify delegation, but impersonation is still privileged: scope the binding, protect the caller identity, avoid long delegation chains, and monitor use.

# Grant impersonation permission
gcloud iam service-accounts add-iam-policy-binding \
    my-app-sa@my-project.iam.gserviceaccount.com \
    --member="user:developer@example.com" \
    --role="roles/iam.serviceAccountTokenCreator"
 
# Use impersonation for gcloud commands
gcloud auth application-default login \
    --impersonate-service-account=my-app-sa@my-project.iam.gserviceaccount.com
 
# Or set for current session
gcloud config set auth/impersonate_service_account \
    my-app-sa@my-project.iam.gserviceaccount.com

What are IAM conditions and when would you use them?

IAM conditions add contextual rules to policy bindings, granting access only when specified conditions are met. This enables fine-grained access control based on attributes like time, resource properties, or request context.

Common uses include expiring access and restrictions based on supported resource names, resource types, tags, or request attributes. Conditions use Common Expression Language (CEL), but attribute support varies by policy type, service, and permission. Network- or device-based access commonly requires a supported access-level/IAP design rather than an arbitrary source-IP expression in any IAM binding.

# Grant access only during business hours
gcloud projects add-iam-policy-binding my-project \
    --member="user:contractor@example.com" \
    --role="roles/compute.instanceAdmin" \
    --condition='expression=request.time.getHours("America/New_York") >= 9 && request.time.getHours("America/New_York") < 17,title=business-hours-only'
 
# Grant access until a specific date
gcloud projects add-iam-policy-binding my-project \
    --member="user:contractor@example.com" \
    --role="roles/storage.objectViewer" \
    --condition='expression=request.time < timestamp("2027-03-01T00:00:00Z"),title=temporary-access'

Networking Questions

GCP networking has unique characteristics, particularly the global VPC model. Understanding these differences is important for cloud interviews.

How does GCP VPC differ from AWS VPC?

A Google Cloud VPC network is global and its subnets are regional. An AWS VPC is regional and its subnets are scoped to Availability Zones. In one Google Cloud VPC, regional subnets participate in the network's routing and policy model without VPC peering solely because the regions differ.

The platforms also differ in routes, firewall/security-group semantics, load balancers, service networking, DNS, quotas, and charging. A global VPC does not supply multi-region application availability, replicated data, compliant residency, failover, or bounded cross-region cost by itself.

How do you create a multi-region network in GCP?

Create non-overlapping regional subnets in a custom-mode VPC, then design routes, DNS, firewall policy, hybrid connectivity, service access, and observability. Resources in different regional subnets of the same VPC can use internal connectivity without peering the VPC to itself, subject to policy and product constraints.

Enable Private Google Access only on subnets whose internal-only VMs need supported Google API endpoints, and satisfy the DNS, route, and firewall requirements. It is different from private services access and Private Service Connect. Separately design application redundancy, data replication/residency, regional failure, latency, and inter-region charges.

# Create custom VPC (global by default)
gcloud compute networks create my-vpc --subnet-mode=custom
 
# Create subnets in different regions
gcloud compute networks subnets create us-subnet \
    --network=my-vpc \
    --region=us-central1 \
    --range=10.0.1.0/24 \
    --enable-private-ip-google-access
 
gcloud compute networks subnets create eu-subnet \
    --network=my-vpc \
    --region=europe-west1 \
    --range=10.0.2.0/24 \
    --enable-private-ip-google-access
 
gcloud compute networks subnets create asia-subnet \
    --network=my-vpc \
    --region=asia-east1 \
    --range=10.0.3.0/24 \
    --enable-private-ip-google-access
 
# Instances in all three regions can now communicate directly

How do firewall rules work in GCP?

GCP firewall rules control traffic at the VPC level, specifying what traffic is allowed or denied based on source, destination, protocol, and port. Rules can target instances using network tags or service accounts, providing flexibility in how you apply security policies.

VPC firewall rules are stateful through connection tracking. Classic VPC rules use priorities from 0 through 65535, where a lower number is higher priority; when matching allow and deny rules have the same priority, deny wins. Hierarchical, global, regional, system, and classic VPC policies can compose in a configured evaluation order before implied actions. For VM interfaces, the implied ingress action is deny and implied egress is allow unless a higher-level or explicit policy decides otherwise.

# Allow HTTP/HTTPS to instances tagged 'web'
gcloud compute firewall-rules create allow-web-traffic \
    --network=my-vpc \
    --allow=tcp:80,tcp:443 \
    --target-tags=web \
    --source-ranges=0.0.0.0/0 \
    --priority=1000
 
# Allow internal communication within VPC
gcloud compute firewall-rules create allow-internal \
    --network=my-vpc \
    --allow=tcp,udp,icmp \
    --source-ranges=10.0.0.0/8 \
    --priority=1000
 
# Allow SSH only from specific IP (admin access)
gcloud compute firewall-rules create allow-ssh-admin \
    --network=my-vpc \
    --allow=tcp:22 \
    --target-tags=allow-ssh \
    --source-ranges=203.0.113.0/24 \
    --priority=900

What load balancer should you use for a global web application?

For an internet-facing HTTP application with global backends, evaluate the global external Application Load Balancer. It can provide a global anycast frontend, TLS termination, URL maps, health-checked backends, and integrations such as Cloud CDN and Cloud Armor. Regional external, internal, proxy Network, passthrough Network, and cross-region internal products serve different protocols, reachability, proxy, residency, and locality requirements.

Do not choose solely from the word “global.” Confirm protocol, client IP preservation, TLS, backend types, traffic-management mode, failover behavior, data location, capacity, health checks, security controls, quotas, and pricing. “Nearest” is not a universal routing guarantee for every mode and backend state.

# Create health check
gcloud compute health-checks create http http-health-check \
    --port=80 \
    --request-path=/health
 
# Create backend service
gcloud compute backend-services create web-backend \
    --global \
    --protocol=HTTP \
    --health-checks=http-health-check \
    --port-name=http
 
# Create URL map (routing rules)
gcloud compute url-maps create web-map \
    --default-service=web-backend
 
# Create HTTPS proxy with SSL certificate
gcloud compute target-https-proxies create web-proxy \
    --url-map=web-map \
    --ssl-certificates=my-cert
 
# Create forwarding rule (the public IP)
gcloud compute forwarding-rules create web-rule \
    --global \
    --target-https-proxy=web-proxy \
    --ports=443

What is Private Google Access and why is it important?

Private Google Access lets VMs with only internal IP addresses reach supported external Google API and service endpoints using their internal source addresses. It is enabled per subnet and has no effect on VMs that already have external IP addresses.

The subnet still needs the documented DNS, routing, and firewall configuration. Regional rep.googleapis.com endpoints and managed services exposed through private services access or Private Service Connect use different paths. Cloud NAT is for other outbound internet access and is not what enables Private Google Access. Treat lack of an external VM IP as one control, not a complete security boundary.

# Enable Private Google Access on a subnet
gcloud compute networks subnets update my-subnet \
    --region=us-central1 \
    --enable-private-ip-google-access
 
# Verify it's enabled
gcloud compute networks subnets describe my-subnet \
    --region=us-central1 \
    --format="get(privateIpGoogleAccess)"

Data and Analytics Questions

GCP's data and analytics services, particularly BigQuery, are major differentiators. These questions come up frequently in interviews.

What is BigQuery and how does it differ from traditional data warehouses?

BigQuery is a managed analytics platform that separates storage and compute. Query compute can use on-demand bytes processed or capacity pricing through BigQuery editions and reservations. Storage, ingestion/extraction paths, BI Engine, BigQuery ML, Omni, and other features can have separate billing dimensions.

Its columnar architecture supports parallel analytical processing, but no fixed data volume or latency is guaranteed: performance depends on bytes, shuffle, skew, slots, concurrency, partitioning, clustering, caching, and query shape. GoogleSQL is the current name for its SQL dialect.

How does BigQuery pricing work?

BigQuery query compute offers on-demand pricing by bytes processed and capacity pricing by slot-hour using editions, autoscaling, reservations, and optional commitments. “Flat-rate pricing” is legacy terminology. The on-demand free allowance and unit price can change and vary by location/currency, so use the live pricing page and billing SKUs.

Storage has active and long-term logical/physical billing choices and location-specific rates; long-term eligibility is based on partition/table data not being modified for the required period, not whether it was queried. Also account for streaming, replication, data transfer, and optional services. Use dry runs, query plans, billing export, budgets, reservations metrics, and maximum-bytes-billed controls.

How do you optimize BigQuery costs and performance?

Cost optimization in BigQuery revolves around reducing the amount of data scanned per query. Partitioning divides tables by date or integer range, so queries can skip irrelevant partitions entirely. Clustering sorts data within partitions by specified columns, improving filter efficiency and reducing bytes scanned.

Select only columns required by the contract; LIMIT alone does not reduce bytes processed for an on-demand query. Use partition filters that enable pruning, cluster on measured filter patterns, inspect query plans, and use dry runs or maximum bytes billed. Materialized views, result cache, approximate functions, and capacity reservations can help specific workloads, but measure refresh, storage, staleness, and slot trade-offs.

-- Create partitioned and clustered table
CREATE TABLE my_dataset.events
PARTITION BY DATE(event_timestamp)
CLUSTER BY user_id, event_type
AS SELECT * FROM raw_events;
 
-- Query uses partition pruning (only scans one day)
SELECT user_id, event_type, COUNT(*)
FROM my_dataset.events
WHERE DATE(event_timestamp) = '2026-08-15'  -- Partition filter
  AND event_type = 'purchase'               -- Clustering benefits this
GROUP BY user_id, event_type;
 
-- Check bytes scanned before running
-- Use --dry_run with bq command or check validator in console
bq query --dry_run \
    'SELECT * FROM my_dataset.events WHERE DATE(event_timestamp) = "2026-08-15"'

What are the Cloud Storage classes and when should you use each?

The primary broadly available classes are Standard, Nearline, Coldline, and Archive. Nearline, Coldline, and Archive have minimum storage durations of 30, 90, and 365 days and retrieval fees; deleting, replacing, or changing class early can incur early-deletion charges. Rapid is available only with Rapid Bucket and has a separate low-latency use case.

Rates vary by location and include storage, operations, retrieval, data transfer, replication, and other features. A fixed age ladder is not automatically cheaper: model real reads, rewrites, retention/legal holds, recovery objectives, and early-deletion exposure. Use Object Lifecycle Management for explicit policy or evaluate Autoclass when access patterns are uncertain.

# Create bucket with lifecycle policy
cat > lifecycle.json << 'EOF'
{
  "rule": [
    {
      "action": {"type": "SetStorageClass", "storageClass": "NEARLINE"},
      "condition": {"age": 30}
    },
    {
      "action": {"type": "SetStorageClass", "storageClass": "COLDLINE"},
      "condition": {"age": 90}
    },
    {
      "action": {"type": "SetStorageClass", "storageClass": "ARCHIVE"},
      "condition": {"age": 365}
    },
    {
      "action": {"type": "Delete"},
      "condition": {"age": 730}
    }
  ]
}
EOF
 
gcloud storage buckets update gs://my-bucket --lifecycle-file=lifecycle.json

What is Pub/Sub and when would you use it?

Pub/Sub is a fully managed messaging service for asynchronous communication between services. Publishers send messages to topics, and subscribers receive messages through subscriptions. This decouples producers from consumers, enabling scalable, fault-tolerant architectures.

Use Pub/Sub for event distribution, streaming pipelines, and asynchronous service integration. The default delivery model can redeliver, so consumers need idempotent effects or durable deduplication where required. Exactly-once delivery is an optional regional guarantee for pull/StreamingPull subscriptions after successful acknowledgment; it does not make an arbitrary external side effect atomic. Ordering is also opt-in and scoped by ordering key. Design acknowledgment deadlines, dead-letter handling, retry policy, flow control, schemas, retention, and observability explicitly.

# Publisher
from google.cloud import pubsub_v1
 
publisher = pubsub_v1.PublisherClient()
topic_path = publisher.topic_path('my-project', 'user-events')
 
data = '{"event": "user_signup", "user_id": "123"}'
future = publisher.publish(topic_path, data.encode('utf-8'))
print(f'Published message ID: {future.result()}')
 
# Subscriber
subscriber = pubsub_v1.SubscriberClient()
subscription_path = subscriber.subscription_path('my-project', 'user-events-sub')
 
def callback(message):
    print(f'Received: {message.data}')
    # Process message idempotently
    message.ack()
 
streaming_pull_future = subscriber.subscribe(subscription_path, callback=callback)

Cost Optimization Questions

Cost optimization is a practical concern that interviewers use to assess real-world cloud experience.

What are the main strategies for reducing GCP costs?

Cost optimization starts with reliable allocation and usage evidence, then removes waste and changes architecture only when service objectives remain satisfied. Use billing export, labels/tags and project hierarchy, Recommender as input rather than an automatic command, idle-resource detection, rightsizing, schedules, quotas, retention, data-transfer analysis, and unit-cost metrics.

Spot VMs fit interruption-tolerant capacity; autoscaling services can reduce idle allocation but do not eliminate minimum-instance, reservation, storage, request, networking, or downstream costs. Commit only a measured baseline, and test lifecycle policies against retrieval and early-deletion charges. Budgets and alerts improve detection; eligible spend-cap budgets can now enforce a limited project/service scope, but alerts alone do not stop spend.

How do committed use discounts work?

Committed use discounts exchange a time-bound resource or spend commitment for discounted eligible usage. Discount, term, scope, eligible SKUs, region, attribution, and purchase model vary by product and can change; calculate them from the current offer rather than memorizing a maximum percentage.

Compute Engine resource-based commitments are tied to specified resources and region, while spend-based models include service-specific commitments and compute flexible commitments that can cover eligible Compute Engine, GKE, and Cloud Run spend. Billing-account sharing and attribution settings matter. Commit a conservative baseline after accounting for growth, migrations, autoscaling, existing reservations/discounts, currency, and the cost of underutilization.

# View commitment options
gcloud compute commitments list-regions
 
# Create a commitment (example: 3-year commitment)
gcloud compute commitments create my-commitment \
    --region=us-central1 \
    --resources=vcpu=100,memory=400GB \
    --plan=36-month
 
# View active commitments
gcloud compute commitments list

How do you track and allocate GCP costs across teams?

Use project hierarchy, billing-account structure, labels, tags, and service-specific metadata as an allocation model, recognizing that not every charge inherits or exposes every label. Establish ownership and data-quality checks before using exports for showback or chargeback.

Export detailed usage cost data to BigQuery, preserve the schema/history, and reconcile it with invoices and credits. Standard budgets can send threshold notifications or Pub/Sub events but are not caps. As of 2026, spend-cap budgets exist only for eligible, single-project and single-service scopes and have important exclusions; use policy and automation carefully rather than assuming every budget can halt charges.

# Create resources with cost allocation labels
gcloud compute instances create my-vm \
    --labels=team=platform,env=prod,cost-center=eng-123
 
# Export billing to BigQuery (via console or API)
# Then query for cost breakdown

-- BigQuery cost analysis by team
SELECT
  labels.value AS team,
  SUM(cost) AS total_cost
FROM `my-project.billing_export.gcp_billing_export_v1_*`
CROSS JOIN UNNEST(labels) AS labels
WHERE labels.key = 'team'
  AND _PARTITIONTIME >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
GROUP BY team
ORDER BY total_cost DESC;

Quick Reference

Related Resources

• Kubernetes Interview Guide - Core concepts that apply to GKE
• Docker Interview Guide - Container fundamentals
• AWS Interview Guide - Compare cloud platforms
• CI/CD & GitHub Actions Guide - Deploy to GCP
• System Design Interview Guide - Architecture patterns

GCP Interview FAQ

What is the difference between GKE Autopilot and Standard mode?

GKE Standard exposes node pools and more infrastructure choices; Autopilot lets GKE manage nodes and applies opinionated workload defaults and restrictions. Autopilot billing is pod-based for general-purpose workloads but node-based for workloads selecting specific hardware. Choose from workload compatibility, security policy, hardware, operations, availability, and measured total cost rather than assuming one mode is always cheaper.

When should I use Cloud Run services vs Cloud Run functions?

Use a Cloud Run service when you want to deploy a container or source-built service and control its HTTP, scaling, runtime, and delivery model. Use a Cloud Run function when a function entry point and event or HTTP trigger is the simplest unit. Current Cloud Run functions are built as containers and deployed as Cloud Run services, so compare developer workflow and configuration instead of treating them as unrelated platforms.

How does BigQuery pricing work?

BigQuery separates compute, storage, and charges for some ingestion, extraction, and optional services. Query compute can use on-demand bytes processed or capacity pricing measured in slot-hours through BigQuery editions, autoscaling, and optional commitments. Prices and free tiers vary by location, currency, and SKU, so estimate with current pricing, dry runs, maximum bytes billed, and billing exports instead of memorizing a fixed dollar figure.

What is Workload Identity Federation for GKE and why use it?

Workload Identity Federation for GKE exchanges a Kubernetes workload identity for short-lived Google credentials, avoiding downloaded service account keys. Grant a Kubernetes ServiceAccount principal direct resource access when the target API supports it, or use IAM service account impersonation for compatibility. Enabling the feature alone grants no permissions; least-privilege IAM bindings are still required.

What are the GCP storage classes and when should I use each?

Standard has no minimum duration or retrieval fee; Nearline, Coldline, and Archive trade lower storage prices for retrieval fees and minimum durations of 30, 90, and 365 days. Rapid is available only with Rapid Bucket and has a different use case. Select a class from location, access and rewrite patterns, retention, operations, recovery targets, and current pricing; use lifecycle rules or Autoclass only after modeling those costs.

How does GCP VPC differ from AWS VPC?

A Google Cloud VPC is a global resource with regional subnets, whereas an AWS VPC is regional with Availability Zone subnets. The policy, routing, load-balancing, service networking, quota, and billing models also differ. This does not make multi-region design automatic: both platforms still require deliberate IP planning, availability, security, DNS, data-residency, failure-domain, and cost decisions.

Sources

• Google Cloud Resource Manager overview
• Compute Engine machine families
• Compute Engine Spot VMs
• Compute Engine host maintenance policy
• Cloud Run functions comparison
• Cloud Run minimum instances
• GKE Autopilot overview
• Workload Identity Federation for GKE
• Artifact Registry transition from Container Registry
• Google Cloud firewall rule evaluation order
• Private Google Access
• BigQuery pricing
• Cloud Storage classes
• Pub/Sub exactly-once delivery
• Google Cloud committed use discounts
• Cloud Billing spend-cap budgets