Google ACE Practice Question: Allow a vendor to upload files to a specific…

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 GCP service account for the vendor and share the key JSON file.

  Why it's wrong here

  Sharing a service account key JSON file grants the vendor raw Google credentials with whatever permissions the service account has, giving them direct API access to your GCP project until the key is rotated or deactivated. These keys are long-lived private secrets; distributing them outside your organization means you lose auditability and control, and the vendor must persist and secure the key file. A signed URL contains the signature within the URL itself, so no secret is shared with the vendor—they only receive the time-limited link.

• ✓

  Generate a Signed URL with a 24-hour expiration for the specific bucket path.

  Why this is correct

  A signed URL with a 24-hour expiration provides a time-limited, authenticated upload (HTTP PUT) link for a specific Cloud Storage object path. The URL is signed with a service account private key that you retain, and the vendor does not need a Google account or any extra credentials—they simply perform an HTTP PUT to the unique, query-parameter-bearing URL. Once 24 hours pass, the link expires and access is automatically revoked, making it the ideal solution for a one-time, temporary external upload.

• ✗

  Make the Cloud Storage bucket publicly writable and share the bucket URL.

  Why it's wrong here

  Making a Cloud Storage bucket publicly writable uses the `allUsers` IAM member with storage.objects.create and delete permissions, allowing anyone on the internet to upload, overwrite, or delete objects without any authentication. This permanently exposes the bucket to spam, malware, storage cost abuse, and data compromise, and it violates the principle of least privilege. In contrast, a signed URL restricts access to a known third party for a specific object path and a finite expiration window.

• ✗

  Add the vendor's email to the bucket's IAM policy with Storage Object Creator role.

  Why it's wrong here

  Adding the vendor's email to the bucket's IAM policy with the Storage Object Creator role requires the vendor to have a valid Google account (e.g., Gmail or Workspace) and grants persistent, project-wide upload access until it is explicitly removed. This goes beyond the temporary, single-path access needed here, and it introduces identity administration overhead for managing a third-party user. Signed URLs avoid the need for a Google account and automatically expire, reducing the security and management burden.

Go deeper

Related to this question