Top 46 Google Cloud Platform (GCP) Interview Questions & Answers (2026)

Google Cloud Platform (GCP) is a suite of cloud computing services provided by Google, running on the same infrastructure that Google uses for its own products like Google Search, Gmail, and YouTube. GCP offers services for computing, storage, databases, machine learning, networking, and DevOps across a global network of data centers in over 40 regions. It is the third-largest cloud provider after AWS and Azure. GCP is particularly known for its strengths in data analytics (BigQuery), machine learning (Vertex AI, TensorFlow), containers (GKE — which Google invented Kubernetes), and networking performance (Google's global fiber backbone).

A GCP Project is the fundamental organizational unit in Google Cloud. It is the base-level container for all GCP resources and services. Key attributes: a unique Project ID (globally unique, immutable), a Project Name (human-friendly), and a Project Number (auto-assigned). Each project has its own billing account, APIs enabled, IAM policies, and network configuration. Resources like Compute Engine VMs, Cloud Storage buckets, and Cloud SQL instances exist within a project. Projects are grouped within folders and organizations (using Cloud Resource Manager) for enterprise governance. You must enable specific APIs before using them in a project — for example, enabling the Kubernetes Engine API before creating a GKE cluster.

Google Compute Engine (GCE) is GCP's Infrastructure as a Service (IaaS) offering for running virtual machines. It provides high-performance, scalable VMs on Google's infrastructure. Key features: Machine types: predefined (N2, C2, M2 series) and custom (specify exact vCPU and RAM). Preemptible/Spot VMs: 60–91% cheaper, but can be reclaimed with 30 seconds notice. Persistent Disk: network-attached SSD/HDD storage. Local SSD: physically attached, high-IOPS storage. Live migration: Google migrates VMs to different hardware during maintenance with no downtime — a unique GCP advantage. Managed Instance Groups: auto-scaling groups of identical VMs. Billed per second with a 1-minute minimum.

Google App Engine is a fully managed PaaS for building and hosting web applications. Google manages the servers, operating systems, and runtime — you deploy code. Two environments: Standard Environment: runs in a sandboxed environment with specific language runtimes (Python, Java, Go, PHP, Node.js, Ruby); scales to zero (no cost when idle); free tier available; limited to approved libraries. Flexible Environment: runs in Docker containers on Compute Engine VMs; supports any language or runtime; never scales to zero; more flexible but costs more. App Engine is best for web apps and APIs where you want Google to handle scaling and infrastructure. It was Google's first cloud service, launched in 2008, predating AWS Lambda by years in the serverless concept.

Google Cloud Storage (GCS) is GCP's unified object storage service for storing any amount of data with global availability. Data is organized in buckets (globally unique names) containing objects (files). Storage classes: Standard: frequently accessed data. Nearline: accessed once per month; lower storage cost. Coldline: accessed once per quarter. Archive: accessed once per year; lowest cost. Transition between classes automatically with Object Lifecycle Management. Key features: Strong consistency (unlike early AWS S3). Uniform bucket-level access for IAM-based access control. Object versioning. Signed URLs for temporary public access. GCS is the central data lake for GCP data analytics workloads.

Google Kubernetes Engine (GKE) is Google's managed Kubernetes service and the most mature managed Kubernetes offering, as Google invented Kubernetes. GKE manages the control plane (free for Standard mode) and provides automated upgrades, auto-repair, and logging. Key features: Autopilot mode: fully managed — GKE manages nodes, networking, and security; you only manage pods and pay per pod resource. Standard mode: you manage nodes (VMs). Auto-scaling: Cluster Autoscaler for nodes, HPA for pods. Node pools: different VM types for different workloads. Workload Identity: bind Kubernetes service accounts to Google service accounts for secure GCP API access. Binary Authorization: ensure only signed images are deployed. GKE is often considered the gold standard for managed Kubernetes.

BigQuery is Google's fully managed, serverless data warehouse designed for ultra-fast SQL analytics on massive datasets. It can run SQL queries over petabytes of data in seconds to minutes without any infrastructure management. Key characteristics: Serverless: no clusters to provision or manage. Columnar storage: data stored in Capacitor format, highly compressed and optimized for analytical queries. Separation of storage and compute: scale independently. Pay per query ($5 per TB scanned) or flat-rate pricing. BigQuery ML: train ML models using SQL. BI Engine: in-memory analysis for sub-second queries. Streaming inserts: ingest real-time data. BigQuery integrates with Looker, Data Studio, and all major BI tools and is the flagship GCP analytics service.

Cloud IAM (Identity and Access Management) in GCP controls who can do what on which resources. The core model: Principal (who): Google account, service account, Google group, Cloud Identity domain. Role (what): a collection of permissions. Roles are: Primitive (Owner, Editor, Viewer — broad, legacy), Predefined (specific: roles/storage.objectViewer), or Custom (create your own). Policy: a binding of principal to role on a resource. Policies are inherited down the resource hierarchy (Organization → Folder → Project → Resource). Service Accounts: identities for workloads/VMs to access GCP APIs. IAM is deny-by-default — permissions must be explicitly granted. Use predefined roles and least-privilege principle.

Cloud SQL is GCP's fully managed relational database service supporting MySQL, PostgreSQL, and SQL Server. Google handles backups, replication, failover, encryption, and patches. Key features: High availability: synchronous replication to a standby instance with automatic failover; 99.95% SLA. Read replicas: offload read traffic. Automatic storage increases: no manual capacity planning. Cloud SQL Proxy: secure, encrypted connection without needing whitelisted IPs — the standard way to connect applications to Cloud SQL. Private IP: deploy inside a VPC for security. Point-in-time recovery: restore to any second within the backup window. Cloud SQL is suitable for lift-and-shift of existing relational database workloads to GCP.

Cloud Pub/Sub is GCP's fully managed, globally distributed message streaming service. It provides durable publish-subscribe messaging at massive scale. Topics: publishers send messages to a topic. Subscriptions: subscribers receive messages from a topic. Two delivery types: Pull (subscriber pulls messages) and Push (Pub/Sub pushes to a HTTPS endpoint). Key features: At-least-once delivery with acknowledgement-based exactly-once semantics available. Ordering: message ordering keys ensure ordered delivery per key. Dead letter topics: handle unprocessable messages. Retention: up to 7 days. Pub/Sub is the backbone for event-driven architectures and decoupling microservices on GCP — commonly used to trigger Cloud Functions, feed BigQuery streaming inserts, and connect to Dataflow pipelines.

Cloud Run is a fully managed serverless platform for running containerized applications. You provide a container image, and Cloud Run handles all infrastructure — automatically scaling from zero to thousands of instances based on incoming requests. Key features: Any language/runtime: if it runs in a container, it runs on Cloud Run. Scale to zero: no cost when no traffic. Request-based billing: pay only when handling requests (per 100ms). Concurrency: each instance handles multiple concurrent requests (unlike AWS Lambda's one-request-per-instance model), reducing cold starts and cost. Cloud Run Jobs: run tasks to completion rather than serving requests. Revision management: deploy new versions with traffic splitting. Cloud Run is the recommended way to deploy containerized web services on GCP without managing clusters.

Cloud Functions is GCP's serverless, event-driven compute service for running single-purpose code in response to events. Deploy a function; Google manages everything else. Triggers: HTTP (REST API), Cloud Pub/Sub, Cloud Storage (new file), Firestore, Firebase, and more. Supports Node.js, Python, Go, Java, .NET, Ruby, PHP. Gen 1: original version, one request per instance. Gen 2 (built on Cloud Run): better performance, larger instances, concurrency, longer timeouts, and VPC access. Use cases: image processing triggered by Cloud Storage uploads, database change processing, scheduled tasks, and lightweight microservices. For stateful or long-running workloads, use Cloud Run instead. Cloud Functions are billed per invocation, compute time, and networking.

Cloud Spanner is Google's globally distributed, strongly consistent, horizontally scalable relational database. It is unique in combining ACID transactions with horizontal scaling across regions — a combination previously considered impossible (the "CAP theorem trade-off"). Key features: True horizontal scaling: add nodes to increase throughput without downtime. Global strong consistency: reads anywhere see the latest committed data. Standard SQL: ANSI SQL 2011 compatible. 99.999% SLA (five nines) for multi-region configurations. Automatic sharding: data is split (sharded) across nodes automatically. Use cases: financial systems, global inventory, games leaderboards — any application requiring a relational database that needs to scale beyond what a single instance can handle. It is significantly more expensive than Cloud SQL, justified only for global-scale workloads.

Cloud Firestore is GCP's flexible, scalable NoSQL document database. It stores data in documents (JSON-like objects with fields) organized in collections. Key features: Real-time listeners: clients subscribe to documents/collections and receive updates in real time — ideal for mobile and web apps. Offline support: client SDKs cache data locally, enabling offline functionality. Strong consistency: unlike many NoSQL databases. Automatic scaling: from 1 to 1M+ operations/second. ACID transactions: multi-document. Security Rules: define access control that runs close to the data. Two modes: Native mode (recommended) and Datastore mode (backward compatible with old Cloud Datastore). Firestore is the primary database for Firebase applications.

A GCP VPC (Virtual Private Cloud) is a global, software-defined network that provides private connectivity for GCP resources. Unlike AWS and Azure VPCs which are regional, a GCP VPC is global — subnets in the same VPC can be in different regions and communicate privately without VPC peering. Key components: Subnets: regional resources with a primary IP range; resources (VMs, GKE nodes) deploy in subnets. Firewall rules: stateful allow/deny rules for ingress and egress traffic. Routes: define how traffic is forwarded. VPC Peering: privately connect two VPCs. Shared VPC: share a VPC across multiple projects — host project owns the network, service projects deploy resources into it. GCP's global VPC is a significant architectural advantage for multi-region applications.

Cloud Load Balancing in GCP distributes traffic across backend instances for scalability and high availability. GCP has several load balancer types. External Application Load Balancer (formerly HTTP(S) LB): global anycast IP, Layer 7, URL routing, SSL termination, CDN integration — the primary choice for web apps. External Network Load Balancer: Layer 4 (TCP/UDP), regional or global. Internal Application Load Balancer: Layer 7 for internal VPC traffic. Internal Network Load Balancer: Layer 4 for internal traffic. A unique GCP advantage: the Global External LB uses a single anycast IP that routes traffic to the nearest healthy backend globally — there is no DNS-level routing lag as with AWS Route 53 health checks. This makes global failover near-instantaneous.

Cloud Armor is GCP's DDoS protection and Web Application Firewall (WAF) service integrated with Cloud Load Balancing. It protects applications from the internet at the load balancer edge, before traffic reaches backends. Key features: DDoS mitigation: automatic protection against volumetric and protocol-based attacks, leveraging Google's global infrastructure which absorbs some of the largest DDoS attacks on record. WAF rules: pre-configured rule sets based on OWASP ModSecurity Core Rule Set (CRS) to block common web attacks (SQLi, XSS). Custom rules: IP allow/deny lists, geo-based blocking, rate limiting. Adaptive Protection: ML-based anomaly detection that suggests rules to block novel attacks. Edge policies: apply rules at Google's edge (PoP) before traffic reaches your data center for maximum protection.

GCP resources are organized in a four-level hierarchy. Organization: the root node, representing your company. Requires Cloud Identity or Google Workspace. Organization-level IAM policies apply to all resources. Folders: group projects (and other folders) for teams, environments, or departments. Apply policies at the folder level for bulk governance. Up to 10 levels of folder nesting. Projects: the base container for resources, APIs, billing, and configuration. Resources: individual services like VMs, buckets, databases. IAM policies set at a higher level are inherited downward (cannot be revoked lower). Organization Policies (via Organization Policy Service) enforce constraints across the hierarchy — e.g., restrict which regions resources can be created in, or disable service account key creation.

Vertex AI is Google's unified AI platform for building, deploying, and scaling ML models. It consolidates Google's ML services (AutoML, AI Platform, AI Hub) into a single platform. Key capabilities: AutoML: train high-quality models for image, video, text, and tabular data without writing ML code. Custom training: train your own models using TensorFlow, PyTorch, scikit-learn, or XGBoost on managed infrastructure. Model Registry: version and manage trained models. Vertex AI Predictions: deploy models as REST endpoints with automatic scaling. Pipelines: orchestrate ML workflows (based on Kubeflow Pipelines). Workbench: managed JupyterLab notebooks. Feature Store: manage and serve ML features. Gemini API on Vertex AI: access Google's large language models (Gemini Pro, Ultra) via enterprise API.

Cloud CDN (Content Delivery Network) is GCP's CDN that uses Google's globally distributed edge points of presence to cache content close to users, reducing latency and origin server load. It is integrated directly with the External Application Load Balancer — enable it with a single checkbox. Cloud CDN caches HTTP responses from your load balancer backends (GCE VMs, GKE, Cloud Storage, Cloud Run). Cache invalidation can be triggered via API. Cache keys are configurable to include/exclude headers and query parameters. Signed URLs and Signed Cookies enable time-limited access to private content. GCP's CDN is powered by the same global infrastructure used for YouTube — one of the largest CDN networks globally. It is tightly integrated with Cloud Storage for static asset delivery.

Cloud Dataflow is a fully managed, serverless stream and batch data processing service based on Apache Beam. You write pipelines using the Apache Beam SDK (Java or Python), and Dataflow manages the distributed execution, auto-scaling, and fault tolerance. Key concepts: Pipeline: the entire data processing graph. PCollection: a distributed dataset. Transforms: operations on PCollections (ParDo, GroupByKey, Combine, Flatten). Windowing: process infinite streams in time windows (tumbling, sliding, session). Watermarks: handle late-arriving data. Common patterns: ETL from Cloud Storage to BigQuery, real-time fraud detection from Pub/Sub, log processing. The same Beam pipeline runs in batch on historical data or streaming on real-time data without code changes.

Anthos is Google's hybrid and multi-cloud application platform that enables organizations to build and manage applications consistently across on-premises data centers, GCP, AWS, and Azure. Built on Kubernetes and Istio. Key components: GKE on-premises (GKE Enterprise): run GKE clusters on VMware or bare metal. Anthos Service Mesh: managed Istio for service-to-service communication policies, mTLS, and observability. Anthos Config Management: GitOps — sync Kubernetes configurations from a Git repository across all clusters. Cloud Run for Anthos: run Cloud Run workloads on any Anthos cluster. Migrate to Containers: modernize VMs into containers. Anthos solves the "stranded workloads" problem — organizations with on-premises investments can adopt cloud-native practices without a full cloud migration.

GCP networking has several architectural differences from AWS. Global VPCs: a single GCP VPC spans all regions; subnets are regional but in the same VPC — no VPC peering needed for inter-regional private communication. AWS VPCs are regional. Global anycast load balancing: GCP's External Application LB uses a single global IP with anycast routing to the nearest healthy backend. AWS requires Route 53 for geo-routing. Google's private network: GCP traffic between regions travels on Google's private fiber backbone, not the public internet. GKE networking: GKE uses VPC-native (alias IP) networking for pods — pods get IP addresses from the VPC subnet, enabling direct routing without NAT overlays. Pricing: GCP charges less for egress between regions compared to AWS. For enterprises with global applications, GCP's networking architecture often simplifies multi-region deployments.

Cloud Bigtable is Google's fully managed, wide-column NoSQL database service for very large analytical and operational workloads. It is the same database that powers Google Search, Google Analytics, Gmail, and Maps. Key characteristics: Petabyte scale: handles trillions of rows. Low-latency reads: sub-10ms for single-row reads. Time-series optimized: designed for time-stamped data like IoT sensor readings and financial market data. HBase compatible: migrate existing HBase workloads. Linear scaling: add nodes for more throughput proportionally. Data model: tables have row keys, column families, and cells with timestamps — no secondary indexes. Row key design is critical for performance. Use Bigtable for IoT, finance (stock tickers), AdTech, and ML feature data. It is not a general-purpose database — use Firestore or Cloud SQL for transactional workloads.

GCP uses a pay-as-you-go model billed per second (with some per-minute minimums). Unique pricing advantages: Sustained Use Discounts (SUDs): automatically applied to Compute Engine VMs when they run for more than 25% of a billing month — no commitment required. At 100% usage, you get 30% off. This is automatic — you get the discount just by running VMs continuously. Committed Use Discounts (CUDs): commit to 1 or 3 years for 55–70% savings on VMs and databases. Preemptible/Spot VMs: 60–91% savings for fault-tolerant workloads. Custom machine types: pay only for the exact vCPU and RAM you need. Free tier: certain services have monthly free usage (1 f1-micro VM, 5GB Cloud Storage, 1TB BigQuery per month). GCP generally has competitive pricing compared to AWS, especially for compute and networking egress.

Cloud Monitoring (formerly Stackdriver Monitoring) collects metrics, events, and metadata from GCP services, GKE, and custom applications. It provides dashboards, alerting policies, uptime checks, and SLO monitoring. Metrics can be from built-in GCP services or custom metrics sent via the Monitoring API. Cloud Logging (formerly Stackdriver Logging) collects, stores, and analyzes log data. All GCP services emit logs automatically. Logs Explorer allows querying logs with Cloud Logging query language. Log-based metrics convert log data into Monitoring metrics. Error Reporting: automatically groups exceptions. Cloud Trace: distributed tracing for latency analysis. Cloud Profiler: continuous CPU and memory profiling in production. Together they form GCP's operations suite for full observability.

Cloud Build is GCP's fully managed CI/CD service for building, testing, and deploying software. Define build steps in a cloudbuild.yaml file: each step is a Docker container that performs a task (run tests, build a Docker image, push to Artifact Registry, deploy to Cloud Run or GKE). Cloud Build executes steps sequentially or in parallel. Triggers: build automatically when code is pushed to Cloud Source Repositories, GitHub, or Bitbucket. Integration with Binary Authorization: ensure only builds signed by Cloud Build are deployed. Build artifacts are stored in Artifact Registry (the successor to Container Registry). Private pools: use your own VMs for builds requiring VPC connectivity. Cloud Build is Google's native CI/CD option; it integrates seamlessly with other GCP services but also supports deploying to non-GCP targets.

Secret Manager is GCP's secure, managed service for storing API keys, passwords, certificates, and other sensitive data. It is the GCP equivalent of AWS Secrets Manager or Azure Key Vault. Key features: Versioning: store multiple versions of a secret — roll back or rotate without changing application code (reference the latest version or a specific one). Automatic rotation: integrate with Cloud Scheduler to trigger secret rotation functions. Audit logging: every access to every version is logged in Cloud Audit Logs. IAM-based access control: grant the secretmanager.secretAccessor role to specific service accounts. CMEK: optionally encrypt secrets with customer-managed encryption keys. Access in code using the Secret Manager client library or REST API. Applications should retrieve secrets at startup, not hard-code them.

Workload Identity is the recommended way for GKE workloads (pods) to authenticate to GCP services without managing service account keys. Instead of downloading and mounting JSON key files into pods (a security risk), Workload Identity binds a Kubernetes service account to a Google service account via an IAM binding. When the pod makes API calls using the Google Cloud client libraries, it automatically obtains short-lived tokens from the metadata server. Setup: enable Workload Identity on GKE cluster, create a Google service account, create a Kubernetes service account, bind them: gcloud iam service-accounts add-iam-policy-binding with roles/iam.workloadIdentityUser. This eliminates the #1 GKE security risk: long-lived service account keys in container images or Kubernetes secrets.

GCP has a first-class Google Cloud Terraform provider (hashicorp/google) maintained jointly by HashiCorp and Google. It covers virtually all GCP resources: Compute Engine, GKE, Cloud Storage, Cloud SQL, BigQuery, IAM, and more. Key resources: google_compute_instance, google_container_cluster, google_storage_bucket. Authenticate via Application Default Credentials (ADC) or a service account key. Store Terraform state in a GCS bucket with state locking. GCP also provides Cloud Foundation Toolkit: opinionated, production-ready Terraform modules for common GCP patterns (VPC, GKE, project factory). Use google_project_service to enable APIs as part of infrastructure. GCP's Terraform provider also covers organization policy, billing, and monitoring resources for complete infrastructure management.

AlloyDB is Google's fully managed, high-performance PostgreSQL-compatible database designed for demanding transactional and analytical workloads. It delivers up to 4x faster transactional performance and 100x faster analytical query performance than standard PostgreSQL. Key architectural innovations: Disaggregated storage: compute and storage are separate, enabling independent scaling. Google Columnar Engine: automatically identifies hot data and stores it in a columnar format in memory for analytical queries — no need for a separate DW. ML-based vacuum: predictive maintenance replaces manual VACUUM operations. High availability: 99.99% SLA with <60 second RPO. AlloyDB sits between Cloud SQL (standard PostgreSQL) and Cloud Spanner (globally distributed) — ideal for applications needing high performance without global distribution. It integrates with AlloyDB Omni for on-premises deployment.

Both run containerized workloads but with different abstraction levels. Cloud Run: fully managed, serverless. You deploy a container image; Google manages everything — servers, networking, scaling, load balancing. Scales to zero. Best for stateless HTTP services, APIs, and event-driven workloads with variable or unpredictable traffic. Pay per request. No operational overhead but limited control. GKE: managed Kubernetes. You manage (or let Autopilot manage) the node pool. Full Kubernetes ecosystem: StatefulSets, DaemonSets, custom operators, CRDs. Best for complex microservices, stateful applications, batch workloads, and when you need fine-grained control or specific Kubernetes features. GKE Autopilot bridges the gap — fully managed nodes like Cloud Run but with the full Kubernetes API. For new containerized services, start with Cloud Run and migrate to GKE only if you hit Cloud Run's limitations.

BigQuery ML (BQML) enables data analysts to create and execute machine learning models using standard SQL queries directly in BigQuery, without exporting data or using Python. Create a model: CREATE MODEL dataset.my_model OPTIONS(model_type='logistic_reg') AS SELECT label, feature1, feature2 FROM training_table;. Evaluate: SELECT * FROM ML.EVALUATE(MODEL dataset.my_model). Predict: SELECT * FROM ML.PREDICT(MODEL dataset.my_model, (SELECT ... FROM prediction_table)). Supported model types: logistic regression, linear regression, K-means clustering, matrix factorization, deep neural networks (via TensorFlow), XGBoost, and importing pre-trained models from Vertex AI. BQML democratizes ML — analysts who know SQL can train models on petabytes of data already in BigQuery without data engineering pipelines.

GCP provides multiple tools for data sovereignty and compliance. Data residency: specify regions when creating resources to control where data is stored. Organization Policies: restrict resource creation to approved regions organization-wide — constraints/gcp.resourceLocations. VPC Service Controls: create security perimeters around GCP services to prevent data exfiltration — even malicious insiders or compromised APIs cannot move data out of the perimeter. Access Transparency: near-real-time logs of actions Google personnel take on customer data. Assured Workloads: deploy in compliance-controlled environments (FedRAMP, ITAR, CMMC, EU data boundary). Data Loss Prevention (DLP): automatically discover, classify, and de-identify sensitive data (PII, PCI, PHI) across Cloud Storage and BigQuery. Certificate Authority Service: manage internal PKI. GCP supports GDPR, HIPAA, ISO 27001, SOC 1/2/3, and many other certifications.

GCP's modern data analytics stack: Ingest: Pub/Sub for streaming events, Cloud Storage for batch files, Datastream for CDC (change data capture) from operational databases. Process: Dataflow (Apache Beam) for stream and batch ETL, Dataproc (managed Spark/Hadoop) for batch processing, Cloud Data Fusion (managed Apache NiFi) for visual ETL. Store: BigQuery as the central data warehouse/lake; Cloud Storage as the raw data lake; Bigtable for high-throughput low-latency access. Analyze: BigQuery SQL + BQML, Looker (BI), Vertex AI (advanced ML). Orchestrate: Cloud Composer (managed Apache Airflow) or Workflows. Govern: Dataplex (unified data governance), Data Catalog (metadata), DLP (data classification). The complete pipeline from raw event to business insight can be entirely serverless and managed on GCP.

GKE Autopilot is a fully managed Kubernetes mode where Google manages the entire infrastructure including nodes — you only manage Kubernetes objects (Pods, Deployments, Services). Differences from Standard: No node management: you never create or manage node pools. Google provisions, scales, and maintains nodes automatically. Per-Pod billing: billed for actual pod resource requests, not node VMs. No cost for idle node capacity. Security hardened by default: Shielded VMs, secure boot, workload identity enforced. No access to nodes: no SSH, no DaemonSets (privileged), no host namespaces. Automatic bin-packing and scaling: Google optimally packs pods and scales nodes within seconds. When to use Autopilot: most stateless workloads, teams that want Kubernetes without node management. Standard mode is needed for specialized node hardware, custom node configurations, or DaemonSets.

BigQuery data governance uses a layered IAM approach. Dataset level: the primary access control unit. Grant roles like roles/bigquery.dataViewer (read tables/views), roles/bigquery.dataEditor (modify), roles/bigquery.dataOwner. Table/View level: table-level IAM for fine-grained access to specific tables. Row-level security: Row Access Policies restrict which rows a user can see based on their identity. Column-level security: Policy Tags (created in Data Catalog) label columns as sensitive; you then define IAM policies on the taxonomy tag — only users with the tag's fine-grained reader role can see those column values. Authorized views: share query results without granting access to source tables. VPC Service Controls: prevent data exfiltration from BigQuery. Combine these layers for defense-in-depth data access control.

GCP multi-region HA uses two patterns. Single-region multi-zone: deploy resources across 3+ zones in one region. For VMs: use a Multi-Zone Managed Instance Group. For GKE: multi-zone node pools and regional clusters. For databases: Cloud SQL HA uses synchronous replication to a standby in another zone. This protects against zone failures with near-zero RPO. Multi-region: deploy across multiple regions for protection against regional outages. Use Global Load Balancing (single anycast IP routes to nearest healthy region). For data: Cloud Spanner multi-region, Firestore multi-region, GCS multi-region buckets. For GKE: deploy workloads in clusters in multiple regions with a Global LB frontend. Key tools: Cloud Endpoints, Traffic Director (service mesh control plane), Cloud DNS with geo-routing. GCP's global anycast LB makes multi-region failover essentially instant — no DNS propagation delays.

VPC Service Controls creates security perimeters around GCP APIs and services to prevent data exfiltration. It works at the API level — even if an attacker compromises a VM or a Google employee account within your environment, they cannot copy data from BigQuery to a bucket outside the perimeter. Define an Access Policy with a Service Perimeter that lists protected projects and services (BigQuery, Cloud Storage, Cloud SQL). Resources inside the perimeter can only call APIs of other services inside the same perimeter. Access Levels: define conditions (IP ranges, device attributes, users) that allow access from outside the perimeter. Ingress/Egress rules: explicitly allow specific cross-perimeter data flows. VPC Service Controls go beyond IAM — IAM controls who can do what; VPC Service Controls controls where data can flow regardless of who is making the request.

Google invented SRE as a practice for running large-scale production systems reliably. Google uses GCP's own tools and the SRE philosophy across its products. Core SRE concepts as implemented in GCP: SLIs/SLOs/SLAs: Cloud Monitoring allows defining Service Level Objectives (SLOs) based on metrics like availability and latency. Error budget: if your error budget is exhausted (SLO not met), new feature work stops in favor of reliability work. Cloud Operations Sandbox: practice SRE on a simulated production system. Traffic Director: xDS-based service mesh for advanced traffic management (canary deployments, circuit breaking). Chaos Engineering: test resilience by deliberately injecting failures. GCP's documentation includes the free SRE Book and SRE Workbook that document Google's practices. Cloud Monitoring's SLO feature makes operationalizing SRE concepts straightforward.

Eventarc is GCP's event routing service that triggers Google Cloud services based on events from GCP services, custom applications, or external sources via Cloud Audit Logs. It provides a standardized, consistent eventing experience using CloudEvents (CNCF standard). Eventarc routes events to: Cloud Run, Cloud Functions (2nd gen), GKE, and Workflows. Event sources: Cloud Audit Logs (every API call becomes an event — create a VM, upload to Storage, etc.), Cloud Pub/Sub, third-party sources. Example trigger: "When a file is created in Cloud Storage (via audit log), route the event to a Cloud Run service." Eventarc replaces the various service-specific trigger mechanisms with a unified system. It is foundational to Google's event-driven architecture vision alongside Pub/Sub and Cloud Tasks.

GCP network egress pricing has two tiers with significant performance and cost differences. Premium Tier (default): traffic enters Google's private network at the PoP nearest to the source and travels entirely on Google's global fiber backbone to the destination. Cold-potato routing: traffic gets onto Google's network as early as possible. Lowest latency and highest reliability. Higher cost. Standard Tier: traffic uses the public internet between regions. Hot-potato routing: traffic gets off Google's network as early as possible. Lower cost but higher latency and variable performance. Significant cost differences: egress to the internet from us-central1 is ~$0.085/GB (Premium) vs ~$0.045/GB (Standard). For latency-sensitive global applications, Premium Tier is essential. For batch data transfers and non-latency-sensitive workloads, Standard Tier saves cost. Choose at the load balancer level. Traffic within the same region is free (same VPC).

TrueTime is Google's globally synchronized clock API used internally in Cloud Spanner to achieve external consistency (the strongest consistency guarantee — stronger than linearizability). TrueTime exposes the current time as an interval [earliest, latest] with a known error bound (typically under 7ms), based on GPS and atomic clocks in every Google data center. Spanner uses this to implement commit wait: before committing a transaction, the database waits until the commit timestamp is safely in the past (beyond TrueTime's uncertainty). This guarantees that any subsequent read on any replica will see the committed data. External consistency means: if transaction T2 starts after T1 commits (in real-world time), T2 always sees T1's writes — even across continents. This eliminates the need for distributed coordination protocols like 2PC for certain operations and is what enables Spanner's globally-consistent, serializable transactions.