SY0-701 Question 160
Single answerMicroservicesA company is modernizing its customer portal by breaking a monolithic application into microservices deployed in containers. Each microservice needs to communicate with several others over the network, and developers currently authenticate these connections using long-lived shared API keys stored in configuration files. During a security review, the team identifies a high risk of lateral movement if one container is compromised. Which of the following changes would BEST reduce this risk while supporting secure service-to-service communication in the microservices environment?
- A
Implement mutual TLS between services and issue short-lived service identities through a centralized identity or certificate management system
- B
Place all microservices on the same isolated VLAN and continue using shared API keys because the internal network is trusted
- C
Encrypt only the external user traffic to the portal and leave internal microservice traffic unencrypted to reduce latency
- D
Store the shared API keys in environment variables instead of configuration files so the keys are no longer exposed
Show answer and explanation
Correct answer: A
Explanation
The best answer is to implement mutual TLS with centrally managed, short-lived identities for each service. In microservices environments, the main security challenge is controlling east-west traffic and limiting the blast radius of a compromise. Shared long-lived API keys are weak because they are difficult to rotate, can be reused across services, and provide poor identity assurance. By contrast, mTLS ensures each service proves its identity cryptographically while also encrypting traffic in transit. This approach supports zero trust architecture by avoiding implicit trust based on network location alone. Best practices from sources such as NIST's zero trust guidance and common cloud-native security recommendations emphasize strong service identity, least privilege, credential rotation, and protecting internal service communications rather than trusting the internal network.
- A. Correct.
Correct. In a microservices architecture, mutual TLS (mTLS) provides both encryption in transit and strong authentication between services. Using unique, short-lived service identities or certificates reduces the impact of credential theft and helps prevent unauthorized east-west traffic if one container is compromised. This aligns with zero trust principles and common best practices for service-to-service communication in distributed environments.
- B. Incorrect.
Incorrect. Network segmentation can help reduce exposure, but simply trusting the internal network and continuing to use long-lived shared API keys does not adequately address identity, authentication, or credential reuse. If one service is compromised, shared secrets can still enable lateral movement across the environment.
- C. Incorrect.
Incorrect. Protecting only north-south traffic is insufficient in microservices environments, where east-west traffic between services is extensive and often carries sensitive data. Leaving internal traffic unencrypted and unauthenticated creates opportunities for interception, impersonation, and unauthorized access.
- D. Incorrect.
Incorrect. Moving shared API keys from configuration files to environment variables may slightly change how secrets are stored, but it does not solve the core issue of long-lived shared credentials. Attackers who compromise a container can often access environment variables, and the shared-key model still allows broad reuse across services.