An ops lead asks whether adopting serverless means the city has no security responsibility. What is the correct fundamentals distinction?
Select an answer to reveal the explanation.
Short Explanation
Handing off the kitchen does not mean the recipe can be reckless. The provider locks the building and maintains the stoves; the city still owns whether the chat-bot code and citizen data are handled safely. Serverless is not a “no security” free pass.
Full Explanation
Adopting serverless does not erase the city’s security duty. The provider secures the underlying platform and hosts; the customer remains responsible for securing application code, configuration, identities, and data. Shared responsibility still applies—serverless changes which layer you patch, not whether citizen data and app logic must be protected.
Claiming serverless removes shared responsibility so the city never secures code or data is a dangerous myth. Saying Azure refuses to secure the platform so the city must patch every host OS reverses platform versus customer roles. Asserting serverless automatically makes all application code publicly readable with no controls invents a default that is not part of the model.
Exam caveat: the exact split of duties can differ slightly by service, but AZ-900’s consistent message is that moving up the abstraction stack never means the customer owns nothing—code and data remain on the customer side of the ledger.
Operational check: for each serverless app (chat-bot, webhook, upload handler), list customer controls in the security review—identity permissions, secret storage, input validation, encryption, and logging—so ops leads see a concrete residual responsibility list rather than a blank Azure handles security assumption.