One of the trickier distinctions on the Professional Data Engineer exam shows up when a question describes a data exfiltration risk and asks how to lock things down. The two answers that look right are usually "put each workload in a separate VPC" and "wrap the projects in a VPC Service Controls perimeter." They sound similar. They are not. One protects the network. The other protects the data. If you pick the wrong one on the exam, the answer is wrong even when the wording feels close.
I want to walk through how I think about these two when I see them side by side, because the Professional Data Engineer exam loves to test whether you understand that network isolation and service isolation are different layers of the stack.
The simplest project-isolation pattern is to give each project its own VPC, then make sure there is no VPC peering, no shared VPC arrangement, and no route between them. Project A has VPC Network A with its own subnets. Project B has VPC Network B with its own subnets. Nothing connects the two.
Traffic cannot flow directly from a VM in Project A to a VM in Project B because there is no network relationship between the networks. No peering, no shared routes, no transit. This is a clean way to separate environments, departments, or tenants, and it satisfies a lot of compliance requirements around blast radius and lateral movement.
Here is the catch, and this is where the exam pushes you. Separate VPCs only stop traffic from flowing through the VPC fabric. They do not stop a workload in Project A from calling the Cloud Storage API and downloading an object out of a bucket in Project B, as long as the calling identity has IAM permission. Google APIs are reached through public endpoints (or Private Google Access endpoints), not through the peer VPC. The network layer never sees that call as cross-project traffic, because from the VPC fabric perspective it is just a workload reaching out to storage.googleapis.com.
That means the answer "use separate VPCs" is correct when the question is really about network reachability, lateral movement between VMs, or keeping subnets apart. It is the wrong answer when the question is about a service account, leaked credentials, or someone with valid IAM pulling data out of BigQuery or Cloud Storage.
VPC Service Controls work at a completely different layer. Instead of isolating networks, you draw a perimeter around one or more projects, and you list which Google managed services are protected by that perimeter. Inside the perimeter you can list BigQuery, Cloud Storage, Dataflow, Pub/Sub, Dataproc, and so on.
Once that perimeter is in place, any API call into a protected service from outside the perimeter is denied, even if the caller has valid IAM permissions. That last part is the whole point. IAM answers the question "is this identity allowed to do this action." VPC Service Controls answer a different question, which is "is this call coming from an allowed location." Both have to say yes for the call to succeed.
That is why VPC Service Controls are the data exfiltration answer. If a service account key leaks, or if an insider with legitimate BigQuery access tries to copy a dataset to a personal project, the perimeter blocks the call at the service layer. The Cloud Storage API itself refuses to return the object. The BigQuery API refuses to run the export. The call never makes it through, regardless of what IAM says.
Perimeters are not all-or-nothing. You configure ingress rules to say "this specific identity, calling from this specific source, is allowed into this protected service." You configure egress rules to say "this workload inside the perimeter is allowed to call this protected service in a project outside the perimeter." That is how you let a Dataflow job inside the perimeter read from an approved upstream bucket without dropping the wall entirely.
Perimeter bridges are a separate mechanism. A bridge lets projects in two different perimeters share specific resources without merging the perimeters themselves. You use a bridge when two regulated environments need to exchange a known set of data and you do not want to flatten them into one perimeter.
On the Professional Data Engineer exam, when a question mentions "allow this one job to read from this one project but otherwise stay inside the perimeter," you are looking at ingress or egress rules. When the question mentions two perimeters that need a controlled handoff, you are looking at a perimeter bridge.
The pattern I use when I read a scenario is to ask what is actually being prevented. If the answer is "VMs in one project should not be able to send packets to VMs in another project," that is the network layer, and separate VPCs (with no peering or routing) are enough. If the answer is "a workload with valid credentials should still not be able to pull a BigQuery dataset or a Cloud Storage object out of this project," that is the service layer, and VPC Service Controls are the right pick.
The exam writers know these two answers look interchangeable, so they tend to put both in the choices. Reading the scenario for the words exfiltration, credentials, IAM, service account, or API access is usually the giveaway that the question is about VPC Service Controls and not about network isolation.
My Professional Data Engineer course covers VPC Service Controls perimeters, ingress and egress rules, perimeter bridges, and the network-versus-service-layer framing in detail, with the exam-style scenarios that hinge on this exact distinction.
