Cloud Digital Leader Trust and security with Google Cloud 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 JSON file and store it in the application's source code repository.

  Why it's wrong here

  Downloading a service account key JSON file and storing it in the application's source code repository is a critical security failure. Repository files are subject to Git history, code review, CI/CD logs, and branch merges, meaning the private key can be exposed to any developer, CI system, or unauthorized party with read access to the repo—and once committed, removing it from the latest commit does not remove it from Git history. This bypasses all IAM controls because the key is a static, long-lived credential that never expires unless manually deleted, giving attackers persistent access if leaked. Google strongly recommends against ever using service account keys for Google Cloud workloads, especially on a VM, where the metadata server already provides a secure, automatically rotated credential.

• ✓

  Attach the service account to the Compute Engine VM; the application obtains credentials automatically via the metadata server with no key files needed.

  Why this is correct

  Attaching a service account to a Compute Engine VM is the recommended pattern for Google Cloud workloads. The metadata server automatically provides short-lived OAuth2 access tokens to the VM, and Application Default Credentials (ADC) discovers these tokens without any key file, secret, or environment variable. This approach eliminates the need to create, distribute, or rotate long-lived service account key files, reducing the attack surface and administrative overhead. Because credentials are obtained automatically from the metadata server, the application can also transparently run on any VM with the attached identity.

• ✗

  Grant all users the Storage Admin role so the application can access Cloud Storage through their credentials.

  Why it's wrong here

  Granting all users the Storage Admin role is an improper and unsafe way to give an application access to Cloud Storage. This approach entrusts the application to use the personal credentials of individual users, which are generally short-lived, may be scoped to interactive login sessions, and can be revoked or changed by multi-factor authentication policies, causing application failures. Moreover, it violates the principle of least privilege by granting every user far more access than required for the application, broadening the blast radius if any user account is compromised. Applications should always run with a dedicated service account identity, not the credentials of a human user.

• ✗

  Create a shared service account key file accessible to all VMs via a Cloud Storage bucket.

  Why it's wrong here

  Placing a shared service account key file in a Cloud Storage bucket for VMs to retrieve is a severe security anti-pattern. The file is a long-lived private key that grants the service account's permissions to anyone who can read it, meaning any principal with even read access to that bucket—or any IAM grant exposed by a misconfigured bucket—can silently steal the key and use it outside the VM. This also creates a distribution and rotation nightmare: every VM must be re-configured whenever the key is rotated, and the key still exists at rest, increasing the chance of accidental exposure. In contrast, a VM-attached service account provides ephemeral credentials automatically, with no key file to misappropriate.

Go deeper

Related to this question