A healthcare analytics team runs Amazon EKS with sensitive genomics traffic between pods across nodes and to RDS. Compliance requires encryption of all inter-node and pod-to-pod transit with mutual authentication, without managing certificates manually. Which inter-resource encryption design secures EKS transit traffic as required?
Select an answer to reveal the explanation.
Short Explanation
Your pods are chatting across hallways you can’t trust, so you’ll want every whisper sealed automatically. A service mesh with mutual TLS encrypts pod-to-pod traffic and authenticates both workloads without manual certificate handling, while TLS to RDS over private networking protects that database link.
Full Explanation
A service mesh with mutual TLS is the fitting design because it can automatically issue and rotate workload certificates, encrypt pod-to-pod traffic across nodes, and authenticate both communicating workloads without manual certificate handling. Pairing this with TLS to RDS over private networking protects the database connection without exposing it to the internet. KMS encryption for Kubernetes secrets protects data at rest, not live inter-resource traffic, so it does not encrypt pod communication even when TLS protects the RDS connection. WireGuard encryption via Calico protects the node-to-node underlay, but does not provide pod-level identity or mutual authentication; a compromised pod within the tunnel could still communicate without authenticated workload identity. Istio mutual TLS with manually managed certificates can encrypt and authenticate pod traffic and secure the RDS connection, but manual certificate management violates the requirement and creates expiry and rotation risks. Exam caveat: VPC isolation, Security Groups, and TLS at an edge load balancer are not substitutes for end-to-end authenticated pod encryption. In practice, verify that the mesh enforces strict mutual TLS, capture traffic to confirm it is encrypted, and test that RDS connections require valid certificates.