IAM

GCP IAM binds who can do what on which resource through identities, roles, and policies. FullStack teams should separate human access from workload access: developers use groups with short-lived credentials, while Cloud Run, GKE pods, and CI use dedicated service accounts with scoped custom roles.

| Identity | Typical use | |----------|-------------| | User / group | Engineer access via Google groups | | Service account | Runtime and automation identity | | Workload Identity | Kubernetes pod → GCP API without JSON keys |

					gcloud projects add-iam-policy-binding my-project \
  --member="serviceAccount:api-runner@my-project.iam.gserviceaccount.com" \
  --role="roles/cloudsql.client"
				

Prefer predefined roles when they fit; compose least-privilege custom roles when they do not. Audit with Policy Analyzer and Cloud Audit Logs.

On interviews: service account keys versus Workload Identity; principle of least privilege; project/folder/org hierarchy; conditional IAM; breaking CI with overly broad roles.

Common pitfalls: downloading service account keys into repos or laptops; one super-admin service account for every microservice; granting `Editor` instead of task-specific roles.

The trade-off is velocity from broad permissions versus blast radius, auditability, and compliance expectations.

Checklist:

• No long-lived keys in application repos.
• One service account per workload with minimal roles.
• Use Workload Identity on GKE and attached SA on Cloud Run.
• Review IAM bindings in code review like application logic.