Security
Cloud IAM
Identity and Access Management — who can do what on which resource
AWS equivalent
IAM
Architecture Diagram
GCP Resource Hierarchy & IAM Inheritance
💡 Key concept: IAM policies set at the Organization or Folder level are automatically inherited by all child projects — you set a policy once and it applies everywhere below. Unlike AWS where each account is a fully separate IAM boundary.
AWS → GCP: Key Differences
- ▸
Same core model: principals, permissions, policies. But GCP has a clearer resource hierarchy (Org → Folder → Project → Resource).
- ▸
Policies are attached to RESOURCES (not principals like AWS).
- ▸
Roles in GCP: Basic (Owner/Editor/Viewer — avoid), Predefined (service-specific), Custom.
- ▸
Service accounts ≈ IAM roles for EC2 instances. But in GCP, service accounts are also principals.
Key Concepts to Know
- 1
Principal types: Google accounts, service accounts, Google groups, domains.
- 2
Service accounts: machine identities for GCP resources. One per workload with minimal permissions.
- 3
Workload Identity (GKE): map a Kubernetes service account to a GCP service account. Eliminates key files.
- 4
Conditional IAM: grant access only under specific conditions (time, IP range, resource attributes).
- 5
IAM Recommender: ML-powered tool that suggests removing excess permissions.
DCE Interview Tips
- ★
Security answer: 'Each Cloud Run service gets its own service account with only the permissions it needs.'
- ★
For customer security concerns: 'Workload Identity means no service account keys in code — eliminates the #1 cause of GCP credential breaches.'
Common Gotchas
- !
Owner/Editor basic roles grant massive permissions — almost never appropriate in production.
- !
Service account keys don't expire and can be exfiltrated. Use Workload Identity instead.