In Google Cloud IAM, there are two types of identities that get granted access to resources: user accounts and service accounts. Understanding the difference between them, and knowing when to use each, is foundational to working with GCP and is tested consistently on the Associate Cloud Engineer exam. The question is not complicated once you understand what each one is designed for.
A user account is associated with a person. It is the Google account or Google Workspace account that a human uses to sign in. Authentication happens through a username and password, often with multi-factor authentication layered on top. When someone logs into the Cloud Console, uses gcloud auth login, or accesses GCP resources through a web interface, they are using a user account.
User accounts are appropriate for interactive access: a developer SSH-ing into a Compute Engine VM, an administrator configuring IAM policies, an analyst running queries in the BigQuery console. Any situation where a human is directly interacting with GCP calls for a user account.
Managing IAM for many users with similar access needs is more efficient through Google Groups. You create a group, add members to it, and assign IAM roles to the group rather than to individuals. When someone joins the team, you add them to the group and they automatically inherit the appropriate permissions. When they leave, you remove them from the group. This pattern is Google's recommended approach for managing access at scale, and it reduces the overhead of maintaining individual IAM bindings for every user.
A service account is associated with an application, a VM, or an automated process rather than a person. It is how code authenticates to GCP. Instead of a username and password, service accounts authenticate using cryptographic keys or tokens managed by Google.
Service accounts are essential for any automated process that needs to interact with GCP services. When an App Engine application needs to read from Cloud Storage, it runs as a service account with the appropriate Cloud Storage permissions. When a Cloud Function needs to write to BigQuery, it uses a service account with BigQuery permissions. When a scheduled batch job runs Dataflow pipelines, the job authenticates as a service account rather than requiring a person to be present and logged in.
When you create a Compute Engine VM, you can assign a service account to the instance during creation. The code running on that VM then inherits the service account's permissions and can call GCP APIs without needing any credentials stored on the VM. This is the recommended pattern: assign a service account at instance creation time, grant that service account only the permissions it needs, and let Google manage the credential rotation. Storing JSON key files on VMs is a less secure alternative that is generally discouraged.
There are two categories of service accounts. Google-managed service accounts are created automatically when you enable certain GCP services. When you create a Compute Engine instance, a default service account is created automatically in the format [project-number]-compute@developer.gserviceaccount.com. App Engine has its own default service account as well. These come with broad default permissions, which is why Google recommends creating dedicated user-managed service accounts for specific workloads instead.
User-managed service accounts are created by you and are specific to a task or application. You name them, define what permissions they need, and assign them to the appropriate resources. A user-managed service account for a data pipeline might have BigQuery read and write access and Cloud Storage read access and nothing else. Creating and managing service accounts requires the Service Account Admin IAM role.
The principle of least privilege applies to both user accounts and service accounts: grant only the permissions needed for the specific task, and nothing more. For service accounts, this means creating a dedicated service account for each application or pipeline and granting it only the permissions that application requires. Avoid relying on the default Compute Engine service account, which has broad Editor permissions across the project, for production workloads.
Over-privileged access increases the blast radius of a security incident. If a service account with broad permissions is compromised, an attacker can do more damage than if the account had narrow, task-specific permissions. The exam tests this concept through scenarios where a service has been given too many permissions and asks what the appropriate corrective action is. The answer almost always involves creating a more constrained custom or predefined role.
The exam regularly presents scenarios involving service accounts. Know when to use a service account instead of a user account: automated processes, application-to-service communication, and scheduled jobs all require service accounts. Know the difference between Google-managed and user-managed service accounts, and why user-managed accounts with narrow permissions are preferred for production workloads. Know that assigning a service account to a VM at creation time is preferable to storing key files on the instance. And know that the Service Account Admin role is required to create and manage service accounts.
One additional IAM feature worth knowing is Access Approval. This feature lets you require your team's approval before Google support staff can access your resources to assist with a support case. The roles/accessapproval.approver role is required to review and approve those requests.
The GCP Study Hub Associate Cloud Engineer course covers IAM in full, including user accounts, service accounts, roles, and the principle of least privilege, with exam-focused examples throughout.
