GCP ACE Practice / Study guide / Topics / IAM Roles & Permissions
IAM Roles & Permissions
What actually gets tested on the Google Cloud Associate Cloud Engineer exam,
the traps to know, and 6 free sample questions with full explanations.
IAM shows up more than any other subject on the ACE exam, once you count how often it resurfaces inside questions that are nominally about something else. Start with the three role types: basic roles (Owner, Editor, Viewer — broad, legacy, almost never the right answer once security is in scope), predefined roles (service-scoped, Google-maintained, usually the correct choice), and custom roles (built from individual permissions when no predefined role fits, at the cost of maintaining them yourself as APIs evolve).
The mechanic the exam leans on hardest is that IAM policy is additive and inherits downward: a project's effective policy is the union of everything set directly on it plus everything set on its folders and organization above it, and there is no way to revoke an inherited grant at a lower level — only deny policies (a separate, newer mechanism) can restrict what an inherited grant allows. Grant a role on a folder and every project under it inherits it automatically; that's usually presented as a feature in the question, not a trap, but it means broad grants placed high in the hierarchy are hard to walk back later.
Principals are the "who": user accounts, service accounts, Google groups, and Workspace/Cloud Identity domains, plus special identifiers like allAuthenticatedUsers. Granting a role to a group rather than individually to each member is the answer whenever a question is about managing access at scale — membership changes then handle themselves with a full audit trail, instead of someone having to remember to revoke access when a person changes teams.
Exam tips for this topic
- Basic roles (Owner/Editor/Viewer) are almost always the wrong answer once a question mentions least privilege or security — predefined is the usual correct choice.
- IAM is additive and inherits downward; you cannot remove a grant made at a higher level from underneath it, only add a deny policy on top.
- Grant roles to a Google group instead of individual users whenever a question is really about managing access at scale, not about a single one-off grant.
Sample questions — IAM Roles & Permissions
These 6 questions are drawn from our full bank of 658 to show the style and
depth you'll get in the app. Each comes with the full explanation you'd see after answering
in a real practice session.
IAM
A developer on your team hits a permission error attaching a service account to their new VM. Which role must a user hold ON the service account to attach it (i.e., 'act as' it)?
- roles/iam.serviceAccountUser on that service accountCorrect
- roles/viewer on the project
- roles/billing.user
- No permission is needed
Why: serviceAccountUser gates who can deploy workloads AS the SA — a critical privilege-escalation control: whoever can act as an SA effectively has its powers. Deployment always checks it.
IAM basics
Which best describes how IAM policy inheritance works?
- Policies are inherited downward, and the effective policy is the union of the resource's policy and its ancestors' policiesCorrect
- A policy set on a project overrides and removes any permissions that were granted at the organization level above it
- Policies apply only at the level where they are defined and are never inherited by child resources
- Child policies must be explicitly synchronized with their parent policies before they take effect
Why: IAM is additive: a resource's effective policy is the union of policies set on it and everything above it, so you cannot remove an inherited grant at a lower level (deny policies are a separate, newer mechanism). Grants at higher levels therefore deserve extra care.
IAM
Your org must give an external auditor org-wide read-only visibility into resource configurations and IAM policies — no data access, no changes. Which role fits?
- roles/iam.securityReviewer (plus Viewer-type roles as needed) at the organization levelCorrect
- Organization Administrator, since auditors need full visibility
- Owner on each project, granted temporarily for the audit period
- Editor at the org
Why: Security Reviewer grants list/get on IAM policies and security configs — audit visibility without modification or data reads. Admin/Owner/Editor all allow changes.
IAM basics
What are the three basic (primitive) roles that predate predefined roles?
- Owner, Editor, ViewerCorrect
- Admin, Writer, Reader
- Root, User, Guest
- Manager, Contributor, Auditor
Why: Owner, Editor, and Viewer are the legacy basic roles that apply broadly across all services in a project. Google recommends predefined (or custom) roles instead because basic roles are far too coarse for least-privilege access.
IAM
You need to check from the CLI which roles a specific user holds on your project before an access review. Which gcloud command shows this?
- gcloud projects get-iam-policy PROJECT --flatten=bindings --filter=bindings.members:user:ana@example.com --format='table(bindings.role)'Correct
- gcloud iam whois ana@example.com --project=PROJECT --show-roles
- gcloud iam users describe ana@example.com --format='table(roles)'
- gcloud iam roles list --member=user:ana@example.com
Why: You inspect the policy and filter bindings by member (the console's IAM page does this visually; Policy Analyzer answers 'who can access what' at scale). The other commands don't exist.
IAM basics
Which statement about the basic Editor role is a reason Google discourages its use in production?
- It grants broad modify permissions across nearly all services, violating least privilegeCorrect
- It cannot be granted to Google groups, so every developer needs an individual grant
- It only works while the project remains inside the free tier usage limits
- It expires after 90 days and must be re-granted, causing operational overhead
Why: Editor lets a principal modify almost every resource type in a project — far more than most jobs need — so a compromise of that account is catastrophic. Predefined roles scope permissions to a service and function. The other statements are simply false.
Practice this for real
The app has dozens more questions on this and every other topic, with instant scoring,
spaced repetition of what you get wrong, and progress tracking across sessions.
Start practicing →
This topic shows up in
Other topics