Google Cloud (GCP) interview questions

Google Cloud Platform (GCP): Google's suite of cloud computing services running on the same infrastructure Google uses internally for its products. GCP Resource Hierarchy (top to bottom): Organization: root node for a company. Created when you associate a domain with GCP (Google Workspace/Cloud Identity). Policies applied here affect everything below. Folders: optional grouping containers. Organize by department (Engineering, Finance, HR), environment (Prod, Staging, Dev), or geography. Policies inherited from parent folders. Projects: fundamental organizational unit. Every GCP resource belongs to a project. Billing, APIs, quota, and IAM are scoped per project. A project has a name (human-readable), ID (globally unique, immutable), and number. Resources: actual services within a project — Compute Engine VMs, Cloud Storage buckets, Cloud SQL instances, etc. IAM Policy Inheritance: policies set at a higher level are inherited by all lower levels. Deny policies block access even if a lower-level allow exists. Benefits: - Separate billing: track costs per project/folder - Access isolation: grant a team access to their project without affecting others - API enablement: enable only the APIs each project needs - Quota management: per-project API quotas prevent runaway usage Best practice: separate projects per environment (prod, staging, dev), per application, or per team. Use shared VPC project for centralized networking.

GCP IAM (Identity and Access Management): controls who can do what on which GCP resource. Core concepts: Principals (who): - Google Account: a person's Google account (user@gmail.com) - Service Account: non-human identity for applications and VMs - Google Group: collection of Google Accounts - Workspace/Cloud Identity domain: all users in an organization - allUsers: anyone on the internet (public access) - allAuthenticatedUsers: any authenticated Google account Roles (what permissions): - Basic roles (avoid for production): Owner, Editor, Viewer — overly broad, apply to all GCP services - Predefined roles: curated roles per service. roles/storage.objectViewer, roles/bigquery.dataViewer, roles/compute.instanceAdmin.v1 - Custom roles: create your own permission bundle when predefined don't fit Bindings: a policy is a list of bindings. Each binding: { role: "roles/storage.objectViewer", members: ["user:alice@example.com"] } Conditions: bind roles based on resource attributes (time, IP, resource tags). Grant developer access only to non-production resources. Service Accounts: identity for applications. - Create service account, grant it roles - Bind to VM: VM automatically gets SA's identity (no keys needed) - Service Account Keys (avoid): downloadable JSON credentials — security risk. Prefer workload identity. Principle of Least Privilege: grant only the minimum permissions needed. Don't grant Editor when Viewer suffices. Audit with IAM Recommender (shows unused permissions in last 90 days). Deny policies (newer feature): explicit deny that overrides any allow — useful for organization-wide controls.

Compute Engine (GCE): infrastructure-as-a-service for running virtual machines on Google's network. Choose machine type, OS (custom image or marketplace), networking, storage. Machine types: - General purpose: E2 (cost-optimized, shared core), N2/N2D/N1 (balanced), Tau T2D (scale-out workloads) - Compute-optimized: C2/C3 (high CPU, SAP, HPC) - Memory-optimized: M1/M2/M3 (up to 12TB RAM — SAP HANA, large in-memory DBs) - GPU: A100, V100, L4, T4 — ML training and inference - Custom machine types: any combination of vCPU and memory within limits Pricing models: - On-demand: pay per second (1-minute minimum) - Sustained use discounts: automatic — GCP automatically discounts when you run a VM for most of the month (up to 30% discount, no commitment) - Committed use discounts (CUD): 1 or 3 year commitment, up to 70% discount - Preemptible VMs (Spot VMs): excess capacity, up to 91% discount, can be reclaimed with 30-second notice. Use for batch, fault-tolerant workloads. GCE vs AWS EC2: - Sustained use discounts: GCE gives these automatically, EC2 requires Reserved Instance commitment - Custom machine types: GCE allows any vCPU/RAM combo; EC2 has fixed instance types - Network pricing: GCE charges less for egress; no charge for ingress - Live migration: GCE migrates VMs to another host for maintenance with no reboot needed; EC2 requires maintenance events Instance groups: Managed Instance Groups (MIG) for auto-scaling and healing (like AWS ASG). Unmanaged for manually managed groups.

GKE (Google Kubernetes Engine): fully managed Kubernetes service — same team at Google that created Kubernetes built and runs GKE. AWS K8s expert opinion: GKE is widely considered the best managed Kubernetes offering. Standard mode: - You manage node pools: choose machine types, configure auto-scaling, manage upgrades - Control plane managed by Google (free) - More control over node configuration - Per-node pricing Autopilot mode (GKE's distinctive feature): - Google manages nodes, node pools, auto-scaling, all infrastructure - You deploy pods/workloads only — no node management - Billing per pod resource request (CPU, memory), not per node - Automatically right-sizes and scales nodes for your workloads - Security hardened by default: workload identity required, no SSH to nodes, privileged containers blocked - Best for: teams wanting Kubernetes without infrastructure management Key GKE features: - Release channels: Rapid, Regular, Stable — choose your upgrade cadence. Auto-upgrades handle security patches. - Cluster autoscaler (Standard): automatically adds/removes nodes based on pending pods - Vertical Pod Autoscaler (VPA): recommends or automatically adjusts pod CPU/memory requests - Horizontal Pod Autoscaler (HPA): scale pods based on CPU, memory, custom metrics (Pub/Sub queue depth) - Binary Authorization: require signed container images before deployment - Config Connector: manage GCP resources (Cloud SQL, Pub/Sub) from Kubernetes YAML - Workload Identity: pods get Google service account identity without storing keys GKE vs EKS vs AKS: GKE Autopilot is unique in the market — EKS and AKS don't have an equivalent fully node-managed offering with per-pod billing.

Cloud Run: fully managed serverless platform for stateless containers. Deploy any container that listens on HTTP — Cloud Run handles scaling, load balancing, SSL, zero to thousands of instances in seconds. How it works: 1. Build and push Docker image to Artifact Registry 2. gcloud run deploy myservice --image gcr.io/project/myimage --region asia-south1 --allow-unauthenticated 3. Cloud Run provides HTTPS URL immediately 4. Scales to zero when no traffic, scales up within seconds on traffic Key features: - Scale to zero: no traffic = zero cost. Pay only for requests + compute during execution. - Scale to thousands: handle traffic spikes instantly with zero configuration - HTTP/2 and gRPC: native support - Concurrency: set max concurrent requests per container instance (default 80). High-concurrency Node.js/Go apps can handle 1000 simultaneous requests on one instance. - Minimum instances: set > 0 to avoid cold starts for latency-sensitive services - Revisions: every deployment creates a new revision. Split traffic between revisions (canary). Rollback by routing traffic to previous revision. - Cloud Run Jobs: run containers to completion (batch processing, ETL, migration jobs) — not for HTTP serving Cloud Run vs GKE: - Cloud Run: simpler, no K8s knowledge needed, automatic scaling, pay-per-use, stateless HTTP workloads - GKE: stateful workloads, complex networking, multi-container pods, custom K8s features, GPU, Kubernetes ecosystem tools - Cloud Run (Anthos): Cloud Run on your own GKE cluster or on-premises (hybrid) Cloud Run vs Cloud Functions: - Cloud Functions: small code snippets, lighter weight, directly trigger on GCP events without HTTP conversion - Cloud Run: any containerized app, more control, handle longer requests (60 minutes timeout), custom runtimes India use case: microservices for a SaaS product — backend API containers in Cloud Run. Scale to zero on weekends, scale to 100 instances on Monday morning automatically.

Cloud Storage: globally unified, scalable object (blob) storage. Buckets + objects. 99.999999999% (11 nines) durability. Bucket location types: - Region: single region (asia-south1 = Mumbai). Lowest latency for users in that region. Cheapest storage. - Dual-region: two specific regions (nam4 = Iowa + South Carolina). Redundant, fast replication between pair. - Multi-region: continent-wide (asia, us, eu). Highest availability. Objects replicated across many regions. Storage Classes (choose by access frequency): - Standard: frequently accessed. Highest per-GB/month cost, no minimum storage duration, no retrieval fee. Active data. - Nearline: once/month or less. Lower storage cost, 30-day minimum, retrieval fee. Monthly reports, backups. - Coldline: once/quarter or less. Even lower storage cost, 90-day minimum, higher retrieval fee. DR backups. - Archive: once/year or less. Lowest storage cost ($0.0012/GB/month), 365-day minimum, highest retrieval fee. Compliance archives. Object Lifecycle Management: automatically transition or delete objects based on age or other conditions. lifecycle: rule: - action: { type: SetStorageClass, storageClass: NEARLINE } condition: { age: 30 } - action: { type: SetStorageClass, storageClass: COLDLINE } condition: { age: 90 } - action: { type: Delete } condition: { age: 365 } Uniform bucket-level access: enforce IAM only (disable legacy ACLs) — recommended for new buckets. Signed URLs: grant time-limited access to a specific object without requiring a Google account. const url = await storage.bucket(bucketName).file(fileName).getSignedUrl({ action: 'read', expires: Date.now() + 15 * 60 * 1000 }); Public access prevention: block all public access — no accidental public buckets (like AWS Block Public Access).

BigQuery: fully managed, serverless, petabyte-scale data warehouse with built-in ML, BI, and geospatial analytics. Why BigQuery is a game-changer: Serverless: no clusters to provision, configure, or maintain. Just write SQL and BigQuery executes it on Google's Dremel engine — which can spin up thousands of workers in seconds. Scale: query petabytes of data in seconds using massively parallel column-oriented processing. A query that takes hours on traditional databases takes seconds on BigQuery. Pricing: pay per TB scanned (on-demand: $5/TB). No idle cost. Or flat-rate capacity pricing for predictable workloads. Compare to Redshift where you pay per node 24/7. Performance tricks: - Columnar storage: reads only queried columns - Partitioning: partition by date/integer — WHERE date > '2024-01-01' scans only those partitions - Clustering: co-locate related rows — further prune data scanned - Materialized views: precompute expensive aggregations, auto-refresh - BI Engine: in-memory analysis layer for sub-second dashboard queries BigQuery ML: run ML training and inference with SQL statements. CREATE MODEL myproject.mydataset.salary_model OPTIONS(model_type='linear_reg', input_label_cols=['salary']) AS SELECT experience, skills, salary FROM myproject.mydataset.employees; External tables: query data in Cloud Storage, Drive, Bigtable without loading into BigQuery (federated queries). Omni: run BigQuery on AWS S3 or Azure Blob data without moving data (BigQuery Omni). India use case: analytics on billions of rows of e-commerce transaction data — Flipkart, BigBasket scale analytics.

Cloud SQL: fully managed relational database service for MySQL, PostgreSQL, and SQL Server. Google handles patching, backups, replication, failover. Features: - High availability: primary + standby in different zone, automatic failover - Read replicas: scale reads, up to 10 replicas per instance - Backups: automated daily backups + point-in-time recovery - Storage auto-increase: automatically grows storage as data grows - Private IP: accessible only within VPC (recommended over public IP) - Maintenance windows: control when patches are applied - Instance types: shared core (dev), dedicated (production), high-memory (data-intensive) Cloud SQL vs standard PostgreSQL on GCE VM: - Cloud SQL: managed backups, HA failover, patching — less ops work - GCE: full control, any PostgreSQL version, custom extensions, potentially cheaper at scale with proper setup Cloud Spanner: Google's globally distributed relational database. - Horizontal scaling: add nodes to scale writes and reads — SQL with NoSQL-style horizontal scale - Global distribution: span multiple regions with synchronous replication and strong consistency - Five 9s availability (99.999%) - Distributed transactions: ACID transactions across regions - SQL + external consistency: strongest consistency model (stronger than SERIALIZABLE) - External consistency: like having a global, distributed, strongly-consistent database When to choose: - Cloud SQL: standard OLTP workloads, single-region, familiar MySQL/PostgreSQL, cost-effective - Cloud Spanner: global applications needing strong consistency (financial transactions across regions), need to scale writes horizontally beyond single-node limits, willing to pay premium (starts at ~$900/month for smallest instance) Cloud Spanner is what banks and telecos use — Google Ads and Google Photos use Spanner internally.

Cloud Pub/Sub: fully managed, real-time messaging service for decoupling services and enabling event-driven architectures. Scales to millions of messages per second globally. Core concepts: - Topic: named channel where publishers send messages - Subscription: named resource representing a subscriber's interest in a topic. Multiple subscriptions can receive the same message from a topic. - Message: data + optional attributes. Up to 10MB each. - Publisher: sends messages to a topic - Subscriber: receives messages from a subscription Delivery semantics: at-least-once — messages can be delivered more than once (design idempotent consumers). Subscription types: - Pull: subscriber calls Google API to pull messages. Consumer controls the pace. Use for batch processing, variable throughput workloads. - Push: Pub/Sub pushes messages to a HTTPS endpoint. Subscriber is a web server. Use for Cloud Run, App Engine, webhooks. - BigQuery subscriptions: directly write messages to BigQuery table — no consumer code needed - Cloud Storage subscriptions: write messages to GCS as files Message retention: 7 days (configurable). Replay: seek to a timestamp to reprocess historical messages. Ordering: enable message ordering with an ordering key — messages with the same key delivered in order. Exactly-once delivery (new): Pub/Sub guarantees exactly-once delivery per subscription if consumer acknowledges within ack deadline. Filtering: subscriptions can filter messages by attribute — subscriber only receives relevant messages without filtering in consumer code. Use cases: microservices decoupling, event streaming, analytics pipeline ingestion, real-time notifications, IoT telemetry (millions of devices). Pub/Sub Lite: zonal (cheaper), lower throughput, manual partition management — use for cost-sensitive high-volume use cases.

Cloud Firestore: fully managed, serverless, NoSQL document database. Scales automatically from 0 to billions of documents. Used by Firebase apps and backend services. Data model: - Documents: JSON-like objects with fields. Max 1MB per document. - Collections: containers for documents (like tables). Can be nested (subcollections). - Path: documents/collections alternate. users/uid/orders/orderId Hierarchy: users → [userId] → { name, email } → orders (subcollection) → [orderId] → { total, items } Key features: - Real-time listeners: onSnapshot() — get live updates when data changes. Powers real-time collaborative apps. - Offline support: Firestore SDK caches data locally. Works offline, syncs when reconnected. - Strong consistency: reads reflect all confirmed writes immediately. - Rich queries: filter by multiple fields, order, limit. Compound queries require composite indexes. - Transactions and batch writes: atomic multi-document operations. - Multi-region: strong consistency + high availability. Firebase Realtime Database (RTDB): - Single large JSON tree (no collections/documents) - Real-time sync, offline support - Simpler queries (path-based, sort on one field) - Region: single region only - Cheaper for very simple use cases - Better for simple chat, presence Firestore vs RTDB: - Firestore: richer queries, better scaling (sharded), multi-region, offline for mobile, better for complex data models - RTDB: simpler data model, better deep real-time sync, slightly lower latency at small scale Firestore security rules: rules_version = '2'; service cloud.firestore { match /databases/{database}/documents { match /users/{userId} { allow read, write: if request.auth.uid == userId; } } }

Cloud Functions: event-driven serverless compute. Write a function, deploy it, Google scales it automatically. No servers to manage. Triggers: HTTP, Cloud Pub/Sub, Cloud Storage events, Firebase events, Cloud Firestore events, Cloud Scheduler (cron), Eventarc (all GCP event sources). 1st Generation: - Node.js, Python, Go, Java, .NET, Ruby, PHP - Max timeout: 9 minutes (HTTP), 10 minutes (background) - Max concurrency: 1 request per instance (each concurrent request = new instance) - Cold starts more noticeable - Max instance size: up to 16GB RAM, 4 vCPU - HTTP min-instances to reduce cold starts 2nd Generation (built on Cloud Run — recommended): - Same languages as 1st gen - Max timeout: 60 minutes - Concurrency: up to 1000 concurrent requests per instance (like Cloud Run) — massive cost savings for I/O-bound functions - Larger instances: up to 32GB RAM, 8 vCPU - Built on Cloud Run — brings Cloud Run's features (traffic splitting, min instances, revision management) - Eventarc: richer event trigger ecosystem - Minimum instances: guaranteed warm instances, consistent latency Use Cloud Functions when: - Event-triggered processing (process file uploaded to GCS, message on Pub/Sub) - Simple webhooks - Glue code between GCP services Use Cloud Run when: - Need full container control - Custom runtimes - Complex application logic - Already using containers Migrate 1st gen → 2nd gen: mostly compatible — change function signature slightly, get better performance and longer timeouts.

Cloud VPC (Virtual Private Cloud): global, private networking for GCP resources. Unlike AWS VPCs (regional), GCP VPCs are global — one VPC with subnets in any region. Key concepts: - Subnets: regional resources (not zonal). Resources in different zones in the same region share a subnet. - Firewall rules: apply at VPC level (not subnet level by default). Use tags and service accounts as targets. - Routes: control packet forwarding. Default routes for internet and internal traffic. - Cloud NAT: managed outbound internet access for VMs without public IPs. No NAT VMs to manage. Global VPC advantage: VMs in Mumbai and Singapore subnets in the SAME VPC communicate via Google's private backbone — no VPN/peering required, just internal IPs. VPC Peering: - Connect two VPCs privately (same or different organizations) - Non-transitive: A peers B, B peers C → A cannot reach C - Routes not automatically shared across multiple hops - Use when: two projects need private communication. Example: "data" project VPC peers with "analytics" project VPC. Shared VPC (Host project + Service projects): - One project (host project) owns the VPC - Other projects (service projects) share the network - Centralized networking: one team manages VPC, subnets, firewall rules - Resources in service projects get IPs from host VPC subnets - Use for: enterprise — central networking team controls network, dev teams deploy resources in their own projects but use shared network Private Google Access: VMs without public IPs can reach Google APIs (Cloud Storage, BigQuery, etc.) over Google's network — no internet NAT needed. Private Service Connect: access Google APIs and third-party services via a private endpoint in your VPC.