In Google Cloud, the principals you grant access to, whether a user account or a service account, need a way to be told exactly which actions they are allowed to perform. The mechanism for that is permissions, and the way permissions get organized and assigned is through roles. The Professional Cloud Database Engineer exam expects you to know how those two pieces fit together, because a lot of access-control questions come down to picking the right kind of role for a given situation. We will walk through what a permission is, the three categories of roles, and the two formats you will see role names written in.
A permission is a single, specific action that a principal can be authorized to take. Think about what a database engineer might actually need to do on a given team. That could include reading files in Cloud Storage, writing to an AlloyDB database, or creating and updating a Cloud SQL instance. Each of those capabilities maps to permissions, and they are deliberately fine grained.
There are thousands of permissions across Google Cloud, and even a single user is usually granted many of them rather than just a handful. Permissions are the most granular layer of the access model, which is also why they are not assigned to principals one at a time in normal practice. Managing access at the level of individual permissions would be unwieldy, so Google Cloud groups them.
A role is simply a collection of permissions grouped together. Instead of handing a user dozens of separate permissions, you grant them a role, and the role carries the permissions with it. There are three categories of roles, and the main thing that separates them is how broad or how specific the permissions inside them are. As you move from basic to predefined to custom, the access becomes more specific.
Basic roles are broad permissions that apply at the project level. They grant a wide amount of access across the board, which makes them blunt instruments. They were the original way to grant access in Google Cloud and they are still available, but their breadth is exactly what makes them a poor fit for most real assignments where you want to limit what a principal can touch.
Predefined roles are more specific. Google defines and maintains them, and each one is tailored to a common job function. A BigQuery Data Editor or a Storage Admin are predefined roles, bundling the permissions that someone in that function typically needs. Because Google curates and updates them, they cover most everyday access needs without you having to assemble permissions yourself.
Custom roles are the ones you manage. A custom role can hold any combination of permissions you choose, which lets you build a role around a need that none of the predefined roles match cleanly. The flexibility comes with the responsibility of maintaining the role over time, since it does not get updated by Google the way predefined roles do.
For the exam, it helps to keep the trade off in mind. Basic roles give you breadth at the project level. Predefined roles give you Google-curated bundles aligned to job functions. Custom roles give you precise, self-managed control when nothing predefined fits. When a scenario describes a principal that needs a tightly scoped set of actions and notes that no predefined role lines up, that is the signal for a custom role. When the scenario maps neatly onto a familiar job function, a predefined role is usually the cleaner answer.
Roles appear in two different formats, and recognizing both keeps you from getting tripped up. The first is the descriptive role name, for example BigQuery Data Viewer. This is the readable name written in plain language, and it is what you tend to see in documentation or in conversation. It describes the role's purpose clearly.
The second is the technical role name. For that same role, it looks like bigquery.dataViewer. This is the fully qualified name used when you assign roles in the Google Cloud console or through the command-line interface. It follows the format service.roleName, where the service comes first and the specific role name follows. Descriptive names exist for readability, and technical names exist for implementation in tools. They refer to the same role, just written for different audiences.
Knowing both formats matters on the Professional Cloud Database Engineer exam because a question might present a role by its technical name and expect you to recognize what it does, or describe a capability and expect you to know which role provides it. The pattern is consistent enough that once you have seen a few, the service.roleName structure reads naturally.
Our Professional Cloud Database Engineer course covers IAM permissions and roles alongside principals and service accounts, with practice questions that drill these distinctions.
