Cloud IAM is one of those topics that shows up across every Google Cloud certification, and the Generative AI Leader exam is no exception. The way I think about it is the way Google describes it: Identity and Access Management lets you manage who has what access to which resources in Google Cloud. That sentence is the whole job description of IAM. The rest of the topic is just unpacking what each of those pieces means.
I want to walk through the IAM concepts that are fair game on the Generative AI Leader exam in the same order they tend to build on each other. We will start with principals, move into permissions, then look at how permissions get bundled into roles, and finally cover the two name formats you will see roles written in.
A principal is any identity that can be granted access to Google Cloud resources. When an IAM policy is applied to something, it is applied to a principal. If you do not have a principal, there is nothing for IAM to act on.
For the Generative AI Leader exam, the two principal types worth knowing are user accounts and service accounts.
A user account is associated with a human being. It provides the identity and credentials a person uses to authenticate and access cloud services. Users authenticate via username and password.
A service account is a special kind of account intended for use by applications, processes, or virtual machines rather than individual people. It lets services authenticate with each other and access resources, and it is what you reach for when you want to enable automated or scheduled tasks. Instead of a username and password, service accounts authenticate via keys and tokens.
The distinction matters because the answer to "who is doing this work" is rarely just a person. In a generative AI workload, a model serving endpoint calling another Google Cloud service, a pipeline kicking off a training job, or a scheduled batch process pulling data from Cloud Storage are all situations where the principal is a service account, not a human.
Once you have a principal, you need a way to control exactly what that principal can do. That is what permissions are for.
A permission is a very granular action that can be authorized for a principal. There are thousands of permissions in Google Cloud, and they are intentionally fine-grained.
The example I find easiest to keep in mind is a data engineer. Depending on the team, that one person might need the ability to read files in Cloud Storage, write to datasets in BigQuery, and create and cancel Dataflow jobs. Each of those is a separate permission, and a real-world data engineer would need many more than just those three.
The granularity is the point. Permissions exist at this level of detail so you can give a principal exactly the access they need and nothing else.
Granting permissions one at a time would be unmanageable. Roles solve that problem. A role is a collection of permissions grouped together, and you grant roles to principals rather than handing out individual permissions.
Google Cloud has three categories of roles, and they differ in how specific their permissions are.
Basic roles are broad permissions at the project level. They give a lot of access across the board, which makes them convenient and risky in equal measure.
Predefined roles are defined by Google and tailored for common job functions. BigQuery Data Editor and Storage Admin are examples. They are more specific than basic roles and they save you from having to assemble a permission list yourself for standard job functions.
Custom roles are managed by you and can be any combination of permissions. They exist for the cases where a predefined role does not fit your specific needs.
As you move from basic to predefined to custom, roles become more specific in terms of what they allow. The Generative AI Leader exam expects you to know that progression and to be able to recognize which category fits a scenario.
Roles show up in two different formats, and the Generative AI Leader exam can present either one. Knowing both is useful because they refer to the same thing but appear in different places.
The descriptive role name is the readable name. "Data Catalog Entry Viewer" is an example. This is the format you see in documentation and in conversation, and it clearly describes the role's purpose in plain language.
The technical role name is the fully qualified name used when you actually assign roles in the Google Cloud console or via the command line interface. The same role written technically is datacatalog.entryViewer. The format is always service.roleName.
Descriptive names are for readability. Technical names are for implementation. The exam can show you either, so do not get thrown off when a question references a role by its technical name and the answer choices use the descriptive form, or the other way around.
Cloud IAM is not specific to generative AI workloads, but every generative AI workload on Google Cloud runs on top of it. A model fine-tuning job needs a service account with permissions to read training data and write outputs. A team building an internal AI assistant needs roles that scope what their developers can deploy and what their applications can call. The same principals, permissions, and roles you would use for any other Google Cloud workload are what control access for generative AI work too.
For the Generative AI Leader exam, the IAM material itself stays at the conceptual level I have walked through here. You should be able to define a principal, explain why service accounts exist, distinguish basic from predefined from custom roles, and read both role name formats.
My Generative AI Leader course covers Cloud IAM alongside the rest of the foundational material on the exam.
