When a human logs into GCP, they use a user account with a username and password. When an application or automated process needs to access GCP resources, it uses a service account. Service accounts are the identity mechanism for non-human actors in GCP, and they appear constantly in the Associate Cloud Engineer exam — in IAM questions, in compute scenarios, and in architecture questions involving application-to-service communication.
A service account is an identity associated with an application or a VM rather than a person. It has an email address that follows the pattern name@project-id.iam.gserviceaccount.com and it can be granted IAM roles just like a user account can. The difference is how it authenticates: service accounts use cryptographic keys and tokens rather than passwords.
When a Compute Engine VM runs with a service account attached, any code running on that VM can automatically get credentials for that service account without any configuration. The VM requests a short-lived access token from the metadata server, and the client libraries handle this automatically. This is the recommended pattern for GCP applications running on GCP infrastructure.
The alternative to service accounts would be embedding user credentials in application code or configuration files. That approach is a serious security problem. User credentials can be accidentally committed to version control, they do not expire automatically, and revoking them affects the person's other access as well.
Service accounts solve this cleanly. They are scoped to a specific purpose, they use tokens that expire automatically, they can be granted only the permissions the application needs, and they can be disabled or deleted without affecting any human user's access. When a service account is compromised, you disable it and create a new one. The blast radius is contained.
The exam frequently presents scenarios where application components need to communicate with GCP services. An App Engine application needs to write to BigQuery. A Cloud Function needs to read from Cloud Storage. A scheduled job needs to publish to Pub/Sub. In each case, the right answer is to create a service account with the appropriate predefined role and attach it to the component.
To create a service account, you need the Service Account Admin role (roles/iam.serviceAccountAdmin) in the project. You create it through the IAM and Admin section of the Cloud Console, or with gcloud:
gcloud iam service-accounts create my-app-sa --display-name="My Application Service Account"After creation, you grant IAM roles to the service account like you would to any principal:
gcloud projects add-iam-policy-binding PROJECT_ID --member="serviceAccount:my-app-sa@PROJECT_ID.iam.gserviceaccount.com" --role="roles/bigquery.dataEditor"A Compute Engine VM is associated with a service account at creation time. Every API call the VM makes to GCP services automatically uses that service account's identity and permissions. You can change the service account on a stopped VM, but you cannot change it while the VM is running.
Cloud Run services and Cloud Functions each run as a specific service account. For Cloud Run, this is configured when you deploy the service. For Cloud Functions, you specify it in the function configuration. Getting the service account right means the function or service has exactly the permissions it needs and nothing more.
In some cases, an application running outside of GCP needs to authenticate as a service account. For this purpose, you can create a service account key: a JSON file containing cryptographic credentials that the application uses to obtain tokens.
Service account keys carry significant risk. They do not expire by default and must be managed carefully. If a key is exposed, anyone who has it can impersonate the service account until the key is deleted. Google recommends avoiding service account keys when possible and using workload identity federation or the built-in metadata server instead for applications running on GCP or other cloud platforms.
The Associate Cloud Engineer exam tests the distinction between using the metadata server (the secure, recommended approach for GCP-hosted workloads) and service account keys (the approach for external workloads, with associated risks).
For the full picture of how service accounts fit into GCP authentication patterns, including how they interact with IAM roles and org policies, my Associate Cloud Engineer course covers this in detail alongside the scenarios that appear most frequently on the exam.
For workloads running outside of GCP that need to authenticate as a service account, service account keys are the traditional approach but carry risk because they are long-lived credentials that must be distributed and managed. Workload Identity Federation is the modern alternative.
With Workload Identity Federation, external workloads (running on AWS, Azure, on-premises, or in GitHub Actions CI/CD pipelines) can authenticate to GCP using their existing identity from those platforms without needing a service account key file. The workload presents its identity token to GCP's Security Token Service, which validates the token against a configured trust relationship and issues a short-lived GCP access token. The workload never holds a long-lived GCP credential.
The Associate Cloud Engineer exam does not go deep into Workload Identity Federation configuration, but knowing that it exists as the preferred alternative to service account keys for external workloads is useful context. When an exam question presents a scenario about external workloads authenticating to GCP and one answer involves service account keys while another involves Workload Identity Federation, the federation option is the more secure and Google-recommended choice.
Cloud Audit Logs track service account activity just like user activity. When a service account is used to make an API call, the audit log records the service account's email address as the principal. This makes service accounts traceable: if something goes wrong in a production environment, you can look at the audit logs to see exactly which service account performed which actions and when. This auditability is one of the reasons service accounts are preferable to shared user accounts for automated workloads.
