Google ACE Practice Question: A team stores sensitive configuration files in…

Answer analysis

Option-by-option breakdown

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

• ✗

  Make the specific files publicly readable and share the direct URL

  Why it's wrong here

  Setting an object's ACL to publicRead (or making it public via bucket policy) means anyone with the URL—and anyone who can guess the object name—can read it, with no expiration and no fine-grained control. The direct URL remains functional indefinitely until you explicitly remove the ACL or binding, leaving the data exposed for an inconsistent period. A signed URL, by contrast, restricts access to a set of named objects and automatically stops working after the configured expiration, without changing the object's default access controls.

• ✓

  Generate a Signed URL for the specific files with the required expiration time

  Why this is correct

  A signed URL is a URL that includes an expiration timestamp, a signature, and a signature algorithm, generated using your service account's private key; when accessed, Cloud Storage verifies the signature and grants access only to the specific object path embedded in the URL. This is the correct choice because it gives the partner temporary, revocable access to exactly the identified files without modifying IAM policies or making data public. The signature is cryptographically tied to the object name, bucket, and expiration, so the URL cannot be altered to access other objects.

• ✗

  Create a temporary GCP service account for the partner and share its JSON key

  Why it's wrong here

  Sharing a service account JSON key gives the partner a permanent authentication credential with permissions tied to that service account, not to specific objects. To scope access you would need to create a custom role, set bucket-level IAM, and periodically rotate the key, which is cumbersome and creates a long-lived secret outside your control. Signed URLs are the purpose-built solution for granting temporary, resource-specific access without creating or managing additional identities.

• ✗

  Enable uniform bucket-level access and create a public IAM binding for 24 hours

  Why it's wrong here

  Uniform bucket-level access removes per-object ACLs and relies on bucket-level IAM; granting the allUsers principle a role at the bucket level makes every object in the bucket publicly readable for as long as the binding is active. IAM bindings do not expire inherently—while IAM Conditions can add a time constraint, the binding remains in place and requires active removal. This approach exposes far more data than the designated files and grants access to anyone on the internet, not just the partner.

Go deeper

Related to this question