5.2.1. Creating and Assigning Service Accounts
💡 First Principle: A service account needs three things to be useful and safe — an identity (creation), a scope of what it can do (IAM permissions, ideally minimal), and a binding to whatever resource actually runs as it (assignment) — and skipping the "minimal" part of the second step is the most common real-world service account mistake.
Creating service accounts happens either explicitly (for your own applications) or implicitly — many Google Cloud services automatically provision Google-managed service accounts (like the Compute Engine default service account) to perform their own internal operations. Using service accounts in IAM policies with minimum permissions means granting only the specific roles a workload actually needs, resisting the very common shortcut of granting a broad role "to avoid permission errors later." Assigning service accounts to resources — attaching a specific service account to a VM, a Cloud Run service, or a GKE workload — determines which identity that resource authenticates as when it calls other Google Cloud APIs. Managing IAM permissions of a service account itself (not just what the service account can do, but who can act as that service account) is a distinct and easily overlooked control surface.
⚠️ Exam Trap: A scenario describing an application that was granted a broad role "just to avoid permission errors" during initial setup, with no further review, is describing exactly the anti-pattern the exam expects you to identify and correct — the fix is narrowing to the minimum permissions actually required, not leaving the broad grant in place because it currently works.
Reflection Question: A newly deployed Cloud Run service was granted the Editor role on its service account to unblock initial testing, and nobody has revisited it since. What's wrong with leaving this configuration in place long-term, and what should replace it?
