Signed URLs are one of the most testable Cloud Storage topics on the Associate Cloud Engineer exam because they fit a very specific scenario that nothing else fits. This article covers what they are, the gsutil command to generate one, the expiration model, common use cases, and the exam patterns.
It does not cover signed policy documents for browser uploads in full, advanced V4 signing details, or signed URLs from Cloud Storage's HTTP API directly. The exam tests the concept and the basic command.
A signed URL is a special URL that grants time-limited access to a specific object in a Cloud Storage bucket without requiring the user to authenticate. Anyone with the URL can access the object, until the URL expires.
The Associate Cloud Engineer exam puts it directly. Signed URLs are a secure way to grant time-limited access to a specific object in a bucket without requiring authentication. That definition is exactly what the exam tests.
The flow has three steps. You generate a signed URL with an expiration time. You give that URL to whoever needs access. They use the URL to read or write the object. After the expiration, the URL stops working and the object is no longer accessible to that party.
The URL itself contains a cryptographic signature created by the service account or user that generated it. Cloud Storage validates that signature on every request. Nothing else is needed. No login, no IAM grant, no shared credential.
The gsutil command looks like this:
gsutil signurl -d 1h /path/to/key.json gs://my-bucket/my-file.pdfThe -d flag sets the duration. 1h means one hour. You can specify minutes, hours, or days. The key file is a JSON service account key for the account that has read access to the object. The output is the signed URL itself.
You can also use the --method flag to allow PUT operations instead of just GET, which is how browser uploads work.
There are a few common cases. Sharing a file with someone outside your GCP organization who does not have a Google Cloud account. Letting a partner download a single asset without setting up IAM for them. Allowing a browser to upload a file directly to a bucket without sending it through your application server. Distributing time-limited access to media files for a streaming product.
The common thread: the recipient is not a GCP user, and you do not want to set up persistent permissions. Signed URLs are the right tool for that. IAM is the wrong tool because IAM grants persistent access to authenticated GCP identities. Signed URLs grant temporary access to anyone, regardless of identity.
If you see a question about giving someone outside your organization access to a single Cloud Storage object for a limited time, the answer is a signed URL. This is the most common version.
If you see a question about allowing a user to upload directly from their browser to a bucket without going through your backend, the answer is a signed URL with PUT method. This is less common but does show up.
If you see a question about a partner who needs to download files from your bucket and the partner does not have a Google account, the answer is a signed URL. IAM-based answers are wrong here because IAM requires Google identities.
If you see a question that pairs the words temporary and access in a Cloud Storage context, signed URLs are almost always the answer.
This part trips people up. Signed URLs do not provide ongoing access to a person or a service. They provide one-time temporary access that any holder of the URL can use. If two people get the same URL, both can use it. If someone forwards it, the recipient can use it.
For ongoing access for a known identity, IAM is the right answer. For shared access among a defined group of users, IAM groups or domain-restricted access is the right answer. Signed URLs are for the specific case of time-limited, identity-free access.
Signed URLs grant temporary access to a specific Cloud Storage object without requiring the recipient to authenticate. You generate them with gsutil signurl, set an expiration, and hand the URL to whoever needs access. The Associate Cloud Engineer exam tests this with scenarios that involve external users, time limits, and the absence of GCP identities.
My Associate Cloud Engineer course covers signed URLs in the Cloud Storage section alongside IAM and ACLs, which the ACE exam often tests against each other.
