L12. IAM and Identity: Service Accounts, Roles, and Workload Identity Federation
Video generating
Check back soon for the video lesson on IAM and Identity: Service Accounts, Roles, and Workload Identity Federation
Cloud IAM controls who can do what on Google Cloud resources. The Digital Leader exam tests IAM roles, service accounts, Workload Identity Federation, and the principle of least privilege.
Cloud Identity and Access Management (IAM)
Cloud IAM lets you control who (identity) has what access (role) to which resources (resource). IAM policy structure: a policy binds one or more members (identities) to a role on a resource.
IAM Members (Principals)
| Member Type | Description |
|---|---|
| Google Account | Individual Google identity (user@gmail.com) |
| Service Account | Identity for applications and workloads (not humans) |
| Google Group | Collection of users and service accounts |
| Cloud Identity domain | All users in a Google Workspace or Cloud Identity domain |
| allUsers | Anyone on the internet (use with caution) |
| allAuthenticatedUsers | Any authenticated Google account |
IAM Roles
Roles bundle permissions. There are three types:
Basic roles (legacy): Owner, Editor, Viewer. Broad permissions; not recommended for production.
Predefined roles: created by Google for specific services with carefully scoped permissions (e.g., roles/storage.objectViewer — can only read Storage objects).
Custom roles: you define the exact permissions. Used when predefined roles have too many permissions.
Principle of least privilege: grant only the minimum permissions needed for a task, preferably predefined roles rather than basic roles.
Service Accounts
Service accounts are identities used by applications, VMs, and workloads (not humans). Best practices:
- Create a dedicated service account per application/workload (not a shared default)
- Grant only the roles needed (least privilege)
- Avoid creating service account keys when possible; use Workload Identity Federation instead
- Google-managed keys: Google rotates automatically; preferred
- User-managed keys: you create, download, and rotate; higher risk if keys are leaked
Workload Identity Federation
Workload Identity Federation allows external workloads (GitHub Actions, AWS, Azure, on-premises) to authenticate to Google Cloud using short-lived tokens rather than service account keys. Benefit: eliminates the risk of long-lived credential leaks. External identity providers are trusted, not keys.
Cloud Identity
Cloud Identity is an Identity as a Service (IDaaS) product for managing users and groups without Google Workspace.
Policy Inheritance
IAM policies set at the Organization or Folder level cascade to child resources. You can grant additional permissions at lower levels but cannot restrict inherited permissions. Exam tip: Use predefined roles, not basic roles (Owner/Editor/Viewer). Service accounts for workloads; Workload Identity Federation instead of service account keys where possible.
- ✓IAM binds members (users, service accounts, groups) to roles on Google Cloud resources
- ✓Three role types: Basic (broad, avoid), Predefined (service-specific, recommended), Custom (exact permissions)
- ✓Service accounts are identities for applications and workloads; create one per workload with least privilege
- ✓Workload Identity Federation enables external workloads to authenticate using short-lived tokens instead of service account keys
- ✓IAM policies cascade from Organization to Folder to Project to Resource; lower levels can add but not restrict inherited permissions
1. A Cloud Run application needs to read from a Cloud Storage bucket. What is the recommended approach to grant this access?
2. A GitHub Actions workflow needs to deploy to Google Cloud without storing long-lived service account keys as GitHub secrets. Which feature enables this?
Recommended: Pluralsight
Reinforce these lessons with Pluralsight's Google Cloud paths: structured video courses, GCP console labs, and practice exams for the Digital Leader certification.