Cloud Storage IAM Roles and Signed URLs for the PDE Exam

Cloud Storage access control is one of those Professional Data Engineer topics that looks simple on a slide and gets messy on the exam. You have three mechanisms that overlap, a stack of predefined roles that sound almost identical, and a signed URL workflow that has a very specific failure mode the test writers love to ask about. When I help people prep for the Professional Data Engineer exam, this is the section where I push them to slow down, because a single wrong assumption about which tool to reach for can flip the answer on a scenario question.

Here is how I break down the three ways to grant access to a Cloud Storage bucket, the IAM roles you actually need to recognize, and the signed URL behavior that shows up on the PDE exam.

Three ways to grant access to Cloud Storage

Google Cloud gives you three distinct mechanisms for controlling who can read or write Cloud Storage data. They are not interchangeable, and the exam expects you to know when each one is the right pick.

• IAM policies are the default answer for most access-control questions. You bind basic, predefined, or custom roles to identities, and you can attach those bindings at the organization, folder, project, or bucket level. Object-level control through IAM exists, but it requires conditional IAM policies, which is an important nuance for the exam.
• Access Control Lists (ACLs) operate at the object level only. You assign Owner, Writer, or Reader to a principal on a specific object. ACLs are considered legacy. They still work, but Google does not recommend them for new designs, and the PDE exam tends to treat IAM as the preferred answer unless the scenario explicitly calls for per-object permissions on a legacy system.
• Signed URLs grant temporary, authenticated-looking access to an individual object without provisioning an identity. Anyone holding the URL can read or write the object until the URL expires.

One detail that catches people: IAM permissions inherit downward through the resource hierarchy. A role granted at the project level propagates to every bucket in that project, and from the bucket down to its objects. If a question asks why a user can read a bucket they were never directly granted access to, hierarchical inheritance is usually the answer.

The IAM roles you need to recognize

The predefined Cloud Storage roles sound similar enough that I keep a short mental cheat sheet. These are the ones I see show up on PDE practice questions most often.

• Storage Admin grants full control over Cloud Storage resources, including creating and deleting buckets and managing objects inside them.
• Storage Object Admin lets you manage objects in buckets, which means reading, writing, and deleting object data, but does not include bucket-level operations.
• Storage Object Creator is upload-only. It lets a principal write new objects into a bucket but does not grant the ability to read, overwrite, or delete existing objects.
• Storage Object Viewer is read-only access to objects.
• Storage Legacy Bucket Reader lets you read bucket metadata and the data inside it. The legacy roles map to ACL semantics and exist for backward compatibility.

The trick on the exam is matching the role to the principle of least privilege. If a scenario says a data pipeline only needs to drop files into a landing bucket, the right answer is Storage Object Creator, not Storage Object Admin and definitely not Storage Admin. If a question gives a service account read-only analytics access to a curated dataset, Storage Object Viewer is the cleanest match.

How signed URLs actually work

Signed URLs solve a specific problem: you want to give an external party time-limited access to a single object without creating a Google account, granting an IAM role, or making the bucket public. The workflow has three steps.

• You generate a signed URL for a specific object, with a chosen validity window (for example, three hours).
• The external party uses the URL to read or write the object during that window. They do not authenticate to Google Cloud at all. The signature embedded in the URL is the credential.
• Once the URL expires, it stops working. The external party cannot use the same URL again, even if they saved it.

This is why signed URLs are the right answer for scenarios like sharing a generated report with a customer for 24 hours, letting a partner upload a file to a landing bucket without provisioning identity, or distributing a download link for a paywalled asset. If a question describes time-limited external access to a single object, signed URLs are almost always the intended choice.

The 403 error question

There is one specific signed URL failure mode worth memorizing for the Professional Data Engineer exam. If a user reports a 403 error when trying to access a signed URL, the typical cause is a permissions issue rooted in the URL no longer being valid. The fix is to increase the validity period of the signed URL so the user has enough time to complete the access before it expires.

It sounds like an obvious troubleshooting step, but the exam phrasing can make it feel like a deeper IAM problem. When you see 403 plus signed URLs in the same scenario, lengthen the expiration window before you go hunting for missing role bindings.

How I'd answer access-control questions on the exam

When a Cloud Storage access-control question lands in front of you, I work through it in this order. First, is the access permanent or temporary? Temporary points to signed URLs. Second, is the access tied to a Google identity or to anyone holding a link? An identity points to IAM, a link points to signed URLs. Third, is the access scoped to a bucket or to a specific object? Bucket scope is IAM. Object scope is either conditional IAM, a signed URL, or, in legacy systems, an ACL. Finally, if the role question is about which predefined role to pick, default to least privilege and match the verb in the scenario to the role name (Creator for upload, Viewer for read, Object Admin for manage, Admin for everything).

My Professional Data Engineer course covers Cloud Storage access control in depth, including the IAM roles, ACLs, signed URL workflow, and the troubleshooting patterns the PDE exam tests on.