Google ACE Practice Question: Your organization mandates that all…

Your organization mandates that all service-to-service communication within a GKE cluster must be encrypted in transit using mutual TLS (mTLS). The team does not want to manage certificates or modify application code. Which solution meets these requirements?

⚠ Common exam trap

Google Cloud often tests the distinction between network-layer encryption (node-to-node) and application-layer mTLS (service-to-service), leading candidates to mistakenly choose node-to-node encryption as a solution for service-level mTLS requirements.

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

✓

Enable Anthos Service Mesh with mTLS policy set to STRICT mode.

Anthos Service Mesh (ASM) with mTLS set to STRICT mode enforces mutual TLS between all services in the mesh without requiring any application code changes or manual certificate management. ASM automatically injects Envoy sidecar proxies that handle certificate issuance, rotation, and encryption, meeting the requirement for encrypted service-to-service communication with mTLS.

Answer analysis

Option-by-option breakdown

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

✗
Configure Kubernetes TLS Secrets and mount them as volumes in each pod.
Why it's wrong here
Mounting Kubernetes TLS Secrets as volumes manually shifts certificate management, rotation, and loading responsibilities onto the application code. Each service would need custom logic to read the certificate, establish TLS, and verify the peer's identity — typically one-way TLS rather than mutual TLS. This approach is error-prone, does not scale across many services, and still fails to provide automatic, uniform mTLS without extensive operational overhead.
✓
Enable Anthos Service Mesh with mTLS policy set to STRICT mode.
Why this is correct
Anthos Service Mesh (ASM), built on Istio, injects an Envoy sidecar proxy into each pod. The sidecars intercept all service-to-service traffic and automatically negotiate mutual TLS (mTLS) using SPIFFE identities derived from Kubernetes service accounts. In STRICT mode, the mesh rejects any plaintext connection, ensuring every communication path is both encrypted and mutually authenticated — all without modifying application code or managing certificates manually.
✗
Use Cloud Armor to enforce TLS between services within the cluster.
Why it's wrong here
Cloud Armor is an edge security service that protects external-facing load balancers with WAF rules, DDoS mitigation, and IP allow/deny policies. It operates at the Google Cloud edge, not inside the GKE cluster, and has no visibility into pod-to-pod traffic. Therefore, it cannot enforce TLS or mTLS between services within the cluster, making it an incorrect choice for internal service communication security.
✗
Enable GKE node-to-node encryption to encrypt all traffic between nodes.
Why it's wrong here
GKE node-to-node encryption encrypts all network traffic at the host level between VM nodes using cryptographic protocols, protecting data in transit at the infrastructure layer. However, this is coarse-grained: it does not distinguish between individual services or pods, and it does not provide mutual authentication between services. Since it lacks per-service identity and intent, it cannot enforce service-level mTLS policies, so it fails to meet the requirement of encrypting traffic between specific services.

Go deeper

Google ACE Practice Question: Your organization mandates that all…

Why each option matters

Option-by-option breakdown

Related to this question