Google Cloud ACE: IAM and Service Accounts

Google Cloud IAM becomes much clearer when identities, roles, policies, and service accounts are separated conceptually. A principal is the identity asking to act. A role is a bundle of permissions. An IAM policy binds principals to roles on resources. Service accounts complicate the picture slightly because they can be both principals that receive access and resources that other principals are allowed to use or impersonate.

The current Associate Cloud Engineer gives roughly 17.5% of its exam guide to configuring access and security. It explicitly includes IAM policies and roles, plus creating service accounts, assigning them to resources, managing their IAM, impersonating them, and using short-lived credentials.

The exam value is not memorizing every IAM role. It is understanding how to grant the least privilege needed for a human or workload, how service-account identity flows work, and why long-lived keys are usually a weaker option than attached identities, impersonation, or workload identity approaches.

IAM policy answers who can do what on which resource

Google Cloud access decisions begin with a resource hierarchy and an allow policy. A policy contains role bindings that associate one or more principals with roles. Roles contain permissions. Because policies can be attached at organization, folder, project, and lower resource scopes, inherited access can be broader than a single visible binding suggests.

Associate Cloud Engineer candidates should therefore reason from effective access, not only local configuration. If a user has a role at the project level, adding a narrower resource-level binding does not remove the inherited project permission. Good access design chooses both the smallest useful role and the smallest useful scope.

Basic, predefined, and custom roles solve different problems

Basic roles such as Owner, Editor, and Viewer are broad and generally poor choices for production least-privilege design. Predefined roles are maintained by Google and usually match common job functions more precisely. Custom roles can narrow access further when predefined roles still contain permissions the workload does not need.

Custom roles also create maintenance obligations. Google services evolve, and a custom role may need review when new permissions or features become relevant. The goal is not to use custom roles everywhere. The goal is to grant a role whose permissions match the task without creating unnecessary privilege or an unmanageable role catalog.

A service account represents a workload identity

Service accounts are commonly used by applications, virtual machines, jobs, and managed services rather than human users. When code runs as a service account, its API calls are authorized according to roles granted to that service account. This makes the service account part of the application’s security boundary.

A useful design question is whether the workload needs its own identity or whether it is inheriting a default service account with excessive permissions. Google recommends avoiding broad automatic permissions and granting the fewest permissions needed. One service account per meaningful workload boundary often makes access easier to understand, audit, and revoke.

Service accounts are also resources that need protection

A service account can receive roles on other resources, but it also has its own IAM policy controlling who can use or manage it. Granting someone permission to impersonate a highly privileged service account can effectively give that person the service account’s access. That is why service-account permissions deserve the same scrutiny as direct resource permissions.

The distinction between Service Account User and Service Account Token Creator is especially important conceptually. One permission path can allow a principal to attach or act as a service account in supported scenarios, while token-creation permissions enable forms of impersonation. Candidates should focus on the capability being granted, not merely the role name.

Attaching a service account lets a resource run with that identity

Google Cloud resources such as Compute Engine instances and other managed workloads can have a service account attached. Code running on the resource can then obtain credentials for that identity without storing a long-lived key in application files. The resource’s effective permissions come from the roles granted to the attached service account.

This pattern is safer and easier to operate than distributing service-account keys. It also makes responsibility clear: administrators control which identity is attached, IAM controls what that identity can do, and the platform supplies credentials at runtime. The exam expects candidates to recognize this relationship when deploying workloads.

Impersonation supports short-lived administrative access

Service-account impersonation lets an authorized principal obtain short-lived credentials to act as a service account without possessing its long-lived private key. This is useful for administrators, CI/CD systems, and controlled operational workflows where temporary access is preferable to stored credentials.

Impersonation should still be tightly governed because it can confer all permissions available to the target service account. Logs and role assignments should make it possible to identify who initiated the impersonation and what account was used. The important design principle is to prefer temporary, attributable credentials over persistent secrets when possible.

Service-account keys are an exception, not the default

A downloaded service-account key behaves like a long-lived secret. If copied, exposed in a repository, left on a workstation, or shared between systems, it can be difficult to contain. Current Google guidance recommends avoiding keys where an attached service account, impersonation, or workload identity federation can meet the need.

When keys are unavoidable, they need inventory, ownership, storage protection, rotation or replacement strategy, and prompt revocation when no longer needed. Teams should also monitor for unused keys and unexpected key creation. Key management is not merely a credential task; it is part of the workload’s overall security lifecycle.

Cross-project access needs two sides of authorization

Organizations sometimes centralize service accounts in one project and run workloads in another. In these designs, administrators must consider both permission to attach or impersonate the service account and the permissions that the service account itself has on target resources. Organization policies may also affect whether cross-project attachment is allowed.

This two-sided reasoning prevents a common mistake: granting a workload permission on a resource but forgetting whether the person or service deploying the workload can actually use the intended service account. Google Cloud IAM becomes easier when it is treated as connected identity flows rather than isolated role names.

Audit effective access, not only intended access

Least privilege degrades over time when temporary roles become permanent, projects inherit broad bindings, unused service accounts remain enabled, and old keys survive after workload changes. Regular review should therefore examine effective policies, service-account use, impersonation rights, keys, and whether each identity still has a valid owner and purpose.

The environment setup provides broader project context, but IAM quality ultimately depends on ongoing operations. Secure access is a maintained state, not a one-time configuration task completed when the project is created.

Conditions and organization-level policy can add another layer to access design. A role binding may be restricted by context, and organization policies can constrain how projects or identities are allowed to behave. The Associate Cloud Engineer exam does not require memorizing every constraint, but candidates should recognize that effective authorization may reflect inherited IAM, resource policy, and organization-wide guardrails together.

Default service accounts deserve specific scrutiny because convenience defaults can produce more privilege than a workload needs. Administrators should identify which services created an account, what roles it has, whether automatic role grants were used, and whether a user-managed service account would provide clearer ownership. Removing broad default permissions can materially reduce the blast radius of a compromised workload.

Credential choice should follow where the workload runs. Code on Google Cloud can often use an attached service account. Human administrators can use impersonation. External workloads may be able to use workload identity federation instead of stored keys. This location-aware approach reduces secret distribution and makes identity more attributable. The general rule is to choose the shortest-lived, most platform-managed credential mechanism that satisfies the operational requirement.

Incident response for identity also matters. If a service account is suspected of misuse, responders need to know where it is attached, which roles it holds, whether keys exist, who can impersonate it, and what recent activity appears in audit logs. A well-designed identity model makes containment possible without taking unrelated workloads offline.

For the Associate Cloud Engineer exam, IAM and service accounts should be understood as a chain of trust. Policies bind principals to roles; service accounts provide workload identities; separate permissions control who can use those identities; and short-lived credentials reduce the risks created by persistent keys.

The best design is usually the easiest to explain: each identity has a clear purpose, access is granted at the narrowest practical scope, workloads receive dedicated identities, keys are avoided when safer mechanisms exist, and audit data can show who or what acted under each identity.

Policy troubleshooting should start by separating authentication from authorization. A workload may successfully obtain credentials yet still receive permission-denied errors because its service account lacks the required role or because access is granted at the wrong scope. That distinction helps engineers avoid “fixing” access problems by assigning broad roles when the real issue is a missing permission, incorrect resource, or wrong identity.