SY0-701 Question 159
Single answerMicroservicesA company is modernizing its customer portal by breaking a monolithic application into microservices. Each service runs in containers and communicates with other internal services over APIs. During a security review, the team discovers that developers embedded long-lived database and API credentials directly in container images so the services can authenticate to each other automatically after deployment. The security architect needs a solution that reduces credential exposure, supports frequent service scaling, and aligns with least privilege. Which of the following is the BEST approach?
- A
Store shared credentials in the container image but obfuscate them and rotate the images monthly
- B
Use a centralized secrets management solution and issue unique short-lived credentials or tokens to each microservice at runtime
- C
Place all microservices on an isolated VLAN so embedded credentials cannot be intercepted on the network
- D
Replace API-based communication with direct database connections so fewer credentials are needed
Show answer and explanation
Correct answer: B
Explanation
The best answer is to use a centralized secrets management approach that provides unique, short-lived credentials or tokens to microservices at runtime. In microservices environments, hardcoded or embedded secrets are a common security weakness because container images are widely distributed, reused, and often stored in registries and CI/CD pipelines. Best practices from organizations such as NIST and guidance from major container security references emphasize avoiding hardcoded secrets, enforcing least privilege, rotating secrets regularly, and using identity-based access where possible. Runtime secret injection, short-lived credentials, and per-service identities reduce the likelihood that one compromised service or image exposes all backend systems. This approach also scales better operationally than rebuilding images every time a secret changes.
- A. Incorrect.
This is incorrect because obfuscation is not a security control for protecting secrets. If credentials are embedded in container images, anyone with access to the image registry, build pipeline, or running container may be able to recover them. Monthly rotation is also too infrequent for a dynamic microservices environment and does not address least privilege or secret sprawl.
- B. Correct.
This is correct because centralized secrets management is a recommended practice for containerized and microservices-based environments. Issuing unique, short-lived credentials or tokens at runtime reduces the risk associated with credential leakage, supports autoscaling, and enables fine-grained access control per service. This also aligns with least privilege by allowing each microservice to receive only the permissions it needs rather than sharing static credentials.
- C. Incorrect.
This is incorrect because network isolation can reduce exposure to some attacks, but it does not solve the core problem of hardcoded secrets in images. Attackers or insiders with access to containers, images, logs, CI/CD systems, or orchestration platforms could still obtain the embedded credentials. VLANs are helpful as a compensating control but are not the best primary solution here.
- D. Incorrect.
This is incorrect because replacing service-to-service APIs with direct database access usually increases risk and weakens segmentation. It can bypass intended application-layer controls, expand the blast radius of a compromised service, and violate least privilege by giving multiple services broader access to backend data stores. In microservices architectures, each service should generally authenticate securely using managed identities, tokens, or secrets rather than sharing backend database access unnecessarily.