The 311 application is redesigned as microservices. Which security implication is most important for the new architecture?
Select an answer to reveal the explanation.
Short Explanation
Chopping the app into many services creates more hallways between rooms—each hallway needs a badge check. East-west calls need authz, not blind trust. Treating internal traffic as automatically safe is how small cracks become big incidents.
Full Explanation
Redesigning the 311 application as microservices multiplies internal service-to-service (east-west) communication and therefore multiplies trust boundaries inside what used to be a single process. Each API call between services needs authentication and authorization—mutual TLS, service identities, tokens, or mesh policies—so a compromised frontend or low-privilege component cannot freely invoke sensitive backends. Network controls still matter, but Security+ emphasizes that microservices security is not only perimeter thinking; zero-trust style service identity becomes essential as the blast radius of anonymous internal calls grows.
Claiming microservices eliminate network controls because isolation is automatic overstates platform guarantees; misconfigured meshes, shared networks, and overly open service accounts remain common. Restricting security only to the public web tier while leaving internal calls anonymous ignores lateral movement after any edge foothold. Forcing all municipal apps onto a single shared database account for "simplicity" collapses least privilege across services and turns one credential into an enterprise-wide key.
Exam caveat: microservices questions often hinge on east-west authentication needs, not on "internal equals trusted." Operationally, inventory service dependencies, issue unique identities per service, deny anonymous internal HTTP, log authorization failures between services, and segment sensitive data stores so only the owning microservice identity can reach them.