Google ACE Practice Question: A company has a Compute Engine instance that…

Answer analysis

Option-by-option breakdown

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

• ✗

  Generate a signed URL for the bucket and embed it in the application.

  Why it's wrong here

  Signed URLs are designed for temporary, time-limited access to a specific object, not for an instance's ongoing read access to a bucket. The URL contains an expiration timestamp and a cryptographic signature, so embedding it in the application would require a refresh mechanism and could cause broken reads when it expires. It also exposes the URL to anyone with access to the code or logs, violating least-privilege and secure credential-handling practices. This approach does not provide stable, auditable, role-based access for a long-running VM.

• ✓

  Create a service account with Storage Object Viewer role and associate it with the instance.

  Why this is correct

  Associating a purpose-built service account with the instance is the Google-recommended pattern for granting cloud resources to a VM. Granting the Storage Object Viewer role (roles/storage.objectViewer) provides read-only access to objects without allowing writes or deletions, aligning with least privilege. The Compute Engine metadata server automatically supplies short-lived OAuth tokens for the service account, so no credentials are ever hard-coded or stored on disk. This integration works with the instance's default credentials and is fully auditable in Cloud Audit Logs.

• ✗

  Use the default Compute Engine service account with Storage Admin role.

  Why it's wrong here

  The default Compute Engine service account is created per project and often has the Editor role by default, giving it broad permissions far beyond object viewing. Assigning Storage Admin (roles/storage.admin) explicitly is still over-privileged because it allows creating, deleting, and managing all buckets and objects, not just reading them. Using the default service account couples the instance to a shared, project-wide identity rather than a scoped, per-workload identity, which complicates security reviews and least-privilege enforcement. A custom service account with only the necessary roles is the recommended practice.

• ✗

  Store the bucket credentials in the instance metadata.

  Why it's wrong here

  Instance metadata is accessible via the metadata server to any process running on the instance, including an attacker who has achieved local execution. Storing bucket credentials—such as an access key or service account key—in metadata exposes them in plaintext to anyone who queries the metadata endpoint. These credentials are static and long-lived, lack automatic rotation, and persist even when the instance no longer needs the access. This violates Google's guidance to avoid embedding or storing service-account keys on VMs; instead, use the attached service account to obtain short-lived tokens automatically.

Go deeper

Related to this question