Google ACE Practice Question: A GKE cluster hosts both a public-facing web…

A GKE cluster hosts both a public-facing web application and an internal data processing service. The data processing service should only accept traffic from the web application Pods, not from the internet. Which Kubernetes feature enforces this policy?

⚠ Common exam trap

Google Cloud often tests the misconception that a ClusterIP Service is inherently private and restricts access to only certain Pods, but in reality, ClusterIP only limits external exposure; any Pod in the cluster can reach it unless a NetworkPolicy explicitly denies or allows traffic based on labels.

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

✓

Kubernetes NetworkPolicy restricting ingress to the data service to only Pods with the web app label

Kubernetes NetworkPolicy is the native Kubernetes resource that controls traffic flow at the IP address or port level (OSI layer 3 or 4). By defining an ingress rule that allows traffic only from Pods with a specific label (e.g., 'app: web-app'), you can restrict access to the data processing service exclusively to the web application Pods, regardless of whether the service is exposed via ClusterIP, NodePort, or LoadBalancer. This is the correct and recommended approach for pod-level network segmentation within a cluster.

Answer analysis

Option-by-option breakdown

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

✗
A VPC firewall rule blocking external traffic to the data service's Node IPs
Why it's wrong here
A VPC firewall rule that blocks external traffic to the data service's Node IPs is ineffective because it filters at the Compute Engine network layer, which knows only the node's IP address, not individual Pod IPs. It cannot inspect Pod labels, and it does not affect east-west traffic between Pods inside the cluster, so the data service remains reachable from any Pod on any node.
✓
Kubernetes NetworkPolicy restricting ingress to the data service to only Pods with the web app label
Why this is correct
A Kubernetes NetworkPolicy with an ingress rule that selects Pods carrying the web app label provides exactly the required Pod-level isolation, filtering traffic at the source and destination Pod regardless of node placement. Because the policy's podSelector matches only those web app Pods, all other Pods are denied by default, and GKE enforces this via its network policy engine (e.g., Dataplane V2 or Calico), making it the correct solution.
✗
IAP (Identity-Aware Proxy) configured on the data service
Why it's wrong here
Identity-Aware Proxy (IAP) controls access by authenticating external users and enforcing identity-based authorization in front of a load balancer or service; it is not designed for filtering traffic between Pods inside a GKE cluster. Pod-to-Pod communication bypasses IAP entirely, and IAP does not evaluate Kubernetes Pod labels or IP addresses, so it could never enforce a policy that only the web application's Pods can reach the data service.
✗
Using a private ClusterIP Service for the data service — it's automatically private
Why it's wrong here
A private ClusterIP Service exposes the data service on a stable cluster-internal IP, but that IP is automatically reachable from every Pod in the cluster; the Service does not examine the source Pod's labels or authenticate the caller. It only load-balances to the backend Pods, so any workload can call the data service's ClusterIP unless a NetworkPolicy is explicitly added to restrict traffic.

Go deeper

Google ACE Practice Question: A GKE cluster hosts both a public-facing web…

Why each option matters

Option-by-option breakdown

Related to this question