Google ACE Practice Question: A team builds a GKE application that processes…

Answer analysis

Option-by-option breakdown

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

• ✓

  GCP automatically encrypts all VM-to-VM traffic in transit within its network

  Why this is correct

  Google automatically applies encryption to all VM-to-VM traffic in transit within its network using the cryptographic capabilities built into Google's physical network infrastructure. This includes traffic between GKE nodes in the same cluster or across clusters, whether they are in the same zone or different regions. No configuration or key management is required from the customer, and this protection is independent of application-level protocols like TLS.

• ✗

  GKE node traffic is unencrypted by default — mTLS must be manually configured on every Pod

  Why it's wrong here

  GKE node traffic within Google's network is not unencrypted by default: Google encrypts VM-to-VM packets at the network layer before they leave the host, regardless of workload configuration. mTLS is a mesh-level policy in Anthos Service Mesh, not something you must configure on every individual Pod; it adds workload identity and application-layer encryption, but disabling it would not expose GKE traffic on the wire. Thus, the premise that nodes send plaintext across Google's backbone is incorrect.

• ✗

  Enable VPC Flow Logs — they activate encryption for logged traffic

  Why it's wrong here

  VPC Flow Logs sample and record connection metadata—source/destination IPs, ports, protocols, and packet counts—for monitoring, audit, and network analysis. They do not inspect or modify packet payloads, so enabling them cannot activate encryption for logged traffic. GCP's network-layer encryption already protects VM-to-VM traffic; flow logs are a telemetry feature, not a cryptographic control.

• ✗

  Install a TLS termination proxy on each GKE node — it encrypts intranode traffic

  Why it's wrong here

  Deploying a TLS termination proxy on each GKE node would decrypt inbound TLS traffic and forward plaintext to Pods, which is an application-layer pattern primarily for handling external ingress or service mesh scenarios. It does not encrypt intranode traffic—traffic between Pods on the same node—and it cannot add network-layer protection that Google already provides between VMs. Introducing node-level proxies adds operational overhead and breaks end-to-end encryption, because the proxy becomes the TLS endpoint and internal traffic would then be unencrypted unless re-encrypted.

Go deeper

Related to this question