This chapter covers GCP IAM roles, specifically the three types: primitive, predefined, and custom. Understanding the differences, use cases, and limitations of each role type is critical for the ACE exam, as IAM questions appear in roughly 15–20% of the exam. You will be expected to know when to use each role, how to create custom roles, and the principle of least privilege. This chapter provides the depth needed to answer any IAM role question confidently.
Jump to a section
Imagine a large hotel with different types of key cards. Basic key cards (like primitive roles) are either 'guest' (can enter any guest room), 'staff' (can enter all staff areas), or 'admin' (can enter every room including the manager's office). These are too broad — a guest doesn't need access to the boiler room, and staff shouldn't enter guest rooms. To fix this, the hotel introduces specialized key cards (predefined roles): a 'housekeeping' card that opens only guest rooms and supply closets, a 'maintenance' card that opens boiler rooms and electrical panels, and a 'front desk' card that opens the lobby and office. Each card is designed for a specific job. However, the hotel manager wants even finer control, so they create custom key cards (custom roles) by selecting exactly which doors a specific employee needs — e.g., a 'night auditor' card that opens the front desk, accounting office, and security room, but nothing else. The hotel's key system works by having a central lock database (IAM policy) that lists which key serial numbers can open which doors. When a key is swiped, the system checks the database against the door's access list. If the key's serial number is present, the door unlocks. Primitive roles are like master keys that bypass the per-door list, while predefined and custom roles are listed explicitly. In GCP, primitive roles (owner, editor, viewer) grant broad permissions across all services, predefined roles are scoped to specific services (e.g., roles/storage.objectViewer), and custom roles let you combine individual permissions into a tailored set.
What are IAM Roles and Why Do They Exist?
In Google Cloud Platform (GCP), Identity and Access Management (IAM) controls who (identity) has what access (role) to which resource. A role is a collection of permissions. Permissions determine what operations are allowed on a resource. For example, the permission storage.objects.get allows reading an object from Cloud Storage. IAM roles group these permissions into logical sets. Instead of assigning individual permissions to each user (which would be unmanageable at scale), you assign a role to a principal (user, group, service account, or Google Workspace domain) at a specific resource hierarchy level (organization, folder, project, or resource).
The ACE exam tests your ability to choose the correct role type for a scenario. There are three categories of roles: - Primitive roles (Owner, Editor, Viewer) – historical, broad, exist at the project level. - Predefined roles – fine-grained, curated by Google for specific services. - Custom roles – user-defined, combining specific permissions.
Primitive Roles: The Broad-Brush Approach
Primitive roles are the oldest IAM roles in GCP. They are project-level roles that grant coarse-grained access. There are three primitive roles:
- roles/viewer: Read-only access to all resources in a project. Permissions include get, list, and read on most services.
- roles/editor: Viewer permissions plus the ability to modify state (create, update, delete) resources. Does NOT include managing IAM policies or billing.
- roles/owner: Editor permissions plus the ability to manage IAM policies, set up billing, and delete projects. Only one project owner is needed, but you can have multiple.
Key exam points:
Primitive roles cannot be scoped below the project level. You cannot assign roles/editor to a single Cloud Storage bucket.
They are not recommended for production due to their breadth. Google recommends using predefined or custom roles.
Primitive roles include permissions that may change as Google adds new services. For example, roles/editor automatically gets permissions for new services.
The exam will test that roles/owner includes iam.serviceAccounts.actAs permission, which allows impersonating all service accounts in the project.
Predefined Roles: Service-Specific and Curated
Predefined roles are created and maintained by Google. They are designed for specific services and common job functions. For example: - roles/storage.objectViewer: Read access to objects in Cloud Storage buckets. - roles/compute.instanceAdmin.v1: Full control of Compute Engine instances. - roles/bigquery.dataViewer: Read access to BigQuery datasets and tables.
Each predefined role is a collection of permissions that are carefully scoped. Google updates these roles as services evolve, but the role name remains stable. You can view the permissions in a predefined role using:
gcloud iam roles describe roles/storage.objectViewerPredefined roles can be assigned at any level of the resource hierarchy: organization, folder, project, or resource. For example, you can assign roles/storage.objectViewer to a specific bucket, not just the project.
Exam focus:
You must know the naming convention: roles/<service>.<roleName>.
Common predefined roles include roles/owner, roles/editor, roles/viewer (these are also primitive, but they are also predefined roles with the same name? Actually, primitive roles are a subset of predefined roles in terms of naming, but they are conceptually distinct. Google documentation treats primitive roles as a separate category. The exam expects you to differentiate them by scope and granularity.
Predefined roles follow the principle of least privilege better than primitive roles.
The exam may ask which role to assign for a specific task, e.g., "Which role allows a user to start and stop Compute Engine instances but not delete them?" The answer would be roles/compute.instanceAdmin.v1 (which includes compute.instances.start, compute.instances.stop, but not compute.instances.delete).
Custom Roles: Tailor-Made Permissions
When predefined roles don't meet your needs, you can create custom roles. A custom role is a user-defined set of permissions. You can create custom roles at the organization level or project level. Once created, you can assign them like any other role.
Creating a custom role:
1. Use the gcloud iam roles create command or the Cloud Console.
2. Specify the role ID (e.g., myCustomRole), title, description, and a list of permissions.
3. Permissions must be in the format <service>.<resource>.<verb> (e.g., compute.instances.start).
4. You can include permissions from multiple services.
Example command:
gcloud iam roles create myCustomRole --project=my-project \
--title="My Custom Role" --description="Custom role for instance management" \
--permissions=compute.instances.start,compute.instances.stop,compute.instances.listCustom roles have limitations:
You cannot include permissions that are not supported for custom roles. Google maintains a list of permissions that can be used in custom roles (most are supported, but some, like resourcemanager.projects.get, are allowed).
Custom roles cannot include permissions that are restricted, such as those related to IAM policy management (e.g., resourcemanager.projects.setIamPolicy) unless you are creating a role at the organization level with special privileges.
The maximum number of custom roles per organization or project is 300 (by default).
Custom roles are not automatically updated when Google adds new permissions. You must manually update them.
Exam focus:
Know how to create, update, delete, and list custom roles using gcloud commands.
Understand that custom roles are used when predefined roles are too permissive or not specific enough.
The exam may test the difference between organization-level and project-level custom roles. Organization-level roles can be assigned to any project under the organization, while project-level roles are scoped to that project.
How IAM Roles Work Internally
When a principal makes an API call, GCP evaluates the IAM policy. The policy is a set of bindings that map a principal to a role. The role is a set of permissions. The evaluation checks if the principal has the required permission for the resource. The process involves: 1. Determine the resource hierarchy: The resource's ancestors (project, folder, organization) are considered. Policies are inherited. 2. Collect all policies: IAM policies at the resource, project, folder, and organization level are combined. 3. Evaluate permissions: For each permission needed, GCP checks if any bound role includes that permission. If yes, access is granted (unless denied by Organization Policies).
Roles are never assigned directly to users; they are assigned via policy bindings. The IAM system uses a deny-by-default model: no permissions are granted unless explicitly assigned.
Key Numbers and Defaults
Primitive roles: roles/viewer, roles/editor, roles/owner.
Primitive roles are project-level only; they cannot be assigned to a folder or organization.
Predefined roles exist for most services; they are versioned (e.g., roles/compute.instanceAdmin.v1).
Custom roles: up to 300 per organization or project.
Custom roles can include up to 1500 permissions (limit may change).
Permissions are strings like storage.buckets.get.
Configuration and Verification Commands
List all roles in a project:
gcloud iam roles list --project=my-projectDescribe a predefined role:
gcloud iam roles describe roles/storage.objectViewerCreate a custom role:
gcloud iam roles create myRole --project=my-project --title="My Role" --permissions=storage.objects.get,storage.objects.listUpdate a custom role:
gcloud iam roles update myRole --project=my-project --add-permissions=storage.objects.deleteDelete a custom role:
gcloud iam roles delete myRole --project=my-projectUndelete a custom role (within 30 days):
gcloud iam roles undelete myRole --project=my-projectInteraction with Related Technologies
IAM Conditions: You can add conditions to role bindings to grant access temporarily or based on attributes (e.g., IP address, resource name). This works with predefined and custom roles, but not primitive roles.
Organization Policies: These are separate from IAM and can restrict permissions even if IAM allows them.
Service Accounts: Service accounts are principals that can be assigned roles. Custom roles are often used to give service accounts only the permissions they need.
Audit Logs: IAM changes are logged in Cloud Audit Logs. You can review who assigned which role.
Exam-Specific Details
The ACE exam expects you to:
Differentiate between primitive, predefined, and custom roles.
Know that primitive roles are not recommended for production.
Understand that predefined roles are the default choice unless specific requirements demand custom roles.
Be able to create a custom role using gcloud and the console.
Recognize that custom roles must be manually updated when new permissions are needed.
Know that IAM roles are inherited down the resource hierarchy.
Common Pitfalls
Assuming primitive roles are fine-grained: They are not. They grant broad access.
Creating custom roles when predefined roles suffice: This adds maintenance overhead.
Forgetting to update custom roles when new permissions are needed: This can break functionality.
Assigning roles at the project level when resource-level is sufficient: Violates least privilege.
Summary
IAM roles are the cornerstone of access control in GCP. Primitive roles are legacy and broad. Predefined roles are service-specific and maintained by Google. Custom roles give you maximum flexibility but require manual management. The ACE exam will test your understanding of when to use each type and how to implement them.
Identify Required Permissions
Start by determining exactly what actions the principal needs to perform. List the specific API methods (e.g., `compute.instances.start`, `storage.objects.get`). This is the foundation of least privilege. For the exam, you might be given a scenario like 'a user needs to read objects from a bucket and list buckets.' The required permissions are `storage.objects.get` and `storage.buckets.list`. Avoid guessing; use the documentation or `gcloud iam roles describe` to see what permissions a predefined role includes.
Check Existing Predefined Roles
Before creating a custom role, search for predefined roles that contain the required permissions. Use `gcloud iam roles list` with a filter, or browse the console. For example, if you need `compute.instances.start` and `compute.instances.stop`, `roles/compute.instanceAdmin.v1` includes those. If a predefined role exists and is not overly permissive, use it. The exam will often test if you know the correct predefined role for a task. If no predefined role matches exactly, move to custom roles.
Create a Custom Role (If Needed)
If predefined roles are too broad or too narrow, create a custom role. Use `gcloud iam roles create` with the `--permissions` flag listing exactly the permissions needed. Choose a descriptive role ID and title. For example, `gcloud iam roles create bucketReader --project=my-project --title='Bucket Reader' --permissions=storage.objects.get,storage.objects.list`. The role is created at the project level by default. To create at the organization level, use `--organization=ORG_ID`. Remember that custom roles have a 300-per-project limit.
Assign the Role to the Principal
Use `gcloud projects add-iam-policy-binding` to assign the role to a user, group, or service account. Specify the project, member, and role. For example: `gcloud projects add-iam-policy-binding my-project --member='user:alice@example.com' --role='roles/storage.objectViewer'`. For custom roles, use the full role name: `projects/my-project/roles/myCustomRole`. You can also assign roles at the folder or organization level with `gcloud resource-manager folders add-iam-policy-binding` or `gcloud organizations add-iam-policy-binding`.
Verify Access and Test
After assignment, verify that the principal has the expected permissions. You can use `gcloud projects get-iam-policy` to view the policy. For a user, ask them to perform the allowed actions. For programmatic testing, use service account impersonation with `gcloud auth activate-service-account` and then try the API. Also check audit logs to confirm the policy change. The exam may ask about verifying IAM bindings; know that `get-iam-policy` returns the current policy.
Enterprise Scenario 1: Least Privilege for a Data Analyst
A large e-commerce company uses BigQuery for analytics. The data analyst team needs to query datasets but not modify them. Using primitive roles like roles/editor would give them delete access to all resources. Instead, the cloud admin assigns roles/bigquery.dataViewer at the dataset level. This gives read-only access to tables and allows running queries. The admin also creates a custom role for a contractor who needs to export query results to Cloud Storage. The custom role includes bigquery.jobs.create and storage.objects.create for a specific bucket. This prevents the contractor from viewing other data or accidentally deleting objects. The admin uses gcloud commands to script role creation and assignment, ensuring consistency across multiple projects.
Enterprise Scenario 2: Custom Role for a CI/CD Pipeline
A SaaS company uses Cloud Build and Compute Engine. Their CI/CD pipeline uses a service account that needs to create, start, and stop instances, but never delete them. No predefined role offers exactly this set. The admin creates a custom role roles/ciCdInstanceOperator with permissions: compute.instances.create, compute.instances.start, compute.instances.stop, compute.instances.list, and compute.disks.create (to attach persistent disks). The role is assigned to the service account at the project level. This ensures the pipeline can deploy but cannot destroy resources. The admin also sets up IAM conditions to restrict the role to only instances with a specific label (environment=staging), adding an extra layer of security. The custom role is version-controlled in a Git repository and updated via Terraform.
Scenario 3: Migrating from Primitive to Predefined Roles
A legacy application was originally given roles/editor to all developers. An audit reveals excessive permissions. The cloud team gradually replaces primitive roles with predefined roles. For example, developers who only need to view logs get roles/logging.viewer. Developers who deploy code get roles/cloudbuild.builds.editor. The migration is done by first creating a custom role that matches the current permissions, then assigning it, and finally removing the primitive binding. This reduces risk of accidental deletions. The team uses gcloud commands to script the changes and relies on IAM Recommender to identify unused permissions. Performance is not impacted because IAM evaluation is nearly instantaneous. Misconfiguration (e.g., missing a permission) causes errors that are logged and quickly fixed by updating the custom role.
Common Pitfalls in Production
Overly permissive custom roles: Including too many permissions defeats the purpose. Always start with minimal set and expand as needed.
Not using conditions: IAM Conditions can restrict access based on time, IP, or resource attributes. This is often overlooked.
Hardcoding role IDs: Role IDs must be unique within a project. If you delete and recreate a role, the old ID cannot be reused immediately (30-day soft delete). Plan accordingly.
Forgetting to update custom roles: When a new feature requires additional permissions, the custom role must be updated. Use automation to detect stale roles.
What the ACE Exam Tests (Objective 5.1)
The ACE exam objective 5.1 is about "Configuring IAM roles." Specifically, you must:
Distinguish between primitive, predefined, and custom roles.
Understand the scope of each role type (project vs. resource level).
Know how to create, update, and delete custom roles.
Apply the principle of least privilege when selecting roles.
Recognize that primitive roles are not recommended for production.
Common Wrong Answers and Traps
Choosing primitive roles for fine-grained access: Candidates often pick roles/editor because it's familiar. The correct answer is usually a predefined role like roles/storage.objectAdmin. The trap is that primitive roles seem easier but are too broad.
Assuming custom roles automatically update: A question might say "A user needs a new permission that was recently added to a service." The wrong answer is that the custom role automatically includes it. The reality is custom roles must be manually updated.
Confusing project-level and organization-level roles: A custom role created at the project level cannot be used in another project. The exam may ask where to assign a role that should apply to all projects in an organization. The answer is organization-level or folder-level.
Misunderstanding role inheritance: A common trap is thinking that a role assigned at the project level does not apply to resources within the project. It does, by inheritance. But a role assigned at the resource level only applies to that resource.
Specific Numbers and Terms That Appear on the Exam
The three primitive roles: roles/viewer, roles/editor, roles/owner.
Maximum custom roles per project: 300.
Custom role soft-delete period: 30 days.
Command to create a custom role: gcloud iam roles create.
Command to list permissions in a role: gcloud iam roles describe.
The concept of "least privilege" is explicitly tested.
Edge Cases and Exceptions
Primitive roles at the folder or organization level? They cannot be assigned there. Only predefined and custom roles can be assigned at folder or organization level.
Custom roles with IAM policy permissions: You cannot create a custom role that includes resourcemanager.projects.setIamPolicy unless you are at the organization level and have special privileges. Most exam scenarios avoid this.
Deleted custom roles: If you delete a custom role, all bindings using that role become ineffective. You can undelete within 30 days.
Predefined role versions: Some predefined roles have versions (e.g., v1, v2). The exam may test that newer versions include additional permissions.
How to Eliminate Wrong Answers
When faced with a question about which role to assign, follow this process:
1. Determine the required actions (permissions).
2. If the actions are broad (e.g., full control of a project), the answer might be primitive roles/owner or roles/editor, but only if the scenario explicitly says coarse-grained.
3. If the actions are service-specific, look for a predefined role that matches.
4. If the actions are very specific (e.g., only start and stop instances, no delete), a custom role is needed.
5. Eliminate any answer that assigns a role at the wrong scope (e.g., resource-level role at project level is fine, but project-level role on a resource is not a valid concept).
6. Eliminate any answer that says "automatically updated" for custom roles.
Remember: The exam rewards the principle of least privilege. When in doubt, choose the most specific role that grants exactly the required permissions.
Primitive roles (viewer, editor, owner) are broad and project-level only; avoid in production.
Predefined roles are service-specific and follow least privilege; use them by default.
Custom roles allow combining specific permissions but require manual updates and have a 300-per-project limit.
IAM roles are inherited down the resource hierarchy (org → folder → project → resource).
Custom roles can be created with `gcloud iam roles create` and must specify permissions explicitly.
Deleted custom roles can be undeleted within 30 days using `gcloud iam roles undelete`.
The principle of least privilege is critical on the exam: choose the role that grants only needed permissions.
These come up on the exam all the time. Here's how to tell them apart.
Primitive Roles
Only three roles: viewer, editor, owner.
Assigned only at the project level.
Grant broad permissions across all services.
Automatically updated with new service permissions.
Not recommended for production use.
Predefined Roles
Hundreds of roles, one per service or job function.
Can be assigned at organization, folder, project, or resource level.
Grant fine-grained permissions scoped to specific services.
Updated by Google, but you cannot modify them.
Preferred for production; follow least privilege.
Predefined Roles
Created and maintained by Google.
Cannot be modified; only Google can update permissions.
No limit on number you can use (but you cannot create new ones).
Automatically receive new permissions as services evolve.
Easy to use; no manual management needed.
Custom Roles
Created and maintained by you.
Fully customizable: you choose exact permissions.
Limited to 300 per project or organization.
Do not automatically update; you must add new permissions manually.
Requires ongoing maintenance; best when predefined roles are insufficient.
Mistake
Primitive roles can be assigned at the resource level (e.g., a Cloud Storage bucket).
Correct
Primitive roles can only be assigned at the project level. You cannot assign `roles/viewer` to a single bucket. To grant read access to a bucket, you must use `roles/storage.objectViewer`.
Mistake
Custom roles automatically include permissions from new services added by Google.
Correct
Custom roles are static. They include only the permissions you explicitly added. If a new service is launched, you must manually update the custom role to include any new permissions it requires.
Mistake
The roles/editor role allows managing IAM policies.
Correct
`roles/editor` allows modifying most resources but does NOT allow managing IAM policies. Only `roles/owner` and roles with the `resourcemanager.projects.setIamPolicy` permission can change IAM bindings.
Mistake
A custom role created in one project can be used in another project.
Correct
Custom roles are scoped to the project or organization where they were created. A project-level custom role cannot be assigned in a different project. If you need the same role in multiple projects, create it at the organization level or recreate it in each project.
Mistake
Predefined roles are immutable and cannot be changed.
Correct
Predefined roles are maintained by Google and can be updated (e.g., new permissions added). However, you cannot modify them. The role name stays the same, but the underlying permissions may change. Custom roles are the ones you can modify.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Primitive roles (viewer, editor, owner) are coarse-grained and only assignable at the project level. They grant broad permissions across all services. Predefined roles are fine-grained, service-specific, and can be assigned at any hierarchy level. For example, `roles/storage.objectViewer` grants read-only access to Cloud Storage objects, whereas `roles/editor` would allow modifying compute resources, databases, etc. The exam expects you to choose predefined roles over primitive ones for least privilege.
Use the `gcloud iam roles create` command. For example: `gcloud iam roles create myCustomRole --project=my-project --title='My Custom Role' --permissions=compute.instances.start,compute.instances.stop`. You must specify a unique role ID (within the project), a title, and a list of permissions. You can also create it in the Cloud Console under IAM & Admin > Roles > Create Role. Custom roles can be created at the project or organization level.
No. Primitive roles can only be assigned at the project level. If you need to grant broad access at the folder or organization level, you must use a predefined role like `roles/viewer` (which is also a predefined role name, but it's the same as the primitive role? Actually, `roles/viewer` is both a primitive and a predefined role; however, when assigned at the folder level, it behaves as a predefined role and grants viewer permissions across all projects in that folder. The key point is that the primitive role concept is project-only, but the same-named predefined role can be used at higher levels. The exam distinguishes them by context.
When you delete a custom role, all IAM bindings that reference that role become ineffective. The principal loses all permissions that were granted by that role. However, you can undelete the role within 30 days using `gcloud iam roles undelete`, which restores the role and its bindings. After 30 days, the role is permanently deleted and you must recreate it and reassign the bindings.
Use the `gcloud iam roles describe` command. For example: `gcloud iam roles describe roles/storage.objectViewer`. This returns the role's title, description, and list of permissions (e.g., `storage.objects.get`, `storage.objects.list`). You can also view it in the Cloud Console under IAM & Admin > Roles.
No. Predefined roles are managed by Google and cannot be modified. If you need a different set of permissions, you must create a custom role or use a different predefined role. You can, however, use IAM Conditions to further restrict when a predefined role applies.
The default limit is 300 custom roles per project or organization. This limit can be increased by requesting a quota increase from Google Cloud Support. Each custom role can include up to 1500 permissions.
You've just covered GCP IAM Roles: Primitive, Predefined, Custom — now see how well it sticks with free ACE practice questions. Full explanations included, no account needed.
Done with this chapter?