Quiz results are saved to your browser's local storage and will persist between sessions.
Node service accounts, the two-identities-linked-by-annotation model of Workload Identity, and the node-sizing arithmetic that decides whether a pod can actually be scheduled. Most of these came from real failures, not from reading docs.
GKE node pools implicitly use the default Compute Engine service account unless one is explicitly specified. What are the two independent reasons NOT to rely on it, beyond just "it might not exist yet"?
Confirmed live: gcloud iam service-accounts list | grep compute returned 0 items in a real project — not a timing issue, the SA never existed. Separately, even when it does exist, its broad project-level permissions are a genuine anti-pattern for every node to trust by default. A dedicated, minimal-scope node service account fixes both problems at once.
You set remove_default_node_pool = true on a google_container_cluster resource and give the SEPARATE google_container_node_pool resource a proper node_config with a dedicated service account. Cluster creation still fails on a missing-service-account error. Why?
Even with remove_default_node_pool = true, the GKE API requires an initial node pool to exist momentarily during cluster creation (Terraform deletes it right after). That transient pool reads node_config from google_container_cluster directly. Without a matching node_config there too, it falls back to the same missing default SA — same error, different resource, easy to miss on a first encounter.
A Kubernetes ServiceAccount named my-app-sa and a GCP IAM service account named sa-backend-dev@project.iam.gserviceaccount.com both exist. Are these the same identity?
Workload Identity links a Kubernetes ServiceAccount to a GCP IAM service account through the iam.gke.io/gcp-service-account annotation on the K8s SA — not through any naming convention. Two objects can have completely unrelated names and still be correctly linked, or have similar names and NOT be linked, if the annotation is missing or wrong. Always verify the actual annotation, not the names, when confirming the binding is real.
You have roles/owner on a GCP project, confirmed via gcloud projects get-iam-policy, but kubectl get pods still returns "Forbidden" on a freshly created GKE cluster. What's the most likely explanation?
GCP IAM controls whether you can reach the GKE API and manage the cluster resource itself; Kubernetes RBAC (a separate, cluster-internal system) controls what you can do once you're talking to the cluster's own API server. A fresh cluster often has no RBAC binding for your personal account (Terraform-created bindings frequently target a Google Group, not individual users) — hence Forbidden despite roles/owner.
kubectl get pods fails with a Forbidden error, but IAM policy checks confirm the active account has roles/owner with no conditions attached. What's a likely cause worth checking before assuming the IAM policy itself is wrong?
When multiple gcloud accounts are credentialed on one machine, kubeconfig entries can become mismatched with whichever account is "active" versus which one was active when the entry was generated. Regenerating the kubeconfig entry and re-testing with a non-destructive check like kubectl auth can-i isolates whether the identity itself — not the IAM policy — was the actual problem.
You change a GKE node pool's machine_type in Terraform (e.g. e2-small to e2-standard-2) and run apply. What should you expect?
Machine type is a forces-replacement attribute for node pools — Terraform destroys the old pool and creates a new one with the new size. This is a real operational consideration: on a production workload, this would cause visible disruption while nodes cycle, not just a lab inconvenience.
A GKE node shows Capacity: cpu: 2 but Allocatable: cpu: 940m in kubectl describe node. Why is allocatable so much lower than capacity?
System reservations plus DaemonSet requests can consume a large fraction of a small node's resources before any application pod is scheduled — on a 2-vCPU node, ending up with under 1 full vCPU allocatable is normal, not a misconfiguration. This is exactly why a pod's resource request that looks small on paper can still fail to schedule with "Insufficient cpu/memory."
A pod's FailedScheduling event says "Insufficient memory" on an e2-small node. You resize the node pool to e2-medium and the memory error disappears — but scheduling still fails, now with "Insufficient cpu" alone. Why didn't the resize fix the CPU side too?
Shared-core machine types (e2-micro/e2-small/e2-medium) all cap out at the same 2 vCPUs — stepping between them only changes memory. Fixing a CPU-allocatable shortfall specifically requires moving to a machine family that actually scales vCPU count, such as the e2-standard-* line.
A GKE cluster has workload_identity_config set correctly. Pods still can't use Workload Identity to authenticate as their intended GCP service account. What's a likely missing piece?
Workload Identity configuration exists at two separate levels: the cluster-wide workload_identity_config block enables the mechanism in principle, but each node pool independently needs workload_metadata_config set to GKE_METADATA for pods scheduled on it to actually be able to use that mechanism. Missing it on the node pool is a common, easy-to-overlook gap even when the cluster-level config looks correct.
Why create a GKE cluster with remove_default_node_pool = true plus a separate, explicit google_container_node_pool resource, instead of just letting the cluster's inline default node pool exist?
Coupling node pool lifecycle to the cluster resource itself removes your ability to independently scale, upgrade, or reconfigure nodes without a cluster-level change. Separating them is standard practice specifically to decouple those lifecycles — even for a single-node lab cluster, it's worth building the habit rather than treating it as unnecessary ceremony.