You rent a virtual machine and separately use a managed database service — who applies operating-system security patches in each case?
answer
- the boundary is not at a fixed layer
- it depends on what you actually rented
- rented machine: guest system upward is yours
- managed engine: provider owns host and binaries
- data, accounts and configuration never move down
basics
~20 sOn a rented virtual machine you patch the guest operating system and everything above it. On a managed database service the provider patches the host and the engine, while the data, the accounts and the configuration inside it stay yours.
solid answer
~50 sThe provider always owns the facility, the hardware and the virtualization layer. What differs is where above that its duty stops. On a **rented virtual machine** the provider hands you a guest operating system and stops: its packages, its kernel updates, the agents and libraries you installed, and the service you deployed are all yours. A published machine image is current only at the moment it is published; it does not update itself underneath a running machine. On a **managed database service** the provider also owns the host operating system — you cannot log into it — and the engine binaries, including their security fixes. Your remaining duties are real but narrower: choosing, inside the window the provider offers, when an offered version upgrade lands, testing your application against it, and owning the accounts, the grants and the data inside the engine.
go deeper
Recall that the answer differs by purchase: a rented machine leaves the guest operating system to you, a managed database service does not. Be able to say what the provider owns in both cases: facility, hardware, virtualization.
Explain why a published machine image goes stale under a running machine, and what remains yours on the managed tier — the upgrade window, the regression testing, and the accounts and data inside the engine.
Show you have operated both: a fleet whose images drifted a year behind, and a managed upgrade that had to be scheduled, tested and rolled through environments before the provider's deadline arrived.
Frame it as a standard: which tiers your organisation permits, how patch duty is assigned and evidenced per tier, and what you accept in exchange for giving up host access on the managed side.
## The model in one sentence A cloud provider operates and secures everything up to a boundary it publishes; the tenant secures everything above it. The important part is that **the boundary is not at a fixed layer** — it sits wherever the thing you rented stops. "Who patches the operating system?" is the cheapest probe an interviewer has, because the honest answer flips between two purchases that look equally like "using the cloud". ## A rented virtual machine Renting a virtual machine buys compute capacity and nothing above it. The provider owns: - the building, its power, cooling and physical access control; - the physical servers, their firmware, and the storage hardware underneath; - the virtualization layer that carves a physical machine into the one you were handed; - the network fabric between machines. Everything from the **guest operating system** upward is yours: - the guest's packages and kernel, including their security updates; - the agents, libraries and dependencies you installed on it; - the service you deployed and its configuration; - the local accounts and whatever filtering you attached to the machine. The subtlety worth stating out loud: a provider publishes machine images, and an image is current **at the moment it is published**. It does not update itself under a running machine. Launch from it, leave the machine up for a year, and the packages inside it are a year old. Closing that gap — patching in place, or rebuilding from a newer image and replacing the machine — is a tenant duty, and renting rather than owning the hardware changes nothing about it. ## A managed database service Buying the same engine as a managed service moves the boundary up two layers. The provider now also owns the host operating system, which you have no login to, and the engine binaries themselves, including the security fixes in them. It also owns the mechanics of applying an update: draining connections, restarting, and failing over to a standby replica where the tier has one. | duty | provider | tenant | |---|---|---| | facility, hardware, firmware | yes | no | | virtualization layer | yes | no | | host operating system packages | yes | no | | engine binaries and their security fixes | yes | no | | when an offered upgrade lands | no | yes, inside the offered window | | testing the application against the new version | no | yes | | accounts and grants inside the engine | no | yes | | what data goes in, and how long it is kept | no | yes | So "the provider patches it" is true and incomplete. The provider **installs** the fix; the tenant still owns the scheduling decision within whatever window is offered, the regression risk, and everything the engine is holding. Providers differ here: some let a tenant defer an upgrade indefinitely, others force it after a published deadline, so the safe phrasing is "inside the window the provider offers" rather than "whenever you like". ## What the flip actually teaches The two cases share one rule: the tenant owns **its own data, the identities it grants inside the system, and the configuration it was given control of**. Those never move down to the provider, on any tier. What moves is the operational floor beneath them. This is also why "managed" and "secured" are different words. A managed tier removes a class of work — you are no longer the one who notices a package advisory and reboots a host at midnight. It does not remove the tenant's security duties; it shrinks the surface they apply to and leaves the highest-value ones, the data and the access to it, exactly where they were. ## How to answer it in an interview 1. Name the invariant first: the provider owns the facility, the hardware and the virtualization layer in both cases. 2. Say where the boundary sits for each purchase — at the guest operating system for a rented machine, above the engine for a managed service. 3. Give one consequence per case: a stale image under a long-running machine, and an upgrade window plus regression testing on the managed engine. 4. Close with what did not move: the data, the accounts and the configuration. A candidate who answers only "the provider does it, it's managed" has described a purchase, not a responsibility model — and that is precisely the assumption that leaves an unpatched guest system running for a year because everyone believed it was somebody else's.
- The provider schedules a security patch for your managed engine inside a maintenance window — what is still your job?Choosing the window so the restart lands where it hurts least, testing the application against the new version before it is applied more widely, and making sure clients reconnect cleanly across the brief interruption. The install is the provider's; the blast radius inside your application is yours.
- Who patches the operating system underneath a managed runtime that executes your code?The provider does — you have no host to log into. Your duty moves up to what you ship into that runtime: your own code and the dependencies bundled with it. The provider patches what it installed, not what you deployed on top of it.
A landlord maintains the roof, the wiring and the building's entry system; whether your own door is locked, and what you keep behind it, is still your problem.
saying these in an interview costs you the question
- Thinks the provider patches the guest operating system on a rented machine
- Assumes a managed tier needs no patching work from the tenant at all
- Believes a published machine image keeps updating itself under a running machine
- Never reads the provider's responsibility documentation and guesses the line
- Confuses patching the engine with updating the application's own dependencies