Google ACE Practice Question: A developer needs to forward traffic from their…

Answer analysis

Option-by-option breakdown

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

• ✗

  kubectl expose pod postgres-pod --type=LoadBalancer --port=5432

  Why it's wrong here

  This creates a Service of type LoadBalancer, which provisions a cloud load balancer with a public external IP, making the database reachable from the internet. That violates the requirement for private, local-only access for the developer, and also changes the network topology in the cluster. It does not establish a direct tunnel from the developer's machine; it instead creates a lasting Service resource. The intended behavior is a temporary, private forwarding path, which only port-forward provides.

• ✓

  kubectl port-forward svc/postgres-service 5432:5432

  Why this is correct

  This is the correct command because `kubectl port-forward` creates a direct, temporary tunnel from the developer's localhost port 5432 to the postgres Service's port 5432 inside the cluster. It does not expose the Service externally, does not create any Service or Ingress resource, and the bind is to localhost by default, so only the developer's machine can reach it. This matches the requirement for a secure, private way to connect to the database without altering the cluster's networking. The command is also the standard way to debug or access a private Kubernetes resource from a workstation.

• ✗

  kubectl tunnel --local=5432 --remote=postgres-service:5432

  Why it's wrong here

  The kubectl CLI has no `tunnel` subcommand; this is a fabricated command. The correct native command for forwarding local ports to a cluster resource is `kubectl port-forward`, which takes the form `kubectl port-forward RESOURCE LOCAL_PORT:REMOTE_PORT`. Even if a hypothetical tunnel command existed, the syntax with `--local` and `--remote` flags does not match kubectl's actual port-forward flag conventions. Therefore this option is invalid and would fail immediately.

• ✗

  gcloud container ssh postgres-pod --port-forward=5432:5432

  Why it's wrong here

  `gcloud container ssh` is not a valid gcloud command for accessing a GKE pod; the correct gcloud command for SSH to a node is `gcloud compute ssh`, and even that does not support a `--port-forward` flag. Port forwarding into a pod is handled by kubectl, not by gcloud, because it requires the Kubernetes API to establish the tunnel. This command would either fail as unrecognized or, if SSHing to a node, would not forward the container port. The proper tool is `kubectl port-forward svc/postgres-service 5432:5432`.

Go deeper

Related to this question