A cloud-native application consists of dozens of microservices. Any workload on the internal cluster network can call any service's API, and services trust requests based only on the caller's source IP range. The architect wants every service-to-service call authenticated and encrypted without rewriting each service. What is the best approach?
Select an answer to reveal the explanation.
Short Explanation
Trusting a call because it comes from the right IP range is like letting anyone in who's standing in the right hallway. A service mesh gives every service its own ID badge and checks both badges on every call, with mutual TLS. If you see an answer that still trusts location or shares one secret, skip it.
Full Explanation
A service mesh places a proxy alongside each service and manages communication between them centrally. The mesh's control plane issues each workload a cryptographic identity, typically a short-lived certificate, and the proxies perform mutual TLS on every connection, so both caller and callee are authenticated and the traffic is encrypted. Authorization policies can then allow or deny calls by service identity rather than network address, and none of this requires changes to application code. Restricting traffic to one subnet with a network security group still bases trust on address; any compromised workload inside that subnet is treated as trusted, which is the weakness the scenario describes, and it adds no encryption. A single shared API key provides no per-service identity: every service presents the same secret, so a compromise of any one service exposes all of them, the key cannot express which caller may reach which API, and the header itself is not encryption. Terminating TLS at the external load balancer protects only the client-to-edge leg; traffic between services inside the cluster remains plaintext and unauthenticated after termination. Exam caveat: the mesh secures east-west traffic; it complements, not replaces, an API gateway or WAF at the north-south edge. Operational check: confirm that strict mTLS mode rejects plaintext calls, that certificates rotate automatically, and that a test call from an unauthorized service identity is denied.