hardMultiple SelectObjective-mapped
Google ACE Practice Question: Which THREE options are valid methods to…
Which THREE options are valid methods to authenticate a service account when making calls to Google Cloud APIs from a Compute Engine instance?
⚠ Common exam trap
Google Cloud often tests the distinction between authentication (proving identity) and authorization (granting permissions), and the trap here is that candidates mistakenly think API keys (Option C) can authenticate a service account, when in fact API keys only identify the project and are not tied to a specific identity.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Using a JSON key file downloaded for the service account.
A JSON key file downloaded for a service account contains the private key necessary to create a signed JWT assertion, which is exchanged for an OAuth 2.0 access token via the Google OAuth 2.0 token endpoint (https://oauth2.googleapis.com/token). This is a standard authentication method for service accounts outside of Google Cloud, but it is also valid from a Compute Engine instance, though less secure than using the metadata server.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Using a JSON key file downloaded for the service account.
Why this is correct
A JSON key file downloaded for the service account is a valid authentication method because it contains the private key associated with the service account's identity. Applications can load this file via the GOOGLE_APPLICATION_CREDENTIALS environment variable or directly in client libraries (e.g., service_account.Credentials.from_service_account_file). This enables the application to sign requests and obtain OAuth2 access tokens that prove it is acting as that service account, making it suitable for server-to-server authentication.
- ✗
Using a user account's OAuth2 tokens obtained via a web browser.
Why it's wrong here
Using a user account's OAuth2 tokens obtained via a web browser is invalid for authenticating a service because user tokens represent the identity and consent of an individual end-user, not a service account. The OAuth2 flow for user accounts involves interactive browser login and multi-factor authentication, which is not designed for unattended server-side workloads. Moreover, the resulting tokens carry a different principal and do not grant the same IAM permissions as the service account, so they cannot authenticate or impersonate the service account in API calls.
- ✗
Using an API key generated from the Cloud Console.
Why it's wrong here
An API key generated from the Cloud Console is wrong for service account authentication because API keys only identify the calling project for quota and billing purposes; they do not authenticate a principal or establish an identity. API keys are typically used for accessing public data or APIs with project-level restrictions, and they are not accepted by IAM-aware methods that require an OAuth2 token or service account credentials. Therefore, an API key cannot prove that a request is being made by a specific service account.
- ✓
Using the Compute Engine metadata server to obtain an access token for a custom service account.
Why this is correct
Using the Compute Engine metadata server to obtain an access token for a custom service account is valid because the metadata server exposes identity endpoints (e.g., /computeMetadata/v1/instance/service-accounts/{account}/token) for any service account that is attached to the VM instance. By querying this endpoint, an application running on the instance can retrieve an OAuth2 access token for that specific custom service account without needing to manage key files. The token is signed by Google and is scoped to the service account's identity, enabling authenticated requests to Google Cloud APIs.
- ✓
Using the default service account's automatically provided credentials.
Why this is correct
The default service account's automatically provided credentials are a valid authentication method because every Compute Engine instance has a default service account attached unless explicitly overridden. These credentials are automatically available through the metadata server's default service account endpoint, and the application libraries (e.g., Application Default Credentials) fetch them transparently without any explicit configuration. This leverages the instance's identity token to authenticate as the default service account, making it the recommended approach on Compute Engine to avoid managing service account key files.
Go deeper
Related to this question
Learn chapter
Google Cloud Platform Overview
Key term
Google Cloud
Google Cloud is a suite of cloud computing services offered by Google that provides infrastructure, platform, and software solutions over the internet.
Key term
Service account
A service account is a special type of account used by an application or a virtual machine, rather than a human user, to authenticate and interact with cloud services and APIs securely.
About these practice questions
One of 769 original ACE practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This ACE practice question is part of Courseiva's free Google Cloud certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the ACE exam.