This chapter covers GCP Service Accounts and Workload Identity, two critical concepts for secure authentication and authorization in Google Cloud. Service accounts are the backbone of programmatic access to Google APIs, and Workload Identity extends this model to on-premises or multi-cloud workloads. For the ACE exam, approximately 8-12% of questions touch on IAM and security, with service accounts and Workload Identity being a significant subset. You will need to understand how to create, manage, and use service accounts, the difference between user-managed and Google-managed service accounts, and how Workload Identity Federation allows external workloads to impersonate service accounts without storing keys. Mastery of these topics is essential for designing secure, automated cloud solutions.
Jump to a section
Imagine a secure office building where employees need access to restricted areas. Instead of each employee using their personal ID (which would require managing hundreds of individual credentials), the building issues a 'project badge' for each team. This badge is not tied to any person—it's a digital credential that the team's automated systems (like a cleaning robot or a server rack) can use to open doors. The badge has a unique ID and a secret key (like a PIN) that proves it's authentic. When the robot approaches a door, it presents the badge, and the door's reader checks with a central security server (Google's IAM system) to verify that the badge is authorized for that specific door. The robot never needs to know an employee's password; it just uses the badge. If the badge is compromised, the security team can revoke it without affecting any human's access. The building's security logs record every door access by badge ID, not by robot serial number, making auditing straightforward. This is exactly how service accounts work: they are non-person identities with their own keys, used by applications to authenticate to Google APIs, with permissions granted via IAM roles, and all activity logged via Cloud Audit Logs. The key difference is that in GCP, the 'badge' can also be temporarily attached to a VM (like a badge clipped to a uniform) so that any application running on that VM automatically inherits its permissions—this is the default service account feature.
What is a Service Account?
A service account is a special type of Google account that represents a non-human user. It is used by applications, virtual machines (VMs), and other services to authenticate to Google Cloud APIs and perform operations. Unlike a user account, a service account does not have a password; instead, it uses a cryptographic key (either Google-managed or user-managed) for authentication. Service accounts are identified by an email address in the format: name@project-id.iam.gserviceaccount.com.
Service accounts are essential for automating tasks without embedding user credentials in code. They enable fine-grained access control: you grant IAM roles to a service account, and any application using that service account inherits those permissions.
How Service Accounts Work Internally
When an application needs to call a Google API, it must present an authentication token. The process involves three main steps:
Token Request: The application uses its service account key (a JSON or P12 file) to create a JSON Web Token (JWT) and sends it to Google's OAuth 2.0 token endpoint (https://oauth2.googleapis.com/token). The JWT includes the service account email, a scope (e.g., https://www.googleapis.com/auth/cloud-platform), and a timestamp.
Token Exchange: Google's authentication server verifies the JWT signature using the public key associated with the service account. If valid, it returns an access token (a signed JWT) and optionally a refresh token. The access token is valid for typically 1 hour (3600 seconds) by default.
API Call: The application includes the access token in the Authorization header of API requests. Google's API gateway validates the token and checks IAM permissions before allowing the operation.
For VMs running in Compute Engine, the process is simplified. When you attach a service account to a VM instance, the VM's metadata server provides access tokens automatically. Applications on the VM can retrieve a token by querying the metadata server at http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token. This eliminates the need to manage keys on the VM.
Types of Service Accounts
Google-Managed Service Accounts: Created automatically by Google services (e.g., Compute Engine default service account). The keys are managed by Google and rotated automatically. You cannot download these keys.
User-Managed Service Accounts: Created by you. You can create and manage keys (JSON or P12). These are used when you need to run applications outside of Google Cloud (e.g., on-premises) or when you need to control key rotation.
Google APIs Service Account: A special service account used by Google APIs to access resources on your behalf. For example, service-<project-number>@compute-system.iam.gserviceaccount.com is used by Compute Engine.
Key Components and Defaults
- Service Account Email: Unique identifier, e.g., my-sa@my-project.iam.gserviceaccount.com.
- Service Account ID: A numeric unique ID (e.g., 1234567890).
- IAM Roles: Permissions are granted via roles (primitive, predefined, or custom). Common roles: roles/iam.serviceAccountUser (allows using the service account), roles/iam.serviceAccountTokenCreator (allows creating tokens), roles/iam.workloadIdentityUser (for Workload Identity).
- Key Types:
- Google-managed keys: No download; automatically rotated; used when running on GCP.
- User-managed keys: RSA private key (JSON or P12); you must manage rotation and security.
- Default Service Account: When you enable Compute Engine, a default service account is created with the email [project-number]-compute@developer.gserviceaccount.com. It has the editor role by default, which is overly permissive. Best practice is to create dedicated service accounts with least privilege.
Configuration and Verification Commands
Creating a Service Account (using gcloud):
gcloud iam service-accounts create my-sa \
--display-name="My Service Account"Granting a Role to a Service Account:
gcloud projects add-iam-policy-binding my-project \
--member="serviceAccount:my-sa@my-project.iam.gserviceaccount.com" \
--role="roles/storage.objectViewer"Creating a Key for a Service Account:
gcloud iam service-accounts keys create my-key.json \
--iam-account=my-sa@my-project.iam.gserviceaccount.comAttaching a Service Account to a VM:
gcloud compute instances create my-vm \
--service-account=my-sa@my-project.iam.gserviceaccount.com \
--scopes=https://www.googleapis.com/auth/cloud-platformVerifying Service Account Permissions:
gcloud projects get-iam-policy my-project \
--flatten="bindings[].members" \
--format='table(bindings.role)' \
--filter="bindings.members:my-sa@my-project.iam.gserviceaccount.com"Workload Identity Federation
Workload Identity Federation allows workloads running outside of Google Cloud (e.g., on AWS, Azure, or on-premises) to authenticate to Google Cloud without using service account keys. Instead, it uses a federated identity token from an external identity provider (IdP) to exchange for a Google Cloud access token.
Key Concepts:
- Workload Identity Pool: A collection of external identities that can impersonate a service account.
- Workload Identity Provider: A configuration that defines how to trust tokens from an external IdP (e.g., AWS IAM, Azure AD, OIDC).
- Service Account Impersonation: The external workload obtains a token from the IdP, then calls the google.iam.credentials.generateAccessToken API to impersonate a service account. The service account must have the roles/iam.workloadIdentityUser role on the pool.
Step-by-step:
1. Create a workload identity pool.
2. Add a provider (e.g., AWS or OIDC).
3. Grant the roles/iam.workloadIdentityUser role to the pool's principal (e.g., principalSet://iam.googleapis.com/projects/123/locations/global/workloadIdentityPools/my-pool/*).
4. The external workload obtains a token from its IdP (e.g., AWS STS).
5. The workload calls the generateAccessToken API with the IdP token to get a Google Cloud access token.
6. The workload uses that token to call Google APIs.
Benefits: No service account keys to manage; no key rotation; reduced risk of credential leakage.
Interaction with Related Technologies
IAM: Service accounts are IAM members. You grant roles to service accounts, not to users directly in many cases.
Cloud KMS: Service accounts can be used to encrypt/decrypt data using Cloud KMS keys. The service account needs the cloudkms.cryptoKeyEncrypterDecrypter role.
Compute Engine: Service accounts attached to VMs are used by applications running on the VM to access other GCP services.
GKE: Kubernetes pods can use a service account by referencing it in the pod spec via iam.gke.io/gcp-service-account annotation (Workload Identity for GKE).
Cloud Functions / Cloud Run: These serverless services can use a service account to access resources. You specify the service account at deployment time.
Security Best Practices
Use separate service accounts for different applications to limit blast radius.
Grant the minimum permissions required (least privilege).
Avoid using the default Compute Engine service account with broad editor role.
Rotate user-managed keys regularly (e.g., every 90 days).
Use Workload Identity Federation instead of keys for external workloads.
Enable audit logging to monitor service account activity.
Common Exam Traps
Mixing up service account vs user account: Service accounts are for applications, not people.
Thinking service accounts need passwords: They use keys, not passwords.
Assuming default service account is secure: It has the editor role, which is too permissive.
Forgetting that service accounts can be used across projects: You can grant a service account from one project access to resources in another project.
Confusing Workload Identity with Workload Identity Federation: Workload Identity (for GKE) is different from Workload Identity Federation (for external workloads).
Create a Service Account
Use the gcloud CLI or Cloud Console to create a new service account. The command `gcloud iam service-accounts create my-sa --display-name='My SA'` creates a service account in the current project. This account is not yet granted any permissions. The service account email is generated automatically. You can also create it via the Console under IAM & Admin > Service Accounts. After creation, the service account appears in the list with a unique ID. No keys are created at this stage.
Grant IAM Roles to the Service Account
Assign IAM roles to the service account so it can perform actions. For example, `gcloud projects add-iam-policy-binding my-project --member='serviceAccount:my-sa@my-project.iam.gserviceaccount.com' --role='roles/storage.objectViewer'` grants read access to Cloud Storage. The role binding is stored in the project's IAM policy. Multiple roles can be granted. The service account itself is now authorized to read objects in any bucket in the project (subject to bucket-level policies).
Create and Download a Key
Generate a private key for the service account to authenticate from outside GCP. Use `gcloud iam service-accounts keys create my-key.json --iam-account=my-sa@my-project.iam.gserviceaccount.com`. This downloads a JSON file containing the private key. The key is a RSA private key in PKCS#8 format. You must store this file securely. If the key is compromised, you can delete it using `gcloud iam service-accounts keys delete`. Google does not retain the private key; only the public key is stored.
Authenticate an Application with the Key
An application uses the key file to obtain an access token. For example, using the Google Cloud Client Libraries, the code reads the key file and sets the `GOOGLE_APPLICATION_CREDENTIALS` environment variable pointing to the JSON file. The library then automatically handles token generation. Alternatively, you can use the `gcloud auth activate-service-account` command to authenticate the gcloud CLI with the service account. The access token is valid for 1 hour and is cached.
Use Workload Identity Federation (Optional)
For workloads outside GCP, set up Workload Identity Federation. First, create a workload identity pool and provider. Then grant the `roles/iam.workloadIdentityUser` role to the pool's principal. The external workload obtains a token from its IdP (e.g., AWS STS) and exchanges it for a Google Cloud access token via the `generateAccessToken` API. This avoids storing service account keys. The exchange uses the REST endpoint `https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/SA_EMAIL:generateAccessToken`.
Scenario 1: Automated Data Processing Pipeline
A company runs a data processing pipeline on Compute Engine VMs that reads data from Cloud Storage, processes it, and writes results to BigQuery. They create a dedicated service account data-pipeline-sa and grant it roles/storage.objectViewer and roles/bigquery.dataEditor. They attach this service account to the VM instances. Applications on the VM automatically get tokens from the metadata server. This eliminates the need to store keys on the VM. They also set up Cloud Audit Logs to monitor all API calls made by this service account. A common issue is forgetting to set the correct scopes when creating the VM. If scopes are too restrictive, the token will not have the necessary permissions even if IAM roles are granted. The team uses --scopes cloud-platform to allow all cloud API access, then relies on IAM for fine-grained control.
Scenario 2: On-Premises Application Accessing GCP
A legacy application running on-premises needs to write logs to Cloud Logging. Instead of storing a service account key on the on-prem server, the company uses Workload Identity Federation with an AWS IAM provider. They create a workload identity pool and configure the AWS account as an IdP. The on-prem application (which runs in AWS) obtains an AWS STS token, then exchanges it for a Google Cloud access token. The service account logging-sa has roles/logging.logWriter. The application never sees a service account key. The main challenge is configuring the attribute mapping correctly so that the principal is properly identified. Misconfiguration leads to 'permission denied' errors. The team tests by simulating token exchange using the gcloud auth print-access-token command with the federated token.
Scenario 3: Multi-Project Access
A DevOps team manages multiple projects. They have a central CI/CD system in project 'ci-cd' that needs to deploy resources to 'dev' and 'prod' projects. They create a service account deployer-sa in the 'ci-cd' project and grant it roles/compute.instanceAdmin and roles/iam.serviceAccountUser in the 'dev' and 'prod' projects. The CI/CD tool uses the service account key (stored in Secret Manager) to authenticate. This allows the CI/CD to manage instances in other projects without having a user account. A common mistake is granting the service account the roles/editor role in the target projects, which is too broad. Instead, they grant specific roles. They also enable Organization Policies to restrict where service account keys can be used.
What the ACE Exam Tests (Objective 5.1)
The ACE exam focuses on:
Creating and managing service accounts (gcloud commands)
Understanding the difference between user-managed and Google-managed keys
Granting IAM roles to service accounts
Using service accounts with Compute Engine, GKE, Cloud Functions, and Cloud Run
Workload Identity Federation basics: pools, providers, and impersonation
Best practices: least privilege, key rotation, avoiding default service accounts
Common Wrong Answers and Why
'Service accounts use passwords.' — This is false. Service accounts use cryptographic keys (JSON or P12). Passwords are for user accounts.
'The default Compute Engine service account has no permissions.' — Actually, it has the editor role by default, which is overly permissive. Candidates often think it's secure.
'Workload Identity Federation requires storing service account keys on the external system.' — The whole point is to avoid keys. The external system uses a federated token instead.
'You can use a service account across projects without any additional configuration.' — You must grant the service account IAM roles in the other project. Simply having the service account in one project does not give it access to another.
Specific Numbers and Terms
Access token lifetime: 1 hour (3600 seconds) by default.
Service account email format: name@project-id.iam.gserviceaccount.com.
Default service account email: [project-number]-compute@developer.gserviceaccount.com.
Role for Workload Identity impersonation: roles/iam.workloadIdentityUser.
Role for using a service account: roles/iam.serviceAccountUser.
Role for creating tokens: roles/iam.serviceAccountTokenCreator.
Edge Cases and Exceptions
Scopes vs IAM: When using a service account on a VM, both scopes and IAM roles apply. The effective permission is the intersection of scopes and IAM. For example, if IAM grants storage.objectAdmin but scopes only allow storage.readonly, the effective permission is read-only. The exam may test that scopes are deprecated but still functional.
Service account key deletion: Deleting a key does not invalidate tokens already issued. Tokens are valid until they expire.
Service account as a member of a group: You can add a service account to a Google Group and grant roles to the group. This simplifies management but adds latency.
How to Eliminate Wrong Answers
If an answer mentions 'password' for a service account, eliminate it.
If an answer suggests using the default service account for production, eliminate it.
If an answer claims Workload Identity Federation requires keys, eliminate it.
If an answer says service accounts can only be used in the same project, check if cross-project IAM is mentioned — it is possible.
Service accounts are non-human identities used by applications to authenticate to Google APIs.
Service accounts use cryptographic keys, not passwords.
The default Compute Engine service account has the `editor` role — avoid using it in production.
Grant IAM roles to service accounts using the `member` format `serviceAccount:EMAIL`.
Access tokens obtained by service accounts are valid for 1 hour (3600 seconds) by default.
Workload Identity Federation allows external workloads to impersonate a service account without keys.
The role `roles/iam.workloadIdentityUser` is required for Workload Identity Federation impersonation.
When using a service account on a VM, the effective permission is the intersection of scopes and IAM roles.
Service accounts can be granted roles in other projects to enable cross-project access.
Always follow the principle of least privilege when assigning roles to service accounts.
These come up on the exam all the time. Here's how to tell them apart.
User-Managed Service Account Keys
You create and download the private key (JSON or P12).
You are responsible for key rotation and security.
Can be used from anywhere (on-prem, other clouds).
Risk of key leakage if not stored securely.
Can be deleted individually via gcloud.
Google-Managed Service Account Keys
Google creates and manages the key automatically.
Keys are rotated automatically by Google.
Only usable when running on GCP (e.g., on a VM).
No key material to manage; lower risk.
Cannot be downloaded; no manual deletion needed.
Mistake
Service accounts use passwords for authentication.
Correct
Service accounts use cryptographic keys (JSON or P12 files) or metadata server tokens. They never have passwords.
Mistake
The default Compute Engine service account is secure because it's Google-managed.
Correct
The default service account has the `editor` role, which is overly permissive. It should be replaced with a custom service account with least privilege.
Mistake
Workload Identity Federation requires storing service account keys on the external workload.
Correct
Workload Identity Federation eliminates the need for keys. The external workload uses a token from its own identity provider to impersonate a service account.
Mistake
A service account can only be used in the project where it was created.
Correct
A service account can be granted IAM roles in other projects, allowing it to access resources across projects.
Mistake
Service account keys never expire.
Correct
Google-managed keys are rotated automatically, but user-managed keys do not expire by default. You must manually rotate them. However, you can set a key expiration policy.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No, service accounts are not for human login. Humans should use their own user accounts. However, a human can impersonate a service account using the `gcloud auth activate-service-account` command, but this is for testing or automation, not everyday use.
A user account represents a human and uses a password or OAuth. A service account represents an application and uses a cryptographic key. Service accounts cannot sign in to the Cloud Console interactively.
Add the service account as a member in the IAM policy of the target project using the format `serviceAccount:EMAIL`. Then grant the desired role. For example: `gcloud projects add-iam-policy-binding target-project --member='serviceAccount:my-sa@source-project.iam.gserviceaccount.com' --role='roles/storage.objectViewer'`.
Existing access tokens will continue to work until they expire (typically 1 hour). New tokens cannot be generated with that key. You should rotate keys gradually to avoid disruption.
Yes. When deploying a Cloud Function, you can specify a service account using the `--service-account` flag. The function will use that service account to access resources. If not specified, it uses the default App Engine service account.
Workload Identity Federation allows workloads running outside of GCP (e.g., on AWS, Azure, or on-prem) to authenticate to GCP without service account keys. Use it when you have external applications that need to access GCP resources and you want to avoid managing keys.
Create a new key, update your application to use the new key, then delete the old key. Use `gcloud iam service-accounts keys create` and `gcloud iam service-accounts keys delete`. For automated rotation, you can use a script or a secrets management tool.
You've just covered GCP Service Accounts and Workload Identity — now see how well it sticks with free ACE practice questions. Full explanations included, no account needed.
Done with this chapter?