95% of Cloud Security Is Decided at the IAM Layer
More than 90% of cloud security incidents trace back to misconfigured Cloud IAM. An overprivileged Service Account key accidentally pushed to a public GitHub repo, a former employee whose account still has production access weeks after offboarding, a silent grant of owner-level permissions that nobody notices until the damage is done — every one of these scenarios begins with an IAM failure. On the Associate Cloud Engineer exam, the IAM domain accounts for roughly 17% of questions, and the problems test real-world security judgment rather than rote memorization. This article covers the full picture: the Cloud IAM model, how to use Service Accounts safely, how Workload Identity and Workload Identity Federation eliminate the need for long-lived keys, and how Cloud Audit Logs give you visibility into everything that happens in your environment.
---
The Cloud IAM Model: Members, Roles, and Policy Bindings
Cloud IAM operates on three core concepts. A member answers the question "who?", a role answers "what can they do?", and a Policy Binding connects a member to a role on a specific resource.
There are five member types in Cloud IAM.
| Member Type | Description | Example | |-------------|-------------|---------| | Google Account | Individual Google identity | user@gmail.com | | Service Account | Identity for applications and VMs | my-app@project-id.iam.gserviceaccount.com | | Google Group | Collection of accounts managed as a unit | dev-team@company.com | | Google Workspace Domain | All accounts under a domain | @company.com | | allAuthenticatedUsers | Any Google-authenticated identity | (use with caution on public resources) |
Binding a role to a Google Group rather than individual users is the recommended pattern at scale. Once the group has the binding, you only need to manage group membership going forward — the IAM policy itself never changes, which significantly reduces audit complexity. A single policy supports up to 1,500 bindings.
Exam trap: allUsers means anyone on the internet with no authentication required, while allAuthenticatedUsers means any identity that has authenticated with a Google account. Use allUsers only on intentionally public Cloud Storage buckets and never on resources that hold sensitive data.
---
Three Role Types and the Principle of Least Privilege
Cloud IAM offers three categories of roles. Understanding when each is appropriate is one of the clearest paths to a higher exam score.
| Role Type | Examples | Scope | Exam Signal | |-----------|----------|-------|-------------| | Basic | roles/owner, roles/editor, roles/viewer | Entire project, very broad | Almost always wrong — violates least privilege | | Predefined | roles/compute.admin, roles/bigquery.dataViewer | Service- and action-scoped | Correct answer in most scenarios | | Custom | User-selected permission combinations | Extremely fine-grained | Use when no predefined role fits |
!3 IAM role types
Basic roles are discouraged for a concrete reason. roles/editor can modify nearly every resource in a project, and roles/owner carries full control including the ability to change IAM policies. Granting either role to someone who only needs to manage a single service violates least privilege. When an exam question includes phrases like "with minimal permissions" or "without granting unnecessary access," look for the narrowest applicable predefined role.
Custom roles exist for situations where no predefined role meets the requirement. One critical constraint: custom roles can only be created at the organization or project level — folder-level custom roles are not supported. IAM Recommender uses 90 days of usage data and machine learning to identify permissions that have never been exercised and recommends removing them. Any exam scenario involving a post-audit organization-wide least-privilege initiative should point you toward IAM Recommender.
---
Policy Inheritance and IAM Conditions
GCP resources are organized in a hierarchy, and Cloud IAM policies propagate downward through that hierarchy.
| Level | Description | Inheritance Direction | |-------|-------------|-----------------------| | Organization | Top-level unit (company or domain) | Flows to all children | | Folder | Department or environment grouping | Flows to child projects | | Project | Primary resource isolation boundary | Flows to child resources | | Resource | Individual Compute Engine instance, Cloud Storage bucket, etc. | Lowest level — only receives |
The critical rule of inheritance is that permissions granted at a higher level cannot be revoked at a lower level. If a member receives roles/editor at the Folder level, every project within that folder inherits editor access and there is no mechanism to block it for a specific child project. This makes the placement of role bindings as important as the role choice itself — grant at the narrowest scope that satisfies the requirement.
IAM Conditions extend Policy Bindings with attribute-based access control. You can attach conditions based on time, resource name, or resource type to make a binding context-aware. A common operational pattern is granting a deployment engineer elevated access only during an approved maintenance window, with the binding automatically expiring when the window closes — no manual cleanup required.
| Condition Type | Example Use | Scenario | |---------------|-------------|----------| | Time-based | Allow access only during business hours (09:00–18:00) | Restricting dev environment access | | Resource name | Apply only to buckets matching a specific naming pattern | Separating dev and prod buckets by environment | | Resource type | Apply only to compute.googleapis.com/Instance | VM-only management role |
---
Service Accounts: Dual Nature and Key Management Risk
A Service Account plays two distinct roles simultaneously in Cloud IAM. As a member, it receives IAM roles and acts as the identity that accesses GCP resources. As a resource, it can itself be the subject of a Policy Binding that controls who is allowed to impersonate it. Every GCP compute surface — Compute Engine VMs, Cloud Run services, Cloud Functions — attaches a Service Account to interact with other GCP services.
Service Account keys (JSON credential files) are among the most dangerous artifacts in a GCP environment.
| Access Method | Security Level | Recommended | Notes | |---------------|----------------|-------------|-------| | Service Account key (JSON) | Low | Not recommended | No expiration; immediate risk if exposed | | Service Account impersonation | High | Recommended | Short-lived tokens; audit trail in Cloud Audit Logs | | Workload Identity (GKE) | Very high | Strongly recommended | No keys; credentials auto-rotate | | Workload Identity Federation (external) | Very high | Strongly recommended | External IdP identity exchanges for short-lived GCP tokens |
Key files carry no built-in expiration. Once issued, a key remains valid indefinitely unless explicitly revoked. Accidental inclusion in GitHub repositories, Docker images, or log files is a recurring class of incident. Google's official guidance is to eliminate Service Account keys in favor of Workload Identity mechanisms wherever possible.
Service Account impersonation works by granting a principal the roles/iam.serviceAccountTokenCreator role, which allows it to request short-lived OAuth tokens that carry the Service Account's permissions. These tokens expire automatically after at most one hour, and every impersonation event is recorded in Cloud Audit Logs, giving you a complete audit trail. In legacy environments where keys cannot be avoided, implement regular rotation, immediate deletion of unused keys, and Cloud KMS-managed storage.
---
Workload Identity and Workload Identity Federation
Distinguishing between these two keyless authentication mechanisms is a consistent focus of the Associate Cloud Engineer exam.
| Attribute | Workload Identity (GKE) | Workload Identity Federation (external) | |-----------|-------------------------|------------------------------------------| | Target | GKE pods exclusively | AWS, Azure, GitHub Actions, on-premises systems | | Mechanism | Kubernetes Service Account → GCP Service Account binding | External IdP token exchanged for short-lived GCP token | | Keys required | None | None | | Typical scenario | GKE workload calling GCP APIs | External CI/CD or multi-cloud pipeline calling GCP APIs |
Workload Identity links a Kubernetes Service Account (KSA) inside a GKE pod to a GCP Service Account (GSA). The pod calls GCP APIs without any key material; credentials are obtained automatically from the metadata server and rotated without operator involvement.
Workload Identity Federation lets GCP trust external identity providers — AWS IAM Roles, Azure Managed Identities, GitHub Actions OIDC tokens, and others. The external system presents its identity token to GCP's Security Token Service (STS), which validates it against a configured provider and returns a short-lived GCP access token. No Service Account key is created or stored at any point in this flow.
Exam decision rule: "external CI/CD pipeline accessing GCP without keys" points to Workload Identity Federation. "GKE pod accessing Cloud Storage without keys" points to Workload Identity, which is a GKE-specific feature. The key differentiator is always the origin of the workload.
---
Tracking Operations with Cloud Audit Logs
Cloud Audit Logs is GCP's system of record for answering three questions: what happened, who did it, and when. Any exam question asking "who changed this configuration" or "when was this resource deleted" has Cloud Audit Logs as the correct answer.
| Log Type | Records | Enabled by Default | Cost | |----------|---------|--------------------|------| | Admin Activity | IAM policy changes, resource create/delete | Always (cannot be disab