Skip to main content
Hello and welcome back. In this lesson we cover service accounts: what they are, why you need them, how they differ, and safe production practices for using them.

​
What is a service account and why use one?

IAM grants identities (users or service accounts) roles that permit specific actions. A human Google account receives a role and a person signs in to the Cloud Console to act. For non-human identities—Compute Engine VMs, Cloud Run services, Cloud Composer workers, or other GCP services—you need a programmatic identity: a service account. When you attach a service account to a resource (for example, a Compute Engine VM), applications running on that resource can call Google Cloud APIs with the service account identity and the permissions you granted. This avoids impersonating individual users and enables automated tasks to act securely.
A slide titled "Cloud IAM – Types of Service Accounts" showing a diagram where a Compute Engine instance uses a service account (Role: VPN Editor) to access a Cloud VPN inside a project/zone. The graphic illustrates how applications/VMs authenticate to Google Cloud services.
Example scenarios:
  • A VM needs to change network settings (Compute Network Admin). Attach a service account with the appropriate role and the VM can make those changes programmatically.
  • Cloud Composer needs to write to Cloud Storage. Assign a dedicated service account to Composer and grant the required Storage permissions so Composer writes without a human credential.
Quick CLI examples:
  • Grant a role to a service account:
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:SA_EMAIL" \
  --role="roles/compute.networkAdmin"
  • Create a VM with a service account attached:
gcloud compute instances create INSTANCE_NAME \
  --zone=ZONE \
  --service-account=SA_EMAIL \
  --scopes=https://www.googleapis.com/auth/cloud-platform
  • Replace the service account on an existing VM:
gcloud compute instances set-service-account INSTANCE_NAME \
  --service-account=SA_EMAIL --zone=ZONE

​
Types of service accounts

Google Cloud provides three main types of service accounts. The table below summarizes who manages each type, typical use cases, privilege patterns, and how they are created or deleted.
TypeWho managesTypical use casesPrivilegesCreation / Deletion
User-managed service accountsYou (project admins/dev teams)Custom applications, ETL pipelines, CI/CD, VM workloads — any workload identity you controlYou define roles and permissions; best for least-privilege enforcementCreated and deleted by your team (manual or IaC)
Default service accountsAuto-created by GCP when certain services are usedUsed by Google Cloud services that need a service identity (e.g., Compute Engine default account)Often granted broad permissions by default — can be overprivilegedCreated automatically; deleting may break services that depend on them
Google-managed service accountsFully managed by GoogleInternal support for Google-managed services (e.g., App Engine internal accounts)Permissions are fixed by Google and not configurable by project adminsCreation and deletion controlled by Google
A slide titled "Comparing Service Account Types" showing a table that compares User‑Managed, Default, and Google‑Managed service accounts across characteristics like management, use cases, privilege, and creation/deletion. A short certification tip appears at the bottom.
Certification tip: Know which service account type to use for each scenario and which supports least privilege. Always ask: does this workload need broad roles like Editor, or can you grant a narrowly scoped role?
Prefer user-managed service accounts for workloads. They provide ownership and let you grant only required permissions (least privilege).
Follow these practices to maintain good IAM hygiene and reduce risk:
Best practiceWhy it matters
Use user-managed service accounts per workloadEasier auditing, clearer ownership, and tighter permission scoping
Disable automatic default service account creation where feasiblePrevents unexpected over-privileged accounts and forces explicit identity creation
Grant the minimal permissions requiredLimits blast radius from bugs or compromise (principle of least privilege)
Use structured naming and ownershipOne account per app/environment simplifies incident response and audits
Enable audit logs and monitoringDetect and attribute automated activity; correlate Cloud Audit Logs and app logs
Additional operational tips:
  • Rotate credentials and keys for any service account keys you create.
  • Prefer Workload Identity Federation or short-lived tokens over long-lived service account keys where possible.
  • Use IAM Conditions for more granular access (e.g., restrict by request time or resource attributes).
A presentation slide titled "Managing Service Accounts in Production" showing three colored arrows recommending: Use User-Managed Accounts, Disable Default Creation, and Understand Permissions. Each recommendation is briefly annotated (least privilege/better security, enforcing user-managed accounts, and preventing over-permissive access).
Do NOT reuse a single service account across unrelated services or environments. Reuse increases the blast radius of a compromise and makes it hard to determine which workload performed an action.

​
Summary

  • Service accounts are non-human identities used by applications and services to call Google Cloud APIs.
  • Prefer user-managed service accounts for production workloads and enforce least-privilege permissions.
  • Avoid default account reuse, create explicit service identities with clear ownership, and monitor their activity.
That is it for this lesson. See you in the next lesson.

Watch Video