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 Workload Identity Federation to grant access.

  Why it's wrong here

  Workload Identity Federation is designed for workloads running outside Google Cloud—such as on-premises or in another cloud—that need to impersonate a service account via OIDC or SAML identity tokens. A Compute Engine instance already has a native mechanism for attaching a service account directly to the VM, so using federation introduces an unnecessary external identity provider dependency and does not associate the account with the instance's metadata server. Therefore, it is incorrect for authorizing an application on GCE.

• ✓

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

  Why this is correct

  Creating a dedicated service account, granting it only the required Cloud Storage IAM roles such as roles/storage.objectViewer, and attaching it to the instance with the --service-account flag at creation time follows the principle of least privilege. The VM's metadata server then provides short-lived access tokens to the application, avoiding the need to manage or download any service account keys. This is the recommended, secure pattern for a GCE workload to access Cloud Storage with minimal permissions.

• ✗

  Use the default Compute Engine service account and grant it Cloud Storage roles.

  Why it's wrong here

  The default Compute Engine service account is automatically attached to instances and often has the editor role on the project, granting broad and unintended permissions. Even if you additionally grant it specific Cloud Storage roles, the accumulated privileges far exceed what the application requires, increasing the blast radius if the instance is compromised. A dedicated service account scoped only to the necessary Cloud Storage roles is more secure and manageable than relying on the default account.

• ✗

  Create a service account, download its key, and store it on the instance.

  Why it's wrong here

  Downloading a service account key and storing it on the instance is insecure because the key is a long-lived credential that must be securely stored, rotated, and protected; any attacker with disk access can exfiltrate it. In contrast, a service account attached to the instance uses the metadata server to issue short-lived OAuth2 tokens that are automatically rotated and never written to the filesystem. Thus, this option violates Google Cloud's best practices for VM credential management and should not be used.

Go deeper

Related to this question