Identity and Access Management, or IAM, is how Google Cloud answers a single question for every action: who has what access to which resource. Each part of that sentence maps to a piece of the model. The who is a principal, meaning a person or a service account. The what is the access itself, expressed as roles and permissions. The which is the resource the access applies to. Most IAM questions on the Professional Cloud Database Engineer exam come down to keeping these three parts straight and knowing which kind of identity belongs in a given scenario.
A principal is any identity that can be granted access to Google Cloud resources. Another way to say it is that principals are the entities IAM policies are applied to. When you grant access, you are attaching a role to a principal, and that principal is the thing being authorized. There are two kinds you will work with, and the exam expects you to tell them apart.
A user account is associated with a human being. It carries the identity and credentials a person needs to authenticate and reach cloud services and resources. Users authenticate with a username and password. This is the account a database administrator, a developer, or an operator signs in with.
A service account is a special kind of account meant for use by applications and virtual machines rather than individual people. It lets services authenticate with one another and reach resources securely, and it is often what enables automated or scheduled tasks to run on their own. Service accounts authenticate with keys and tokens rather than usernames and passwords. When a Compute Engine VM connects to a database, or a job runs on a schedule without anyone signing in, the identity behind that action is a service account.
The distinction matters in practice. If a scenario describes a person logging in, the right identity is a user account. If it describes an application, a VM, or an unattended process reaching a resource, the right identity is a service account. A common framing is to ask which identity should be granted access to let a workload connect to a database, and the answer turns on whether a human or a machine is doing the connecting.
The access half of IAM is expressed as roles and permissions. A permission is the right to perform a specific action on a resource, and a role is a collection of those permissions bundled together. You do not hand permissions to a principal one at a time. You grant a role, and the principal receives the permissions inside it. This is what makes IAM manageable, because real workloads need many permissions and grouping them into roles keeps the grants readable.
Because access flows through roles rather than raw permissions, the practical skill is choosing a role that grants what a principal actually needs and no more. A service account that only reads from a database does not need a role that also allows it to modify or delete data. Matching the role to the work is the everyday discipline behind least privilege.
Every grant is scoped to a resource. The resource is the thing access is granted on, and in the database context that is generally an instance or a project containing database services. The same principal can hold different access on different resources, so naming the resource is part of any complete grant. When you put the three pieces together, an IAM grant reads as a single statement: this principal has this role on this resource.
The Professional Cloud Database Engineer exam tends to test whether you can read a scenario and assign the right identity, the right role, and the right scope. Keep the model in the order it is built. Start with who is acting and decide whether that is a user account or a service account. Then decide what they need to do and pick a role that covers it. Then confirm which resource the grant lands on. Holding those three parts apart is usually enough to separate the correct answer from options that mix up the identity type or overgrant the access.
Our Professional Cloud Database Engineer course covers Cloud IAM fundamentals alongside service account design and least-privilege role selection, with practice questions that drill these distinctions.
