IAM on Google Cloud: Roles, Members, and Policies for the ACE Exam

Identity and Access Management (IAM) on Google Cloud is the single topic that trips up more Associate Cloud Engineer candidates than any other, and it is worth understanding why. IAM questions are rarely about memorizing a service; they are about reasoning through a small set of moving parts — who is asking, what they are allowed to do, and where in your organization that permission was granted. This article walks through the model the way the Google Cloud Associate Cloud Engineer expects you to reason about it, with the analogies and worked examples that make it stick.

The one sentence that holds IAM together

Every IAM decision on Google Cloud answers the same question: who can do what on which resource. Google's own phrasing is that a policy grants a role to a member on a resource. If you can locate those three things in any scenario, you can answer the question. The "who" is a member (Google now says "principal"), the "what" is a role that bundles permissions, and the "which resource" is a node somewhere in the resource hierarchy. The mistake most people make is treating permissions as something you assign directly to a person. You never do — you assign a role, and the role carries the permissions.

Members: the "who"

A member is an identity that can be granted access. On the exam you should recognize the main types on sight: a Google account (an individual human), a Google group (a collection of users and other groups you manage in one place), a service account (a non-human identity that applications and virtual machines use to authenticate), a Google Workspace or Cloud Identity domain (everyone in an organization's domain), and the special allAuthenticatedUsers and allUsers identifiers for public access.

The lesson buried in that list is that you should almost always grant roles to groups rather than to individuals. When someone joins or leaves a team, you change one group membership instead of hunting through dozens of resources. The exam rewards this instinct: if a question describes onboarding a team, the intended answer is usually to add them to a group that already holds the right role.

Roles: the "what," and the three types that matter

A role is a named collection of permissions, and a permission is a single fine-grained action such as compute.instances.start. You do not assign permissions one at a time; you assign a role, and Google Cloud offers three kinds. Knowing the difference is probably the most testable single fact in this domain.

Basic roles are the old, broad ones — Owner, Editor, and Viewer — that apply across almost every service in a project. Viewer is read-only, Editor can modify most resources, and Owner adds the ability to manage roles and billing. They are convenient and dangerous both, because Editor on a project is enormous power granted bluntly. The exam frequently offers a basic role as a tempting distractor when the scenario clearly calls for something narrower.

Predefined roles are the ones you should reach for by default. Google maintains hundreds of them, each scoped to a specific service and job, such as roles/compute.instanceAdmin or roles/storage.objectViewer. They give a member exactly the permissions needed for one kind of task and nothing more. When a question says "a developer needs to manage Compute Engine instances but should not touch networking or billing," the intended answer is a predefined role that matches that job.

Custom roles exist for the cases where no predefined role fits — you assemble your own list of permissions. They carry a maintenance cost, because Google adds new permissions to services over time and your custom role will not pick them up automatically. The rule of thumb: use a predefined role whenever one is close enough, and build a custom role only when you genuinely need a combination that does not exist. Scenario-based drilling is the fastest way to internalize which of the three a situation calls for, and the practice questions for the Associate Cloud Engineer lean heavily on exactly this judgment.

Policies and bindings: how the pieces connect

An IAM policy is the object that ties members to roles on a resource. Inside a policy you will find bindings, and each binding is simply a role plus the list of members who hold it. Read a policy and you are reading a table: this role, these members; that role, those members. When you grant access through the console, the command line, or Terraform, you are really adding a member to a binding in a resource's policy. That the binding — not the individual grant — is the unit of storage explains why granting the same role to a second person just extends an existing binding.

The resource hierarchy and inheritance

This is where the exam separates people who memorized definitions from people who understand the model. Google Cloud resources are arranged in a tree: an organization at the top, then optional folders, then projects, then the individual resources like buckets and virtual machines inside those projects. An IAM policy can be set at any level of that tree, and — this is the key rule — policies are inherited downward. A role granted at the folder level applies to every project inside that folder and every resource inside those projects.

Think of it like permissions on nested directories. Grant someone access at a parent folder and they have it on everything beneath. Two consequences follow that the ACE loves to test. First, the effective access on any resource is the union of every policy from that resource up to the organization, so a broad grant high up quietly reaches everywhere below it. Second, this is precisely why granting Editor at the organization or folder level is so risky: it cascades. When a question asks where to grant a role so a team has consistent access across several projects, the answer is the common folder above them, granted once.

Service accounts and least privilege

Service accounts deserve special attention because they are both a member (an identity your code uses to call Google Cloud APIs) and a resource (something you can grant other members permission to act as). A virtual machine runs with an attached service account, and any code on that machine inherits whatever roles the service account holds. That makes the default service account's broad access a real hazard — the exam rewards attaching a purpose-built service account with only the roles the workload needs.

All of this rolls up into one principle the ACE returns to again and again: least privilege. Grant the narrowest role that still lets the member do their job, prefer predefined roles over basic ones, grant to groups rather than individuals, and set policies at the lowest level of the hierarchy that satisfies the requirement. Almost every "best practice" IAM question is really asking you to apply that idea.

Turning understanding into exam-ready recall

IAM is not hard once the model is in your head, but it is unforgiving under time pressure, because the wrong answers are deliberately plausible. The way to get fast is repetition against realistic scenarios, then reviewing every miss until the reasoning is automatic. That is how our platform is built to help: adaptive practice keeps serving you IAM and security questions from the objectives where you are still shaky, and full timed Associate Cloud Engineer exam simulations put those questions inside the real format and pass threshold. The readiness tracking then tells you when your scores on fresh questions are consistently clearing the bar — the honest signal that you are ready to book. When you are ready to move from understanding IAM to reliably answering questions about it, the Google Cloud Associate Cloud Engineer practice set on ExamStudyApp is built to take you there.