GCP ACE Practice / Study guide / Topics / Service Accounts & Identity
Service Accounts & Identity
What actually gets tested on the Google Cloud Associate Cloud Engineer exam,
the traps to know, and 6 free sample questions with full explanations.
Service accounts are identities for workloads, not people — a VM, a Cloud Run service, or a CI pipeline authenticates as one instead of borrowing a human's credentials. They can hold IAM roles exactly like a user account, and the exam's central question about them is almost always the same shape: how does this workload get credentials, and is that the safest way to do it.
The safest way, in nearly every scenario the exam poses, is to attach the service account to the resource that needs it (a Compute Engine instance, a Cloud Run revision) rather than generate and download a long-lived JSON key. Downloaded keys are a recurring trap: they don't expire on their own, they're easy to leak into source control or a laptop, and rotating them is a manual, easy-to-forget process. When impersonation is on the table instead — one identity temporarily acting as a service account via roles/iam.serviceAccountTokenCreator — that's the modern, short-lived-credential alternative the exam wants you to recognize as the better answer.
Cloud Identity is the separate, adjacent idea of managing the humans: it provisions corporate identities (and is what creates an Organization node in the resource hierarchy) without requiring a paid Google Workspace subscription, and it can federate with an existing identity provider via SAML SSO and directory sync so a company's existing AD accounts authenticate into Google Cloud without duplicate identity management.
Exam tips for this topic
- Attaching a service account to the resource that uses it beats downloading a JSON key almost every time a question is framed around security — key leakage is the implied risk.
- Impersonation (roles/iam.serviceAccountTokenCreator) issues short-lived credentials without ever distributing a key file — recognize it as the more modern answer.
- Cloud Identity creates an Organization and manages people; it doesn't require Google Workspace, and it's what federates an existing on-prem AD via SAML/directory sync.
Sample questions — Service Accounts & Identity
These 6 questions are drawn from our full bank of 658 to show the style and
depth you'll get in the app. Each comes with the full explanation you'd see after answering
in a real practice session.
Cloud Identity
Your company wants employees to use corporate credentials for Google Cloud instead of personal Gmail accounts, and it does not use Google Workspace. What should it set up?
- Cloud Identity, then create the organization and manage users thereCorrect
- Have every employee create a personal Google account with the company domain in the name
- Use only service accounts for humans
- Create a shared admin Google account for the whole company
Why: Cloud Identity provides managed corporate identities (and creates the Organization node) without requiring Google Workspace, and it can federate with an existing IdP such as Active Directory. Personal accounts are unmanaged, shared accounts destroy auditability, and service accounts are for workloads, not people.
Service accounts
A junior developer asks why your Cloud Run service runs as an identity that no human ever logs into. What is a service account?
- A special non-human identity used by applications/VMs to authenticate and be authorized via IAMCorrect
- A billing account login used by automated payment jobs
- A Gmail alias registered for the application
- A Kubernetes namespace that isolates workload identities
Why: Service accounts are workload identities: code running as them gets tokens from the platform, and IAM roles bind to them like any principal. They're also resources someone can be granted control OVER (e.g., serviceAccountUser).
Cloud Identity
What is the recommended way to grant Google Cloud access to 60 developers who all need the same permissions?
- Add them to a Google Group and grant the IAM role to the groupCorrect
- Grant each of the 60 developers the role individually on every project they use
- Create one shared user account that all of the developers log in with
- Create 60 service accounts and distribute one key file to each developer
Why: Granting roles to groups centralizes membership management: joining/leaving the group adds/removes access with a full audit trail. Individual grants are unmanageable at scale, shared accounts break accountability, and service accounts are for workloads.
Service accounts
An application on one of your VMs needs to write objects into exactly one Cloud Storage bucket. What is the recommended setup?
- Run the VM as a dedicated service account and grant that SA storage.objectCreator/objectAdmin ON THE BUCKET (not project-wide), with cloud-platform scopeCorrect
- Use the default Compute Engine service account, which already carries project-wide access
- Store your personal credentials on the VM for the app to reuse
- Make the bucket public-write so the app needs no credentials at all
Why: Least privilege = dedicated SA + resource-level grant. The default-SA-with-Editor pattern is the historical anti-pattern being phased out; public-write buckets are abuse magnets.
Cloud Identity
Your company already uses Active Directory on-premises. How do employees keep a single identity for Google Cloud?
- Federate AD with Cloud Identity (e.g., Google Cloud Directory Sync + SSO/SAML) so AD remains the source of truthCorrect
- Manually create a matching Google account for every employee and ask each user to keep both passwords in sync themselves
- Issue every employee an API key tied to their AD username instead of a user identity
- Give all engineers one shared corporate login managed by the IT helpdesk
Why: Directory Sync provisions users/groups from AD into Cloud Identity, and SAML SSO lets AD (or an IdP like ADFS) authenticate them — one identity, centrally disabled when someone leaves. Manual account duplication and shared logins undermine security; API keys are not user identities.
Service accounts
Creating a VM, you're unsure whether to restrict its legacy access scopes or rely on IAM roles for the attached service account. What is the modern guidance?
- Set the cloud-platform scope and control access purely with IAM roles on the service accountCorrect
- Restrict the VM to narrow scopes and skip IAM role management entirely
- Set only scopes, since scopes override whatever IAM allows
- Neither matters
Why: Scopes are a legacy per-VM credential limiter; effective access = intersection of scopes and IAM. Recommended: full cloud-platform scope + least-privilege IAM, one control plane instead of two.
Practice this for real
The app has dozens more questions on this and every other topic, with instant scoring,
spaced repetition of what you get wrong, and progress tracking across sessions.
Start practicing →
This topic shows up in
Other topics