A 311 rewrite uses microservices, containers, and serverless functions with APIs left wide open between services. Which security concern should architects address first among those patterns?
Select an answer to reveal the explanation.
Short Explanation
Microservices without API locks are a building full of unlocked suite doors. Give each service its own badge, shrink permissions, harden the images, and stop leaving master keys in the function pockets.
Full Explanation
A 311 rewrite using microservices, containers, and serverless with APIs left wide open between services recreates implicit trust inside a distributed system: any compromised component can call others freely. Architects should first enforce service identity, least-privilege API authorization, hardened/scanned images, and function permission boundaries so components authenticate to each other, receive only required scopes, and do not carry standing cloud-admin secrets. Assuming containers never need image scanning because orchestration looks modern ignores known vulnerable base layers and supply-chain risk. Disabling authentication on every internal API for permanent developer velocity institutionalizes lateral movement. Storing long-lived cloud admin keys inside each serverless function creates portable superuser credentials in every deployment artifact. Exam caveat: cloud-native patterns still require zero-trust style service auth and least privilege; “internal network” is not an authorization model. Operational check: require mTLS or signed service tokens between 311 services, replace open APIs with scoped authorizers, scan and sign container images in CI, bind serverless roles to minimal actions, purge embedded admin keys, and penetration-test east-west calls from a single compromised service account.