GCP🟡 What is GCP?
›GCP vs AWS vs Azure — Service Mapping
| AWS | Azure | GCP | Purpose |
|---|---|---|---|
| EC2 | VM | Compute Engine | Virtual machines |
| S3 | Blob Storage | Cloud Storage (GCS) | Object storage |
| EKS | AKS | GKE | Managed Kubernetes |
| RDS | Azure SQL | Cloud SQL / AlloyDB | Managed database |
| Lambda | Functions | Cloud Functions | Serverless compute |
| IAM Role | Managed Identity | Workload Identity | App authentication |
| CloudWatch | Azure Monitor | Cloud Monitoring | Observability |
| CloudTrail | Activity Log | Cloud Audit Logs | API audit trail |
| Redshift | Synapse | BigQuery | Data warehouse |
GCP concepts + gcloud CLI basics
🔐 IAM & Workload Identity
›GCP IAM key concepts
GCP IAM is more granular than AWS. You can assign roles at the organisation, folder, project, or individual resource level. The most restrictive ancestor rule: a deny at org level cannot be overridden at project level.
Service accounts + Workload Identity + role bindings
☸️ GKE — Kubernetes
›Why GKE?
Google invented Kubernetes. GKE gets new K8s versions first, has the tightest integration with GCP services, and Autopilot mode offers true serverless Kubernetes. GKE is widely considered the best managed K8s experience.
GKE create (Autopilot + Standard) + features
🪣 Storage Options
›Cloud Storage, Cloud SQL, lifecycle policies
🌐 Networking
›GCP networking is global by default
Unlike AWS where a VPC is regional, a GCP VPC is global. One VPC can have subnets in Mumbai, London, and US-East. This simplifies multi-region architectures significantly.
VPC, firewall, load balancers, Cloud Armor
☸️ GKE — Deep Dive
›GKE is Google's managed Kubernetes — the original managed K8s service
| GKE | AKS | EKS | |
|---|---|---|---|
| Control plane cost | Free (Standard), $0.10/hr (Autopilot) | Free | $0.10/hr per cluster |
| Autopilot mode | Yes — fully managed nodes, pay per pod | No equivalent | Fargate (partial) |
| Upgrade strategy | Node auto-upgrade, surge upgrade | Node pool upgrade | Managed Node Group update |
| Networking | VPC-native, Alias IPs | Azure CNI | VPC CNI |
| Identity for pods | Workload Identity (GKE) | Azure Workload Identity | IRSA |
GKE modes — Standard vs Autopilot
Standard mode: you manage node pools — choose VM types, sizes, number of nodes. Cluster Autoscaler adds/removes nodes. Same as AKS node pools. Full control, you pay for nodes. Autopilot mode: Google manages all nodes. You only define pods. Google provisions the right resources. You pay per pod CPU/memory request, not per node. Zero node management. Best for teams who want Kubernetes without ops overhead.
# Create GKE cluster 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 --workload-pool=my-project.svc.id.goog # enable Workload Identity # Get credentials gcloud container clusters get-credentials my-cluster --region us-central1 # Autopilot cluster (no node management) gcloud container clusters create-auto my-autopilot-cluster --region us-central1
🔐 GCP IAM and Workload Identity
›GCP IAM — projects, service accounts, roles
| Concept | GCP | AWS equivalent | Azure equivalent |
|---|---|---|---|
| Organisation unit | Project | AWS Account | Subscription |
| Human identity | Google Account / Workspace user | IAM User | Azure AD User |
| Service identity | Service Account | IAM Role / Instance Profile | Managed Identity |
| Permissions group | IAM Role | IAM Policy | Azure Role |
| Pod identity | Workload Identity (SA ↔ K8s SA federation) | IRSA | Azure Workload Identity |
# Create service account gcloud iam service-accounts create payment-svc --display-name="Payment Service Account" # Grant it access to a GCS bucket gsutil iam ch serviceAccount:payment-svc@myproject.iam.gserviceaccount.com:roles/storage.objectAdmin gs://my-payment-bucket # Workload Identity — link GCP SA to K8s SA kubectl annotate serviceaccount payment-k8s-sa iam.gke.io/gcp-service-account=payment-svc@myproject.iam.gserviceaccount.com gcloud iam service-accounts add-iam-policy-binding payment-svc@myproject.iam.gserviceaccount.com --role roles/iam.workloadIdentityUser --member "serviceAccount:myproject.svc.id.goog[production/payment-k8s-sa]"
🛠️ Core GCP Services
›Core GCP services every DevOps engineer should know
| Service | What it is | AWS equivalent | Azure equivalent |
|---|---|---|---|
| GKE | Managed Kubernetes | EKS | AKS |
| Cloud Run | Serverless containers — deploy container, Google manages everything | ECS Fargate / Lambda containers | Azure Container Apps |
| GCS (Cloud Storage) | Object storage — buckets and objects | S3 | Azure Blob Storage |
| Cloud SQL | Managed PostgreSQL/MySQL/SQL Server | RDS | Azure Database |
| Artifact Registry | Container and artifact registry (replaces GCR) | ECR | ACR |
| Cloud Build | Managed CI/CD — build, test, deploy | CodeBuild | Azure Pipelines |
| Cloud Pub/Sub | Managed message queue | SQS/SNS | Azure Service Bus |
| Cloud Monitoring | Metrics, alerts, dashboards | CloudWatch | Azure Monitor |
| Secret Manager | Managed secrets storage | AWS Secrets Manager | Azure Key Vault |
| VPC | Virtual private network — global (not per-region like AWS) | VPC (per-region) | VNet (per-region) |
🎯 Interview Questions
›GCP · ENGINEER
What is GCP Workload Identity and why is it better than service account keys?
Service account keys are JSON files containing long-lived credentials for a GCP service account. Problems: they never expire by default, if leaked they give permanent access, they must be manually rotated, and storing them in Kubernetes secrets means they are accessible to anyone who can read that secret. Workload Identity solves this by letting GKE pods authenticate as GCP service accounts using short-lived tokens automatically issued by Google. The pod has a Kubernetes service account annotated with a GCP service account. When the pod calls GCP APIs, the GKE metadata server intercepts the call and returns a short-lived OIDC token that GCP accepts as authentication. No credentials to store, no rotation, tokens expire in one hour, and if a pod is compromised the blast radius is limited to what that specific service account can access. Setup: enable workload pool on cluster, create GCP service account, bind it to the K8s service account, annotate the K8s service account. This is exactly equivalent to AWS IRSA and Azure Workload Identity — the same concept implemented by each cloud provider.
GCP · ARCHITECT
Compare GKE Autopilot vs Standard mode. When do you choose each?
GKE Standard: you configure and manage node pools. You choose machine types, set autoscaling parameters, can SSH to nodes, can run privileged DaemonSets, full control over node-level configuration. You pay per node even when pods are not running. Best for: workloads needing specific node configuration, GPU nodes, needing node-level access for debugging, cost optimisation with custom machine types. GKE Autopilot: Google manages all nodes. No node configuration, no node SSH. You define only pod specs and resource requests. GKE provisions nodes as needed. You pay per pod CPU and memory, not per node — zero cost when no pods running. Best for: teams that do not want to manage nodes, variable workloads that benefit from true scale-to-zero, teams focused on application development not infrastructure. Limitations of Autopilot: some privileged operations not allowed (cannot run DaemonSets, cannot use hostPath volumes), limited to specific machine types. At a startup: Autopilot. At HPE-scale with specific node requirements: Standard.
GCP · ENGINEER
What is the difference between GKE Standard and Autopilot modes?
GKE Standard: you manage the node pools — choose VM type (e2-standard-4, n2-highmem-8), number of nodes, disk size, and OS. Cluster Autoscaler adds and removes nodes based on pending pods. You pay for the VM instances whether pods use them fully or not. Full control: choose GPUs, spot VMs, preemptible instances. GKE Autopilot: Google manages all infrastructure. You never see or configure nodes. You only define pods and their resource requests. Google automatically provisions the right resources for your pods. You pay per pod CPU and memory request — no wasted capacity. Autopilot enforces resource requests on all pods (mandatory), runs pods in a hardened environment, and handles node upgrades transparently. Choose Standard when: you need specific VM types (GPUs, large memory), you run DaemonSets, you have workloads that do not specify resource requests, you want to optimise VM costs with committed use discounts. Choose Autopilot when: you want zero node management, your team is small, you are fine with pod-based pricing, you want automatic security hardening.
GCP · ENGINEER
How does GCP Workload Identity work and how does it compare to AWS IRSA?
GCP Workload Identity links a Kubernetes ServiceAccount to a GCP Service Account, allowing pods to access GCP services without key files. The setup: enable Workload Identity on the GKE cluster (--workload-pool flag). Create a GCP Service Account with the needed permissions. Annotate the Kubernetes ServiceAccount with the GCP SA email (iam.gke.io/gcp-service-account annotation). Add a binding on the GCP SA: allow the K8s SA to impersonate it (roles/iam.workloadIdentityUser). When the pod runs with that K8s SA: GKE automatically injects credentials. The GCP SDK in the pod uses Application Default Credentials (ADC) which queries the GKE metadata server, gets a short-lived token for the GCP SA, and uses it. Comparison with AWS IRSA: identical concept — both use OIDC federation between K8s ServiceAccounts and cloud IAM systems. GCP uses IAM binding on the GCP Service Account. AWS IRSA uses a trust policy on the IAM Role. Azure Workload Identity uses federated credentials on the Managed Identity. All three: zero stored credentials, short-lived tokens, per-pod identity, auditable access.
GCP · ENGINEER
What is Cloud Run and when do you use it instead of GKE?
Cloud Run is a fully managed serverless container platform. You provide a container image, Cloud Run handles: servers, scaling (0 to N, back to 0), load balancing, SSL, custom domains, and upgrades. You pay only when requests are being processed — zero cost when idle. Deploy in seconds with gcloud run deploy. GKE is a managed Kubernetes cluster. You manage node pools, configure networking, install add-ons, and handle pod scheduling. More control, more complexity, more cost. When to choose Cloud Run: stateless HTTP services (REST APIs, webhooks, web apps), event-driven functions (triggered by Pub/Sub, Cloud Storage events), teams that want zero infrastructure management, workloads with variable or bursty traffic where scale-to-zero matters. When to choose GKE: complex microservices with inter-service communication (service mesh), workloads needing DaemonSets, StatefulSets, or Kubernetes-specific features, multi-cloud portability (Kubernetes runs everywhere), teams with existing Kubernetes expertise, GPU workloads (Cloud Run does not support GPUs). The decision is about team complexity tolerance: Cloud Run is simpler but less flexible. GKE is more powerful but requires Kubernetes expertise.
GCP · ARCHITECT
Compare GCP, AWS, and Azure for a multi-cloud Kubernetes deployment.
All three offer managed Kubernetes with similar core capabilities. Key differences for multi-cloud: Networking: GCP VPC is global (one VPC spans all regions). AWS and Azure VPC/VNet are regional (need VPC peering for cross-region). GCP makes multi-region networking simpler. Control plane cost: GCP GKE Standard and Azure AKS are free. AWS EKS charges $0.10/hr per cluster (~$73/month). For many clusters, EKS cost adds up. Identity for pods: GCP has Workload Identity, AWS has IRSA, Azure has Workload Identity — all equivalent in concept, all require configuration. Managed services: GCS, S3, Azure Blob — equivalent. GCP BigQuery (no equivalent — fastest analytics data warehouse). GCP Pub/Sub vs SQS vs Azure Service Bus — similar. Tooling: all three have Terraform providers and Helm chart support. All three work with ArgoCD and FluxCD. For a true multi-cloud deployment using Kubernetes: use the same Kubernetes manifests/Helm charts across all three. Use Terraform with separate provider configs per cloud. Use one ArgoCD instance managing clusters in all three. Service account/identity setup is cloud-specific and the most complex part. Networking between clouds requires either VPN or dedicated interconnect.
Continue Learning