Service account
A named account for software, so a job or service gets its own permissions and audit trail instead of borrowing a human login.
What it is
A service account is an identity owned by software rather than a person. It can receive roles, own resources, and appear in audit logs, while a credential or platform mechanism proves that a particular workload may act as it. Google Cloud IAM uses service accounts for applications, virtual machines, and automated jobs.
Reach for one when a deployment, integration, or scheduled task needs a stable name and its own least-privilege permissions. The service account is the principal; an API key, OAuth client credentials grant, signed JWT, or workload identity is the way that principal authenticates. Keeping those ideas separate makes rotation much less disruptive.
The classic failure is one powerful robot account shared by every environment. Its audit trail cannot say which workload acted, and one leak reaches everything. Create a separate identity per workload and environment, name an owner, review its roles, and prefer short-lived workload identity over downloadable JSON key files.
Ask AI for it
Create a dedicated Google Cloud IAM service account for this workload and environment, grant only the predefined roles required on the exact resources it uses, and record owner, purpose, and review date in the service account's description field. Authenticate with Workload Identity Federation and Application Default Credentials so the workload receives short-lived tokens without a downloaded JSON key. Deny basic Owner and Editor roles, do not share the service account across staging and production, and include its principal email in every authorization decision and audit event. Add a quarterly access review and alert on creation of any long-lived service-account key.