As a workload moves from a rented machine to a fully managed capability, which security duties never transfer to the provider?

## The line is a layer, not a service A useful way to hold the model is as a stack, drawn once and then cut at different heights. From the bottom: facility and physical access, hardware and firmware, the virtualization layer, the host operating system, the runtime or engine, the application, and finally the configuration, the identities and the data. The provider owns from the bottom up to a cut; you own from the cut up. **Every tier on the ladder is the same stack with the cut in a different place.** ## Where the cut sits per tier | layer | rented machine | managed runtime | whole managed capability | |---|---|---|---| | facility, hardware, firmware | provider | provider | provider | | virtualization layer | provider | provider | provider | | host operating system | tenant | provider | provider | | runtime or engine | tenant | provider | provider | | application code and its dependencies | tenant | tenant | provider | | configuration exposed to you | tenant | tenant | tenant | | identities and grants | tenant | tenant | tenant | | the data itself | tenant | tenant | tenant | Read the table downward and the pattern is obvious: the provider's column grows from the bottom, one layer at a time, and stops at the same three rows every time. ## The three rows that do not move 1. **The data.** The provider stores it and, on most tiers, encrypts it at rest by default. Neither of those is a statement about what the data *is*. Classifying it, deciding what may be collected, deciding how long it is retained and when it is deleted — those are tenant decisions on every tier, including the highest one. 2. **The identities and grants.** The provider supplies the mechanism that decides who may reach the service; which principals actually hold that grant is yours. A provider cannot know that a grant is too broad, because from its side a valid request from a valid principal is indistinguishable from a correct one. 3. **The configuration you were given control of.** This is the row that trips people. On a high tier the configurable surface can be genuinely small — a handful of toggles — but those toggles are typically the ones that decide whether the service is reachable from outside, whether an object is public, and how long deleted data is recoverable. ## What the tier does change The honest claim is not that a managed tier gives you nothing. It removes whole classes of work and whole classes of failure: no unpatched guest system, no forgotten agent, no capacity event at 3 a.m. It also usually supplies mechanisms you would otherwise build — encryption at rest turned on by default, a backup mechanism that runs without you. But note what "supplies the mechanism" does and does not mean. A backup mechanism the provider runs is not a retention policy: how far back you can go, whether you have ever tested a restore, and whether a mistaken deletion is recoverable are tenant decisions the provider cannot make for you. A standby replica is a different thing again — it protects against a failure domain and copies a deletion faithfully, so it is not a substitute for retained backups. ## The claim to state carefully It is tempting to say the tenant's configuration duty "never changes". It does change — it shrinks, sometimes dramatically, and on a whole managed capability it may be a short list. What is accurate is that **it never reaches zero while you hold data and accounts in the system**, and that the residual list is disproportionately made of the settings that cause exposures. Saying "it shrinks but never empties" is both true and more useful in an interview than an absolute. ## How to answer it Draw the stack, say which cut each tier makes, and then name the three rows above every cut. If you want one sentence to land on: a higher tier buys you a smaller surface to get wrong, not permission to stop looking at it.