Google ACE Configuring Access and Security Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Use Application Default Credentials with a user account.

  Why it's wrong here

  Application Default Credentials with a user account is designed for local development and interactive login, not for production workloads on a virtual machine. A user account's credentials are short-lived and rely on an interactive OAuth flow to refresh, which cannot run unattended on a Compute Engine instance. Moreover, tying the instance's permissions to an individual user account couples the VM's identity to a person, creating significant security and lifecycle management problems. The correct identity for a VM is a service account managed by Google Cloud.

• ✗

  Download a service account key and store it on the instance.

  Why it's wrong here

  Downloading a service account key and storing it on the instance is widely discouraged because it creates a long-lived static secret that can be exfiltrated or accidentally exposed. Google recommends avoiding service account key downloads entirely; instead, the instance should rely on the attached service account's identity via the metadata server, which issues short-lived access tokens automatically. Managing, rotating, and revoking static keys adds operational overhead, and a leaked key compromises the service account until it is manually rotated, making this approach inferior to the attached service account pattern.

• ✓

  Create a service account, grant it the required roles, and attach it to the instance using the --service-account flag.

  Why this is correct

  Create a service account, grant it the required IAM roles (for example, roles/storage.objectViewer for Cloud Storage read access), and attach it to the instance using the --service-account flag at instance creation time. The instance then automatically authenticates to Google Cloud APIs through the instance's metadata server, which provides OAuth 2.0 access tokens on behalf of the service account without storing any secret material on the disk. This is the standard, secure pattern for granting a Compute Engine instance access to other GCP resources, as it leverages the cloud-native identity and avoids managing static credentials.

• ✗

  Set up a VPN connection to Cloud Storage.

  Why it's wrong here

  Setting up a VPN connection to Cloud Storage is irrelevant to the authentication problem because Cloud Storage is not a private resource inside a VPC that a VPN can reach; it is a global HTTP/HTTPS service with public endpoints. A VPN only establishes a private network path between your on-premises network and your VPC, and it does not provide any identity or authorization context for API calls. To access Cloud Storage, the instance must present valid credentials (such as from a service account) and have the appropriate IAM permissions, regardless of the network path, so the VPN option does not address the requirement.

Go deeper

Related to this question