Once you understand the principal side of Google Cloud IAM (users, groups, service accounts), the next question is the one that actually matters at runtime: what is this principal allowed to do? That is a question about permissions and roles, and on the Professional Cloud Architect exam it shows up in almost every IAM scenario, usually disguised as a least-privilege design problem.
I want to walk through the full hierarchy here: individual permissions, the three categories of roles that bundle them, and how to decide when a custom role is the right answer instead of a predefined one.
A permission in Google Cloud is a single, very specific action that a principal can take against a resource. Think of things like reading a file in Cloud Storage, writing rows to a BigQuery dataset, or creating a Dataflow job. Each of those is a distinct permission, and there are thousands of them across the platform.
You almost never assign permissions directly. The IAM system is designed around granting roles, and a role is just a named bundle of permissions. But it is worth keeping the granular view in your head, because every role you grant ultimately resolves down to a list of permissions, and that list is what determines whether a principal can actually do the thing they are trying to do.
Google Cloud groups roles into three categories, and they sit on a spectrum from broad to narrow:
As you move from basic to predefined to custom, the granularity gets finer. Basic roles grant a lot at once. Predefined roles narrow that down to a service and a function. Custom roles let you pick the exact permissions you want, no more and no less.
There are three basic roles, and you should know exactly what each one does because the exam will use them as distractors in least-privilege questions.
Owner grants full access to all resources in the project. Critically, Owner also includes the ability to manage roles and permissions for other principals. This is the role you give to project admins or team leads who genuinely need complete control. It is almost never the right answer when the question is about giving someone enough access to do their job.
Editor grants read and write access to most resources, but it does not include the ability to manage IAM. A developer who needs to deploy and modify resources but should not be handing out permissions fits here, although in practice you usually want something more specific.
Viewer grants read-only access. Auditors, clients, or anyone who needs to inspect the system without changing anything fits this role.
The reason basic roles get flagged as a bad default is that they are extremely broad. Granting Editor on a project gives someone write access to almost every service in that project, which is rarely what you actually want. The exam often presents a scenario where the obvious-looking answer is Editor or Owner, and the correct answer is a narrower predefined role.
One small but important detail: every role has two names.
The descriptive name is what you see in documentation and conversation. Something like "Data Catalog Entry Viewer" or "Storage Object Creator." It is human-readable and tells you what the role is for.
The technical name is what you use in the Google Cloud console fields, in gcloud commands, and in IAM policy bindings. It follows the format service.roleName, so the same role becomes roles/datacatalog.entryViewer. When the exam shows you a role in a code snippet or CLI command, it will be in the technical format.
You do not need to memorize hundreds of these, but you should be comfortable recognizing the format and translating between the two when a question switches between them.
Predefined roles are where most real IAM work happens. They are scoped to a single service and a single functional pattern within that service. Some examples:
Each of these is a curated bundle. Take the Composer User role as a concrete example. Behind the descriptive name sits a specific list of permissions, including composer.dags.execute, composer.dags.get, composer.environments.list, composer.userworkloadssecrets.get, and a handful of serviceusage permissions needed to actually use the service. None of those permissions on their own would let someone be productive in Composer. Together, they add up to a coherent role that maps to a real job function.
The Storage Object Creator role is similar. It contains storage.objects.create, storage.folders.create, the multipart upload permissions, and a couple of resourcemanager permissions for project context. Each one is a small action, and together they let a principal create objects in Cloud Storage without giving them the ability to read or delete what is already there.
This is the value of predefined roles. Google has done the work of figuring out which permissions belong together for common job functions. You get least-privilege design without having to assemble it yourself.
Custom roles exist for the cases where no predefined role matches your requirements. You define them, you maintain them, and you pick the exact permissions that go in.
Consider a scenario along these lines. A financial services company operates in a highly regulated environment and needs strict control over data access. A team of data analysts needs to:
You could try to cover this with predefined roles, but you would end up granting more than you need on at least one of those services. The cleaner answer is a single custom role, something like "FinSecure Data Analyst," with a hand-picked permission list:
bigquery.datasets.get
bigquery.tables.get
bigquery.tables.list
bigquery.jobs.create
bigquery.jobs.get
dataflow.jobs.create
dataflow.jobs.get
dataflow.jobs.list
dataflow.jobs.updateContents
storage.objects.get
storage.objects.list
logging.logEntries.list
logging.logServices.list
logging.logMetrics.listThat role grants exactly the access the team needs to do their work, and nothing else. No write access to BigQuery tables. No object creation in Cloud Storage. No ability to delete Dataflow jobs. No broader logging access.
The tradeoff with custom roles is maintenance. When a service adds a new permission that fits the role's purpose, nobody is going to add it for you. Predefined roles get updated by Google as services evolve. Custom roles drift unless you actively curate them. For PCA-style design questions, this is the standard reasoning: predefined roles unless requirements demand something narrower, then custom.
The Professional Cloud Architect exam keeps coming back to least privilege. When you see a scenario asking which role to grant, the decision tree is:
Owner, Editor, and Viewer are almost always wrong answers in modern PCA scenarios unless the question is specifically about project administration or auditing.
My Professional Cloud Architect course covers IAM permissions, role categories, and custom role design alongside the rest of the IAM and governance material.
