Google Cloud IAM becomes easier to reason about when roles, principals, service accounts, and impersonation are treated as one authorization path. For Professional Cloud Architect, the critical question is not whether a role exists; it is which principal can obtain which permissions, on which resource, through which identity transition.
Service accounts are unusual because they are both principals and resources. As principals, they can receive IAM roles on buckets, projects, databases, and other resources. As resources, they can be attached to compute or impersonated by users, workloads, or other service accounts when the caller has the required permissions. That dual role is the source of much of their power—and much of the risk.
The approved internal discussion of Google Cloud service accounts provides useful foundation, but production architecture needs one extra step: draw the impersonation chain. A user may impersonate service account A, which can impersonate B, which has access to a protected resource. The effective privilege is defined by the whole chain, not by the user’s direct roles.
Start with the resource and the required action
Authorization design should begin with the operation a workload needs: read objects from one bucket, publish to one topic, query one dataset, or administer one cluster. From that requirement, identify the smallest predefined or custom role that provides the permissions and the resource level where the grant belongs.
Avoid beginning with project-wide Editor or Owner because it is convenient. Broad roles hide the actual contract between the workload and the resource. Fine-grained grants make later review, troubleshooting, and migration much easier because the intended permission is explicit.
The permission design should also capture whether the workload needs read, write, administration, or impersonation capabilities. These categories have different risk. A service that only reads objects should not inherit broad storage administration, and a deployment process that attaches an identity does not automatically need permission to mint tokens for that identity.
Service accounts should represent workload identities
A service account is appropriate when a non-human workload needs a Google Cloud identity. A VM, Cloud Run service, pipeline, external workload, or automation process can use a service account so permissions are attached to the workload role rather than to an employee.
Use separate service accounts when workloads have different privilege or lifecycle. Sharing one highly privileged account across unrelated applications creates an identity blast radius: compromise of any one workload can expose everything the shared identity can reach.
Service-account naming and ownership improve incident response. A name tied to the workload and environment, plus labels or inventory metadata, makes it easier to decide whether an identity is still needed. Generic names such as automation-sa create long-lived ambiguity when the original system is retired.
Workload identities should also be segmented by environment. Reusing the same service account in development and production lets a lower-trust environment become a path toward production data. Separate identities make it possible to grant different permissions and to investigate activity without ambiguity.
Prefer attachment or federation over long-lived keys
Google recommends avoiding service account keys when a more secure authentication method is available. Workloads running on Google Cloud can often use an attached service account. GKE workloads can use Workload Identity Federation for GKE. External workloads can use Workload Identity Federation instead of storing a static JSON key.
If a key is unavoidable, bring it under centralized secrets management with clear ownership, rotation, monitoring, and a plan to remove it when a better method becomes available.
Federated identities should be constrained to the intended external subjects and workloads. Workload Identity Federation reduces key management, but a broad trust mapping can still grant an external identity more impersonation power than intended. The federation configuration is part of the authorization path and deserves change control.
For external federation, restrict attribute mappings and conditions to the smallest identity population that needs access. A federation pool that trusts an entire external tenant when only one repository or workload needs access creates avoidable privilege surface even though no static key exists.
Impersonation creates a second authorization decision
To impersonate a service account, the caller needs permissions on the service account resource, such as the ability to create tokens. The resulting service-account identity then uses its own roles on target resources. This two-step model explains why service-account permissions deserve separate review from the permissions granted to the account itself.
A user with little direct access can still become powerful if allowed to impersonate a highly privileged service account. The general logic behind role-based access control helps expose that risk: role assignment is not only about the target resource but also about who can assume identities that already hold broader access.
Impersonation chains should be kept short. Each additional hop introduces another policy surface and another opportunity for privilege escalation. If A can impersonate B and B can impersonate C, reviewers must understand why the chain exists and whether a direct, narrower grant would be simpler.
Project-level service-account grants can overreach
Granting a role such as Service Account Token Creator at the project or folder level can permit impersonation of many service accounts rather than one intended identity. That may create lateral movement from a lower-trust user into workloads with access outside the project.
Prefer grants on the specific service account when the requirement is specific. High-level grants can be appropriate for platform automation, but they should be justified by a clear administrative function and monitored because their blast radius includes current and future service accounts in scope.
Review both who can use a service account and what the service account itself can do. Those are separate policy questions. An account with narrow permissions can be safely impersonated by more automation identities than an account that administers production databases or organization-level resources.
Default identities deserve explicit review
Some Google Cloud services create default service accounts. Historical environments may also contain broad legacy grants that were convenient when a service was first enabled. Modern organization policies can prevent automatic Editor grants for default service accounts, and new organizations created from May 2024 have that constraint enforced by default.
Do not assume default means required. Inventory which default service accounts are actually in use, identify their permissions, and remove broad roles that no workload needs. A forgotten default identity is still a valid principal that can become a privilege-escalation target.
Default service accounts should be removed from workload configuration when dedicated identities are available. Even if broad legacy roles have been stripped, reusing a default identity across unrelated services makes future permission changes harder because one grant may serve several hidden consumers.
Default service agents created for Google-managed services should not be confused with customer workload service accounts. Removing or changing service-agent permissions without understanding their purpose can break the managed service, while leaving workload defaults overprivileged can create unnecessary risk. Inventory should distinguish the identity types.
Auditability improves when impersonation is attributable
Service account impersonation using user credentials can preserve information about the principal that acted as the service account in audit logs, whereas use of a standalone service account key can make attribution more difficult. This is an operational reason—not only a security reason—to prefer short-lived, brokered credentials.
Logging should answer: who requested the credential, which service account was used, which target resource was accessed, and whether the action matched the expected workload. An identity design is easier to trust when investigators can reconstruct that path after an incident.
Audit design should also capture credential creation and IAM-policy changes around service accounts. A principal who cannot directly impersonate an account may still be able to grant themselves the required role if they can modify the account’s policy or a higher-level inherited policy.
Design for revocation and rotation before the incident
Ask how access is removed when a developer leaves, a workload is retired, a project is moved, or a service account is compromised. Group-based grants, short-lived credentials, dedicated workload identities, and narrowly scoped permissions make revocation smaller and faster.
Test revocation on a representative nonproduction path. If removing a service account role breaks five unrelated applications, the architecture has revealed hidden coupling. If nobody knows which system uses a key, the credential has already outlived its governance.
Revocation tests should include cached or long-lived application behavior. Short-lived access tokens eventually expire, but an application may retry with another credential source or fall back to a key. Knowing the credential acquisition path makes emergency containment more predictable.
The safest IAM design can explain every identity transition
A good review traces principal → impersonated identity → target resource → permission. It also checks inherited policy, groups, service-account attachment, token-creation rights, and alternative data-access paths. That model catches privilege escalation that a list of direct roles will miss.
Architects pursuing the Professional Cloud Architect certification need this system view because Google Cloud solutions often span projects and managed services. Least privilege is not achieved by choosing small role names; it is achieved when every transition in the authorization path is intentional and observable.
A periodic identity review can combine unused-role recommendations, service-account activity, key inventory, impersonation grants, and cross-project lateral-movement insights. The objective is to remove stale capability before it becomes part of an attack path, not merely to document that the identities exist.
The review should include service accounts that have not been used recently and those with permissions outside their home project. Dormant identities with cross-project roles are especially important because they can preserve old lateral paths after the workload that justified them has changed.
