What's changed: Created Associate Cloud Engineer Chapter 5 (Domain 5 "Configuring access and security": IAM policies and roles = basic/predefined/custom roles, least privilege; service accounts = creation/least privilege/assigning to resources/impersonation/short-lived credentials).
5.2Service accounts
Understand service accounts—identities used by apps and workloads: creating them, using them in IAM policies with least privilege, assigning them to resources, service account impersonation, and issuing short-lived credentials to avoid long-lived keys.
A service account is an identity used by apps and workloads (not people). VMs, Cloud Run, and more use it to access other Google Cloud services. Handling service accounts safely is central to operational security.
5.2.1Using service accounts
Create a service account, grant it least-privilege roles via IAM, then assign it to a resource like a VM or Cloud Run. The assigned workload can access other services within those permissions. Importantly, a person can temporarily borrow a service account’s permissions via impersonation, running with elevated permissions only when needed rather than holding them constantly.
5.2.2Keys and short-lived credentials
You can issue long-lived keys for a service account, but keys carry leakage risk, so it is safer to avoid creating/distributing them. Instead, use short-lived credentials issued only when needed, or the automatic authentication of a service account assigned to a resource. The safe pattern: "avoid long-lived keys; assign to resources + short-lived credentials + least privilege."
Common: requirement → action. E.g., "an app/VM accesses other services" = assign a service account; "a person runs with elevated permissions temporarily" = impersonation; "avoid long-lived key leakage" = short-lived credentials; "for service accounts too" = least privilege.
Watch the mix-ups: (1) a service account = identity for apps/workloads (not a person). (2) Avoid long-lived keys—use assignment + short-lived credentials. (3) Apply least privilege to service accounts too (do not over-permission). (4) Use impersonation to avoid standing elevated permissions.
5.2.3Section summary
- Service account = identity for apps/workloads; grant least privilege and assign to resources
- Use impersonation to avoid standing elevated permissions, running only when needed
- Long-lived keys risk leakage—avoid them; use short-lived credentials or assigned-resource auth
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. Which identity does an app on a VM use to access other Google Cloud services without a person’s credentials?
Q2. You want to avoid long-lived service account keys. Which safer method reduces leakage risk?
Q3. To let a person borrow a service account’s permissions temporarily, only when needed, what do you use?
Q4. What is the correct principle when granting permissions to a service account?
Q5. What is the appropriate way to let a Cloud Run service access BigQuery?
Q6. Which correctly describes a service account?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.