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.

• ✗

  Download the service account key and store it on the instance's persistent disk.

  Why it's wrong here

  Downloading a service account key creates a long-lived private credential file that can be stolen, leaked, or exposed via disk snapshots, backups, or any user with instance access. Storing it on a persistent disk violates the principle of least privilege and Google's security guidance. The instance should instead rely on the attached service account, which provides short-lived tokens through the metadata server without any key material on disk.

• ✗

  Use gcloud auth activate-service-account on the instance with the service account email.

  Why it's wrong here

  The gcloud auth activate-service-account command requires a service account key file (JSON or P12) to authenticate; merely providing the service account email is insufficient because the command needs the private key to sign requests. On a Compute Engine instance, gcloud and client libraries already obtain credentials automatically from the attached service account via the metadata server, so running this command is both impossible without a key and unnecessary.

• ✓

  Attach the service account to the instance using the --service-account flag when creating the instance.

  Why this is correct

  Attaching the service account via the --service-account flag at instance creation is the correct approach because it binds the identity to the VM and makes credentials available through the metadata server. Code running on the instance can fetch OAuth 2.0 tokens from the metadata endpoint (http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token) and act on behalf of the service account. This avoids managing key files and ensures that IAM permissions are automatically applied to the instance.

• ✗

  Store the service account email in an instance metadata and use gcloud commands.

  Why it's wrong here

  Storing the service account email in instance metadata is just an arbitrary label; it does not grant the instance any permissions or make gcloud commands run as that service account. The instance must be created with the service account attached via the --service-account flag; only then does the metadata server expose tokens for that identity. Without the attachment, gcloud falls back to user credentials or the default service account, and the email in metadata has no effect on authentication.

Go deeper

Related to this question