A service account is a special kind of identity in Cloud IAM that belongs to an application or a workload rather than to a person. When one component of a cloud system needs to reach another one, such as an application reading from and writing to a database, it does so as a service account. The Professional Cloud Database Engineer exam treats these accounts as the standard way that database services and the workloads around them authenticate, so it is worth understanding what they are, the two kinds you will encounter, and the role of keys.
Most cloud systems are built from components that have to talk to each other securely. An application might depend on storage, a database, a message queue, and a set of APIs, and each of those connections needs to be authorized. Service accounts are how that authorization is expressed. Each resource can be given its own service account, which lets you arrange things so that only the components that should be able to reach a given resource actually can.
The other common use is automation. A great deal of work in the cloud runs on a schedule or in response to an event rather than under a person who is logged in. A cron job, a Cloud Run function, or a CI/CD pipeline all need to interact with services without anyone present to supply credentials. You assign a service account to the job, and the job runs and reaches the resources it needs on its own. A short example makes the pattern concrete. An App Engine application might retrieve data from BigQuery, process it, write the updated data back into BigQuery, and occasionally trigger a Cloud Run function. The App Engine service account is what allows the application to read from and write to BigQuery and to invoke the function. For scheduled or batch work, the same idea applies. Rather than entering credentials by hand each time a task runs, you attach a service account to it once, and it can reach databases and APIs every time it fires.
There are two kinds of service account in Google Cloud, and the difference between them is a common exam distinction. The split comes down to who creates the account and how much control you have over its name and permissions.
Google-managed service accounts are created automatically by Google Cloud. They are used by GCP services to carry out tasks that require access to resources, and they come with a set of default permissions. You can change those permissions, but the account starts with them in place. Their names are predetermined and follow a recognizable format that varies only by project. The default Compute Engine service account is one example, using the form <project-number>-compute@developer.gserviceaccount.com. App Engine creates one as well, in the form <project-id>@appspot.gserviceaccount.com. These accounts exist to run system tasks securely within GCP services.
User-managed service accounts are created by you, and they give you more control. Because you make them, you can specify exactly what resources the account is allowed to access, assign custom permissions from the start, and give the account a custom name. They are usually created for a single, well-defined task, which keeps the scope narrow and the setup more secure. A user-managed account follows the form my-app-service-account@<project-id>.iam.gserviceaccount.com. The practical summary is that Google-managed accounts handle default work for you, and user-managed accounts give you full control over naming and permissions when you have a specific need.
When a workload runs on Google Cloud and has a service account attached to it, it can authenticate to other services as that account without you handling any credentials directly. This is the arrangement in the App Engine example above, and it is the approach we would generally lean toward, because nothing has to be stored or rotated by hand. The service account is the identity, and the platform takes care of presenting it.
Service account keys are a separate mechanism, used mainly when something outside the attached-identity model needs to authenticate as a user-managed service account. A key is a credential, so it has to be protected and managed like any other secret. Whenever a workload can use an attached service account instead, that is the cleaner option, and it removes the burden of looking after a key. For a database engineer, the takeaway is that the application or service authenticates to the database as a service account, and how it gets that identity, whether attached or by key, determines what you have to manage.
Managing user-managed service accounts requires a specific role. To create and modify them in GCP, you need the Service Account Admin role. It allows you to create service accounts for applications or automated processes, assign the permissions that control what each one can reach, and delete or disable accounts when they are no longer needed so that unused identities do not linger. In an environment with automated systems such as cron jobs, batch processes, or APIs interacting with services, having someone hold this role is how those systems stay running securely. Knowing which role grants this authority is the kind of detail the Professional Cloud Database Engineer exam tends to check.
Our Professional Cloud Database Engineer course covers service accounts alongside Cloud IAM roles and how applications authenticate to managed database services, with practice questions that drill these distinctions.
