If you sit the Professional Cloud Architect exam without a clean mental model of IAM principals, you will lose easy points. The good news is that the foundation is small. There are two kinds of identities that get granted access in Google Cloud, and one of those two does most of the heavy lifting in real architectures and on the test.
I want to walk through what a principal actually is, the difference between user accounts and service accounts, the split between Google-managed and user-managed service accounts, and a few practical rules that show up repeatedly in PCA scenarios.
Identity and Access Management lets you manage who has what access to which resources in Google Cloud. That sentence has three parts and the exam tests all three. The "who" is the principal. The "what access" is the role or set of permissions. The "which resources" is the project, folder, organization, or individual resource the policy is attached to.
Everything else in Cloud IAM is a refinement of those three pieces.
A principal is any identity that can be granted access to GCP resources. Principals are what IAM policies are applied to. If you cannot name a principal, you cannot grant a role.
There are two types of principal you will see in Google Cloud and on the Professional Cloud Architect exam: 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. Authentication happens with a username and password, usually a Google or Workspace identity.
A service account is a special kind of account intended for use by applications, processes, or virtual machines rather than individual users. It allows services to authenticate with each other and access resources securely. Service accounts authenticate with keys and tokens instead of usernames and passwords. They are the default mechanism for any automated or scheduled task that needs to talk to a Google Cloud service.
Most of the IAM questions on the PCA exam are really questions about service accounts. The reason is simple. A real cloud application has many components that need to communicate securely, and you cannot have a human typing a password every time one of them needs to call another.
Imagine an App Engine application that interacts with BigQuery and Cloud Functions. The app retrieves data from BigQuery for processing. After processing, it writes the updated data back into BigQuery. Occasionally it triggers a Cloud Function to handle a specific task. In every one of those calls, the App Engine service account is what allows the application to access BigQuery and to invoke the Cloud Function. Each resource is assigned its own service account so that only authorized resources can interact.
The same logic applies to scheduled work. A cron job, a batch job, or a CI/CD pipeline cannot pause and wait for a human to provide credentials. You assign a service account to the job and the job runs on its own, authenticating to the services it needs.
There are two kinds of service accounts in Google Cloud and the difference matters for both daily work and the exam.
Google-managed service accounts are automatically created by Google Cloud. They are used by GCP services to handle tasks that require resource access. They come with default permissions, which you can change but which exist from the moment the account appears. Their names follow a predetermined format that varies slightly by project.
The Compute Engine default service account is a Google-managed service account. It looks like this:
<project-number>-compute@developer.gserviceaccount.comThe App Engine service account is also Google-managed and follows this pattern:
<project-id>@appspot.gserviceaccount.comUser-managed service accounts give you more control. You create them manually and you specify exactly what they can access. You assign custom permissions from the start and you pick a custom name. They are typically used for a specific task or application so that you can tightly scope what the account is allowed to do. The naming pattern is:
my-app-service-account@<project-id>.iam.gserviceaccount.comThe split comes down to control and use case. Google-managed service accounts handle default tasks for built-in services. User-managed service accounts give you full control over permissions and naming when you want a tight, purpose-built identity.
To create and modify user-managed service accounts in GCP, you need the Service Account Admin role. That role lets you create user-managed service accounts for applications or automated processes, assign permissions to them, and delete or disable them when they are no longer needed.
If you have a team running automated systems on service accounts, having someone with the Service Account Admin role whose job is to manage those accounts is what keeps the environment secure over time. On the Professional Cloud Architect exam, when a question asks who should be allowed to provision a new service account for an application, Service Account Admin is the role to recognize.
The single most important practical rule in this section is short. Do not use your own user account to run scripts.
Picture a Python script connecting to a Cloud SQL database. The script might run from your local machine, from an application, or from a VM, and it attempts to query or manage the database. Without the right authentication, it fails. The correct way to make it succeed is to authenticate the script with a service account. Service accounts are specifically designed for use by applications, scripts, and other non-human processes that need to access Google Cloud services. Make sure the service account has only the permissions the script actually needs. For a script that reads from Cloud SQL, that might be the Cloud SQL Viewer role and nothing else.
User accounts are tied to individuals and are not meant for programmatic access. The whole point of service accounts is to run services, automated processes, and scripts. When the exam describes a developer running a script with their personal credentials, the answer is almost always "stop doing that and use a service account with the minimum role required."
Three things are worth locking in before you sit the test. A principal is anything that can be granted access, and the two types are user accounts and service accounts. Service accounts split into Google-managed accounts that GCP creates for you and user-managed accounts that you create yourself for specific applications. The Service Account Admin role is what you need to create and modify user-managed service accounts, and scripts should always run under a service account with narrowly scoped permissions, never under a personal user account.
My Professional Cloud Architect course covers IAM principals and service accounts alongside the rest of the IAM and governance material.
