Google Cloud ACE IAM Policies and Roles Guide

Study Google Cloud ACE IAM Policies and Roles: key concepts, common traps, and exam decision cues.

This lesson is about understanding what Google Cloud access actually means. ACE expects you to know when a predefined role is enough, when a custom role is justified, and how policies expose who has what access.

Predefined role: Google-maintained role with a known set of permissions for a broad job function.

Custom role: User-defined role that contains a tailored permission set when predefined roles are too broad or too narrow.

What Google Cloud is really testing here

ACE wants you to separate:

  • scope from permission set
  • policy inspection from role design
  • broad convenience from least privilege
  • resource-level need from project-wide overgranting

Many stems are not really asking “what is IAM?” They are asking whether you can spot that the access problem is too much scope, the wrong role type, or missing policy visibility.

Fast role chooser

If the question is mainly about… Strongest first lane
broad job access that already matches a common Google Cloud duty predefined role
an old all-powerful role that is too broad for a sensitive task narrower predefined role or custom role
a permission bundle that does not fit any built-in role cleanly custom role
“just make it work” admin-style access in a stem that cares about least privilege avoid basic roles unless the stem clearly forces them

Basic roles exist, but ACE usually treats them as a warning sign because they are so broad. If a question mentions a sensitive action and asks for minimum necessary access, the stronger answer is usually a narrower predefined role or a custom role.

Read the scope before you read the role

Scope question Why it matters
organization or folder? inheritance can grant far more than the local team intended
project? many operator tasks live here, and overgranting here is common
individual resource? this is often the safer answer when the task is narrow
existing policy already grants access? always inspect before creating more bindings

ACE repeatedly rewards candidates who check the scope of the binding before changing the kind of role. A good role bound too high is still too much access.

When a custom role is justified

Use a custom role when:

  • the predefined roles are close but still expose extra permissions
  • the task is stable enough that a tailored permission set will not become a maintenance burden
  • the stem explicitly emphasizes least privilege for a narrow operational action

Do not reach for a custom role first when a clean predefined role already fits. ACE is not testing whether you can over-engineer IAM.

Common traps

Trap Better reading
“A predefined role is broad, so custom role is always better.” Custom roles are justified only when the built-in roles do not fit the least-privilege target cleanly.
“The role looks right, so the access must be correct.” The same role can still be too broad if it is granted at the wrong scope.
“Basic roles are fine for speed.” On ACE, basic roles usually signal avoidable overgranting.
“If access fails, create a new role immediately.” First inspect the current IAM policy and the resource hierarchy.

Harder scenario question

A team member needs to restart one production service in a single project. The existing predefined roles are either too broad or also grant access to unrelated resources. Which lane is strongest first?

  • A. Grant Owner at the folder level
  • B. Grant a basic project-wide role because it is faster
  • C. Create or use a narrower role at the smallest reasonable scope
  • D. Move the service into another region

Correct answer: C. ACE prefers least-privilege access at the narrowest workable scope. The point of the question is not just the role type. It is the combination of permission fit and binding scope.

Decision order that usually wins

  1. First classify the access problem as role fit, scope fit, or policy inspection.
  2. If predefined roles are close but too broad, think custom role.
  3. If a role seems fine but access is still too broad, inspect the scope next.
  4. If you need to know who already has access, inspect IAM policies directly.
  5. ACE usually rewards least-privilege reasoning that reads both the role and the scope together.

Quiz

Loading quiz…
Revised on Sunday, May 10, 2026