14.2 IAM Role Types: Basic, Predefined & Custom Roles

Why Role Types Matter on the ACE Exam

The official exam guide explicitly lists "Managing role types and defining custom IAM roles" as a testable skill under Domain 5. The core tension the exam probes is simple to state and easy to get wrong under time pressure: broader roles are faster to grant but violate least privilege, while narrower roles take more setup but shrink the damage if a credential is ever leaked or misused. Expect the exam to describe a business requirement — "this contractor needs to restart Compute Engine instances but must never delete them or touch billing" — and ask you to pick the correctly scoped role type, not just a role name.

The Three Role Types at a Glance

Basic Roles

Basic roles — still frequently called by their legacy name, primitive roles, in older documentation and in exam-style distractors — are the oldest and broadest access grants in Google Cloud:

• Owner (roles/owner) — full control of every resource in the project, including managing IAM allow policies and billing configuration. Owner is the only basic role that can add or remove other Owners.
• Editor (roles/editor) — can create, modify, and delete most resources project-wide, but cannot manage IAM policies or billing.
• Viewer (roles/viewer) — read-only access to inspect resources and configuration; cannot change anything.
• Browser (roles/browser) — the most limited basic role: lets a principal see which projects and folders exist in the resource hierarchy without exposing the resources inside them.

Because a basic role applies broadly across every Google Cloud service in the project at once, Google explicitly recommends avoiding basic roles in production and reserving them for early experimentation or single-owner sandbox projects. On the ACE exam, whenever a scenario mentions least privilege, an internal security review, or a compliance requirement, a basic role is almost always the wrong answer choice.

Predefined Roles

Predefined roles are Google-curated, service-scoped bundles that Google itself updates as new permissions and features ship — you never maintain them yourself. They follow a consistent naming convention, roles/SERVICE.IDENTIFIER, for example:

• roles/compute.admin — full management of Compute Engine resources
• roles/compute.viewer — read-only Compute Engine access
• roles/storage.objectViewer — read-only access to Cloud Storage objects, but not bucket-level configuration
• roles/iam.securityAdmin — manage IAM allow policies without needing rights to the resources they protect
• roles/resourcemanager.projectIamAdmin — administer IAM policy at the project level
• roles/iam.serviceAccountUser — impersonate, or "act as," a service account (see Chapter 15 for the security implications of this specific role)

Because Google maintains hundreds of predefined roles spanning every Google Cloud product, most real-world least-privilege designs can be assembled entirely from predefined roles without ever writing a custom one — this is Google's recommended starting point before reaching for a custom role.

Custom Roles

When no predefined role fits — say, a support engineer who should restart Compute Engine instances and read logs, but must never delete a disk or touch IAM — you build a custom role: a hand-picked bag of individual permissions, created at either the organization level or the project level. A custom role can only ever be granted within the scope where it was created; an organization-level custom role cannot be bound inside an unrelated organization, and a project-level custom role cannot be granted outside that one project.

Facts worth memorizing for the exam:

• Not every permission is eligible for a custom role — only permissions Google marks "supported for custom roles" can be added; some sensitive permissions remain restricted to predefined or basic roles only.
• You can build a custom role from scratch, or copy an existing role as a base role (gcloud iam roles copy) and then add or remove individual permissions from that starting point, which is far faster than hand-picking every permission.
• Every custom role carries a launch stage: ALPHA, BETA, GA (General Availability), or DISABLED. Setting a role to DISABLED is a soft delete — existing bindings that reference the role remain in place but stop granting any access, which lets you test the blast radius of retiring a role before deleting it outright.
• Quota: an organization can define up to 300 custom roles, and each individual project can separately define up to 300 custom roles — these are two independent quotas, not a shared pool.
• gcloud iam roles list shows every predefined and custom role together with its testable permissions, the standard way to audit exactly what a role grants before you assign it to anyone.

Choosing the Right Role Type: A Decision Framework

1. Is this a throwaway sandbox with no real security requirement, where the built-in Owner/Editor/Viewer/Browser access is acceptable? → A basic role, though this is rarely the correct exam answer once least privilege is mentioned.
2. Does a Google-curated predefined role already match the job function — "read Compute Engine configuration," "manage Cloud Storage objects," "administer BigQuery datasets"? → Use the predefined role; this is the default correct answer on most ACE least-privilege scenarios.
3. Does no single predefined role match — because the requirement spans an unusual permission mix, or must exclude one permission a predefined role would otherwise include? → Build a custom role, ideally starting from the closest predefined role as a base to save effort.

Exam Scenario

A hospital's Google Cloud project has a "biller" job function that must be able to view Compute Engine instance details and create Cloud Monitoring alerting policies, but must never start, stop, or delete any instance. No single predefined role matches this exact combination, and none of the basic roles come close to least privilege. The correct approach is a custom role built at the project level, combining read-only Compute Engine permissions (such as compute.instances.get, compute.instances.list, compute.zones.list) with the Cloud Monitoring alerting-policy permissions — created either from scratch or by copying roles/monitoring.alertPolicyEditor as a base role and then adding the narrow Compute Engine read permissions on top.

Key Takeaways Recap

• Basic roles (Owner/Editor/Viewer/Browser) are broad and project-wide; avoid them once least privilege matters.
• Predefined roles (roles/SERVICE.IDENTIFIER) are Google-maintained and should be your default choice.
• Custom roles are scoped to the org or project that created them, support ALPHA/BETA/GA/DISABLED launch stages, and are capped at 300 per organization and 300 per project.