A library chatbot will run as serverless functions. Which security implication should the architect highlight?
Select an answer to reveal the explanation.
Short Explanation
Serverless means you are not babysitting VMs—but you are babysitting who the function can call and which packages it pulls. Less OS patching, more IAM and dependency discipline. It is not a free pass on identity.
Full Explanation
Serverless functions for a library chatbot reduce the traditional operating-system and patch-management surface because the cloud provider operates the underlying execution environment. Architects must still design identity and permissions carefully: each function's role should follow least privilege for data stores, APIs, and secrets it may invoke. Dependency and supply-chain risk also rise in relative importance—package libraries, layers, and third-party SDKs become primary code you inherit. Security+ positions serverless as a shift of concern from host hardening toward IAM, secrets, API authorization, and software composition, not as elimination of security work.
Saying serverless removes all identity and permission concerns because there is no OS to patch conflates host patching with authorization design; over-privileged function roles remain a top cloud failure mode. Claiming serverless never uses third-party dependencies so supply-chain risk disappears is false—most functions pull packages extensively. Requiring the municipal SOC to perform full hypervisor management misunderstands the shared-responsibility split for FaaS; the provider manages the hypervisor layer.
Exam caveat: serverless items reward "less OS patching, more IAM/deps," not "no security left." Operationally, scope function roles narrowly, store secrets in a managed vault rather than environment plaintext, pin and scan dependencies, enable function logging and tracing into the SIEM, and review which triggers (HTTP, queues, schedules) can invoke the chatbot path without unintended public exposure.