Google ACE Practice Question: A company uses VPC Service Controls to protect…

A company uses VPC Service Controls to protect Cloud Storage. They have a service perimeter that includes the storage API and the project where the stored data resides. Users inside the perimeter can access the data, but users outside cannot. However, a group of users outside the perimeter are able to access the data using a signed URL generated by a service inside the perimeter. Why does this happen?

⚠ Common exam trap

Google Cloud often tests the misconception that VPC Service Controls are a universal access control mechanism, when in fact they do not apply to signed URLs or public buckets, leading candidates to incorrectly assume a misconfiguration or override.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

VPC Service Controls do not apply to signed URLs.

VPC Service Controls are designed to restrict access to Google Cloud resources based on the network origin of requests, but they do not evaluate or block requests made using signed URLs. Signed URLs are authenticated via cryptographic signatures, not IAM or network context, so they bypass the perimeter check entirely. This is by design, as signed URLs are intended for temporary, out-of-band access.

Answer analysis

Option-by-option breakdown

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

✓
VPC Service Controls do not apply to signed URLs.
Why this is correct
VPC Service Controls set a security perimeter around Google Cloud APIs, but they only evaluate requests authenticated via Google identity credentials. Signed URLs are an alternative access method that authorizes access through time-limited query parameter signatures embedded in the URL, so the request never triggers VPC SC context. Therefore, VPC SC simply does not apply to signed URLs.
✗
Signed URLs bypass VPC Service Controls.
Why it's wrong here
The statement that signed URLs 'bypass' VPC Service Controls is technically imprecise because bypass suggests evading an enforced policy. In reality, VPC SC never inspects signed URL requests: the URL signature itself authenticates the request, so no Google account identity is presented, and the perimeter logic is not invoked. The exact behavior is that VPC SC is not applicable to signed URL traffic, not that it is circumvented.
✗
The service perimeter is misconfigured, missing signed URL restrictions.
Why it's wrong here
The assumption that the service perimeter is misconfigured because it lacks 'signed URL restrictions' is incorrect because VPC Service Controls offers no such setting for signed URLs. Service perimeter configuration selects projects, services, and access levels (e.g., IP), but those controls apply only to API calls made with a Google identity; signed URL requests carry only a cryptographic signature. Since there is no VPC SC feature to restrict signed URLs, configuring the perimeter differently cannot affect them.
✗
The users have been granted IAM roles that override the perimeter.
Why it's wrong here
This explanation is wrong because signed URL access does not depend on IAM roles at all; the URL's embedded signature is the sole authorization, so the requesting user's IAM privileges are irrelevant. Also, IAM cannot override VPC Service Controls when a perimeter is active—denials from VPC SC are enforced regardless of IAM permissions. Therefore, the ability to use a signed URL despite a restricted perimeter is not due to IAM roles granting an override. It is simply that VPC SC never sees the signed URL request.

Go deeper

Google ACE Practice Question: A company uses VPC Service Controls to protect…

Why each option matters

Option-by-option breakdown

Related to this question