When you look at the IAM section of a GCP project, you will likely see service accounts you did not create. These are Google-managed service accounts, and they are distinct from the service accounts you create yourself for your applications. Understanding the difference between Google-managed and user-managed service accounts is a detail the Associate Cloud Engineer certification exam tests, particularly in IAM troubleshooting and permission scenarios.
Google automatically creates service accounts for certain GCP services when those services are enabled in a project. These accounts allow GCP services to operate on your behalf without requiring you to set up the authentication yourself.
The two most commonly tested Google-managed service accounts are the Compute Engine default service account and the App Engine default service account.
The Compute Engine default service account has an email address in the format:
[PROJECT_NUMBER]-compute@developer.gserviceaccount.comWhen you create a VM in Compute Engine without specifying a service account, this default account is attached automatically. It comes with the Editor basic role by default, which is overly permissive for most workloads. Google recommends overriding this with a custom service account that has only the permissions your VM actually needs.
The App Engine default service account follows the format:
[PROJECT_ID]@appspot.gserviceaccount.comIt is created when you first deploy an App Engine application and is used for App Engine's internal operations. Like the Compute Engine default, it comes with broad permissions that you may want to restrict in security-conscious environments.
Other Google-managed service accounts exist for Cloud Build, Dataflow, and other services. Their naming conventions vary, but they follow similar patterns using the project number or project ID combined with a service-specific suffix.
User-managed service accounts are the ones you create explicitly for your own applications and workloads. Their email addresses follow the format:
[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.comYou choose the name, you grant the roles, and you manage the lifecycle. User-managed service accounts give you full control over the permissions assigned, which aligns with the principle of least privilege. Rather than relying on the default Editor role that Google-managed accounts often carry, you grant exactly the roles the application needs.
A Cloud Run service that only reads from Cloud Storage and writes to BigQuery should run as a user-managed service account with Storage Object Viewer and BigQuery Data Editor. It should not run as a service account with Editor access across the entire project.
The Associate Cloud Engineer exam tests this distinction in several ways. A question might describe a VM that is making unexpected API calls to Cloud Storage, and ask why. One answer path involves the Compute Engine default service account carrying broad permissions that the VM operator did not intend to grant. Another common question type presents a scenario where a developer creates a VM without specifying a service account and asks which service account the VM uses: the answer is the Compute Engine default service account.
The exam also tests the permissions required to manage service accounts. To create, delete, or manage service account keys, a principal needs the Service Account Admin role. To use a service account (attach it to a resource), a principal needs the Service Account User role. These two roles are separate because the ability to manage service accounts is more sensitive than the ability to use them.
The Service Account User role deserves special attention. When a human user needs to deploy a resource (like a Cloud Run service) that runs as a specific service account, they need the Service Account User role on that service account. Without it, the deployment fails even if they have permission to create Cloud Run services. The user is essentially requesting that their deployment runs as a different identity, and GCP requires explicit permission to do that.
This permission requirement appears in exam scenarios where a developer has the Cloud Run Developer role but cannot deploy because they lack Service Account User on the service account the deployment is configured to use.
User-managed service accounts can have keys created for them, which are JSON credential files used by external applications. Managing these keys is an operational responsibility that the exam touches on. Keys do not expire by default, which means a key created for a temporary purpose and forgotten remains valid indefinitely unless you delete it. The Cloud Console shows all active keys for each service account, and reviewing them periodically to delete unused keys is a security best practice.
For Google-managed service accounts like the Compute Engine default service account, you do not create or manage keys directly. Google handles the credential lifecycle for its managed accounts. This is one advantage of using built-in GCP infrastructure over external workloads: the authentication is managed for you.
Because the Compute Engine default service account comes with the Editor basic role, any VM created without specifying a service account has broad project-level access. In security-conscious environments, organizations restrict or replace the default service account. One approach is to remove the Editor binding from the default service account at the project level and use user-managed service accounts with appropriate predefined roles for all VM workloads. This requires more setup but significantly reduces the blast radius if a VM is compromised.
Some organizations go further and disable the ability to use the default service account entirely through an org policy, requiring all VM deployments to explicitly specify a user-managed service account. This is the pattern the exam describes when it presents a scenario about enforcing least privilege at the infrastructure level rather than relying on developers to make the right IAM decisions.
My Associate Cloud Engineer course walks through these service account scenarios in detail, including the permission requirements and the default service account behaviors that most frequently appear as exam distractors.
