Cloud Digital Leader Google Cloud 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.

• ✓

  Create a service account, grant it the required IAM roles on the bucket, and attach the service account to the Compute Engine instance.

  Why this is correct

  Attaching a dedicated service account to the Compute Engine instance is the recommended keyless approach. The metadata server automatically provides OAuth2 access tokens to the instance, so the application code can implicitly use the attached identity to authenticate to Google Cloud APIs. Granting only the required IAM roles on the bucket (e.g., Storage Object Viewer) follows least privilege, and because no private key ever leaves Google's infrastructure, credential rotation and expiry are handled automatically by the platform.

• ✗

  Create a service account and download its key. Store the key in Cloud Storage and have the instance download it at startup.

  Why it's wrong here

  This approach still creates and downloads a service account key, which is a long-lived private credential. Storing that key in Cloud Storage does not eliminate the fundamental risk: the instance must first authenticate itself somehow to download the key — typically by using its attached service account — which means you are unnecessarily creating and transporting a secret that can be leaked or misused. Additionally, the key file sits on the local disk after startup, making it vulnerable to exfiltration or accidental exposure, and you would need to manage its rotation and revocation manually.

• ✗

  Create a service account, generate a key, and use the gcloud auth activate-service-account command on the instance.

  Why it's wrong here

  Using gcloud auth activate-service-account writes the downloaded key file to the instance's local filesystem (e.g., in the user's home directory), where any process with appropriate file read permissions could obtain it. This contradicts Google's core recommendation to use the metadata server's dynamic tokens instead of long-lived service account keys when running on Google Cloud. The key is stored in plaintext and remains valid until explicitly revoked, so if the instance is compromised or the disk is snapshotted, the credential could be abused indefinitely, making this a poor security practice compared to attaching the service account directly to the instance.

• ✗

  Use the default Compute Engine service account and grant it roles on the bucket; no additional steps needed.

  Why it's wrong here

  While the default Compute Engine service account can technically access the bucket after you grant it roles, it typically has the broad `roles/editor` scope on the project, meaning it already has extensive permissions beyond what is needed for bucket reads. Granting additional bucket roles on top of that default account widens the attack surface unnecessarily and violates the principle of least privilege. Google Cloud best practice is to create a custom service account with only the exact IAM roles required, then attach it to the instance, rather than reusing the permissive default service account.

Go deeper

Related to this question