
Private networking questions show up on the Professional Data Engineer exam in a pretty predictable way. You get a scenario with a Cloud Function, a Cloud Composer environment in a private subnet, a Dataflow job pulling from BigQuery, or a third-party API, and you have to pick the right way to keep traffic off the public internet. The two answers that come up over and over are Private Google Access and Private Service Connect. They sound similar, and people mix them up, but on the exam they are not interchangeable.
Here is how I keep them straight when I am working a Professional Data Engineer question, and how I decide which one a scenario is actually asking for.
Private Google Access is a setting you flip on at the subnet level. Once it is enabled, any VM or managed resource in that subnet that only has an internal IP can reach Google APIs and services. That means BigQuery, Cloud Storage, Pub/Sub, the whole catalog of *.googleapis.com endpoints become reachable from a private workload without giving it a public IP.
The defining traits to remember for the exam:
Private Google Access fits the boring, common case. A Dataproc cluster on internal IPs needs to read from Cloud Storage and write to BigQuery. A private Compute Engine VM running an ingestion script needs to publish to Pub/Sub. Flip on Private Google Access for the subnet and the workload is done.
Private Service Connect works differently. Instead of a subnet-wide flag, you create a Private Service Connect endpoint inside your VPC. That endpoint is an internal IP address that you assign, and it maps to a specific producer service on the other side. The producer can be a Google service like Cloud SQL or Cloud Composer, a managed service in another organization, or even a third-party API that has been exposed as a PSC producer.
What that gives you:
The classic Professional Data Engineer scenario for PSC is the one where a Cloud Function needs to trigger an Airflow DAG in a Cloud Composer environment that lives in a private subnet with no internet access. The Cloud Function is not even in your VPC. Private Google Access cannot help here, because the Function is not the one reaching out to a Google API in the normal sense. You stand up a PSC endpoint in the VPC that fronts Cloud Composer, and the Cloud Function calls the Airflow REST API through that endpoint.
When I read a Professional Data Engineer scenario, I ask three questions in order:
A quick wrong-answer filter that helps. If a question gives you a multi-tenant or partner connectivity setup and one of the options is Private Google Access, that option is wrong. Private Google Access does not cross organization boundaries and does not give you a service-specific endpoint. Conversely, if the scenario is a single project doing internal-only data work against Google APIs and one option is Private Service Connect, PSC is usually overkill compared to the simpler PGA answer.
Private Google Access has a couple of variants worth recognizing by name. Private Google Access for on-premises hosts uses a restricted or private VIP and lets your on-prem network reach Google APIs over a Cloud Interconnect or VPN. There is also the older Private Service Access pattern for some managed services. The exam will not usually trip you up on naming, but if you see private.googleapis.com or restricted.googleapis.com in an answer choice, that is the PGA family.
My Professional Data Engineer course covers Private Service Connect and Private Google Access in the networking module, including the Cloud Function to Cloud Composer scenario and how to spot which of the two a question is really asking about so you do not lose easy points on private networking on exam day.