Memory hook: Grant the action to the actual caller at the narrowest scope.
Must remember
An IAM binding associates a principal with a role on a resource, optionally under conditions. Basic roles are broad; predefined roles are service-oriented; custom roles bundle supported permissions for specific needs. Inherited allow grants can broaden access; deny policies and organization constraints have distinct effects. Removing one narrow grant does not remove an inherited grant elsewhere.
A service account is both an identity used by workloads and a resource whose use can be controlled. Attaching/acting as a service account and creating short-lived impersonated credentials require different permissions. Grant API permissions to the runtime identity, not merely to the human who deployed it.
Prefer attached workload identity, service-account impersonation or Workload Identity Federation over downloaded long-lived keys where supported. External federation exchanges trusted external identity for controlled Google access. Protect audience, attribute mappings/conditions and role bindings; a permissive trust mapping can expose many unintended callers.
Use Secret Manager for secrets and Cloud KMS for encryption-key control. Default encryption does not mean everyone should read the data. Customer-managed keys introduce key IAM, location, rotation, availability and destruction considerations. Separation between key administrators and data users reduces excessive privilege.
VPC Service Controls creates supported service perimeters to reduce data exfiltration; it complements IAM rather than replacing it. Identity-Aware Proxy controls supported application/tunnel access. Audit logs identify activity under their service-specific categories/settings; enable required data-access visibility deliberately and protect the sink destination.
For permission denied, establish the real principal, resource project, required permission, inherited/conditional/deny policies and any perimeter/org-policy restriction. Granting Owner to “make it work” conceals the diagnosis and creates risk.
Review details
Service Account User (roles/iam.serviceAccountUser) includes acting as the service account for supported resource attachment. Service Account Token Creator (roles/iam.serviceAccountTokenCreator) supports generating impersonated credentials and supported signing operations. Granting attachment rights is not the same as giving the human direct access to every resource the account can read, but launching code as that account can be a privilege-escalation path.
Application Default Credentials searches supported credential locations; it is not an IAM role. Workforce federation serves external people, workload federation software. To diagnose a denied call, distinguish authentication failure, missing permission, inherited deny/boundary, organization policy and VPC Service Controls. Principal access boundaries constrain eligible resources for supported access; they do not grant permissions.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Application accesses a bucket | Grant the workload identity the necessary bucket role. |
| CI outside Google Cloud | Federated short-lived credentials with narrowly defined trust. |
| Reduce exfiltration through supported managed APIs | VPC Service Controls plus IAM and data controls. |
Traps
- Service-account use permission is not identical to the service account’s resource permissions.
- A VPC Service Controls perimeter does not replace IAM.
Active recall
1. What are the three basic pieces of a binding?
Principal, role and resource scope, with optional conditions.
2. Why can removing one grant fail to revoke access?
Another direct or inherited binding may still allow it.
3. Why prefer short-lived credentials?
They reduce stored reusable secret exposure and support controlled identity federation/impersonation.
4. Secret Manager versus Cloud KMS?
Secret Manager stores/retrieves secret values; KMS manages cryptographic keys and operations.
5. Who needs the bucket permission in a running app?
The actual runtime caller identity, not necessarily the deploying user.