Roles

Exam guide§4.1

A role is a named bundle of permissions defined by IAM - you never assign raw permissions directly. There are exactly three kinds, and the exam loves testing "which one should you use".

• Basic roles - roles/owner, roles/editor, roles/viewer. Project-wide, coarse, pre-date IAM. Massive scope.
• Predefined roles - service-specific, curated by Google (e.g. roles/storage.objectAdmin, roles/compute.instanceAdmin.v1). The right default for least privilege.
• Custom roles - you hand-pick permissions when no predefined role fits. You maintain them.

Permission format: service.resource.verb (e.g. compute.instances.start, storage.objects.get).

A role scopes actions on the resource, not the data inside it. Example: roles/compute.viewer grants read-only get/list on Compute Engine resources - you can see instance config and list VMs, but you cannot read the data stored on their disks. Reading that data needs a separate grant.

Basic roles

The three basic roles are concentric: Owner includes everything Editor can do, and Editor includes everything Viewer can do. A project can have any number of each. Billing Administrator is separate - it manages billing and admins but cannot change resources.

The roles are concentric: Owner’s "And..." expands into Editor’s entire permission set, and Editor’s "And..." expands into Viewer’s - so Owner ⊇ Editor ⊇ Viewer. Billing Administrator (past the divider) stands alone: it manages billing and admins but cannot change resources.

⚠GotchaBasic roles are almost always the wrong answer

Owner/Editor/Viewer apply to every resource in the project and grant far more than most tasks need. Editor can modify nearly everything; Owner also manages IAM and billing links. If an exam question offers a predefined role that fits, that beats a basic role. Reserve basic roles for tiny sandbox/test projects.

⚠GotchaOnly Owner can manage IAM by default

Editor can change resources but CANNOT set IAM policy. To let someone manage access without full ownership, grant roles/resourcemanager.projectIamAdmin (or the more scoped roles/iam.securityAdmin), not Owner.

Predefined roles

Google curates predefined roles per service - each bundles the permissions a real task needs, scoped to one service's resources, so it grants granular access without exposing everything else. Bind the role to a member (here a Google Group) on a project, and the member gets every permission in the bundle:

A Google Group is bound to the predefined InstanceAdmin role on project_a. IAM (left) governs the binding; the role bundles many compute.instances.* permissions - far more than you would grant one by one.

Compute Engine ships many predefined roles; three commonly tested ones:

Three commonly tested Compute Engine predefined roles - the full list is service-specific.

⚠GotchaCompute "Storage Admin" is not Cloud Storage admin

roles/compute.storageAdmin manages Compute Engine disks, images, and snapshots - NOT Cloud Storage buckets (that is roles/storage.admin). Use it to let someone manage project images without granting Editor on the project.

⚠GotchaNetwork Admin cannot change firewall rules

Network Admin deliberately excludes write access to firewall rules and SSL certificates - it gets read-only there. Firewall changes belong to a separate role such as Security Admin.

Custom roles

When no predefined role fits, define a custom role with exactly the permissions you need. This is how orgs enforce least privilege - each identity gets only the minimum to do its job.

A Google Group is bound to a custom "Instance Operator" role on project_a, granting exactly these four permissions - enough to start and stop VMs but not reconfigure or delete them, a slice no predefined role gives.

Create one in the console

IAM & Admin ▸ Roles ▸ Create role. You either start from scratch or select an existing role and create a copy, then add or remove permissions - the demo builds Instance Operator from scratch.

Creating the Instance Operator custom role in the console: from IAM & Admin ▸ Roles, build from scratch (or import an existing role and trim it), name it, hand-pick permissions, and Create.

The picker holds 2,000+ permissions, so filter by prefix (compute.instances.) to narrow to the ~44 that apply. The demo's Instance Operator grants get, list, reset, resume, start, stop, and suspend - enough to operate VMs (including waking a suspended one with resume) but not reconfigure or delete them.

⚠GotchaThe role ID is permanent

The Title and launch stage can change later, but the ID must be unique and cannot be changed after creation. The console launch-stage dropdown offers only Alpha, Beta, General Availability, and Disabled - start at Alpha and promote as you test it.

≡FactsCustom role facts

• Defined at organization or project level only (not folder).
• Built from allowed permissions; a permission must be in a supported stage (permissions can be SUPPORTED, TESTING, or NOT_SUPPORTED for custom roles).
• Have a stage: EAP → ALPHA → BETA → GA → DEPRECATED → DISABLED (set DISABLED to turn a custom role off without deleting it).
• You own maintenance - Google adds new permissions to predefined roles automatically, but NOT to your custom roles.

Recap

CommandsWorking with roles

# Inspect what a role actually grants

gcloud iam roles describe roles/storage.objectViewer

 

# List predefined roles that mention a service

gcloud iam roles list --filter="name:compute"

 

# Create a custom role at project scope

gcloud iam roles create bucketReader --project=PROJECT_ID \

--title="Bucket Reader" \

--permissions=storage.buckets.get,storage.objects.get \

--stage=GA

?DECISIONWhich role kind?

A curated role covers the task→Predefined

Task needs a slice no predefined role gives→Custom

Quick personal test project→Basic (Viewer/Editor)

Anything production or shared→NOT basic

Pick this when: use predefined by default; custom only when no predefined role fits; basic only in sandboxes