On a managed database service, which threats stay on your side of the shared-responsibility line?
answer
- who prevents it, not who stores it
- schema and queries stay yours
- same threat list, different owner column
- the control plane is a second entry point
- responsibility transfers, accountability does not
basics
~20 sThe provider owns the host, the patching, the storage and the backup machinery; you own the schema, the credentials and every access rule. A cross-tenant read caused by a missing tenant filter is your threat, not theirs.
solid answer
~50 sOn the diagram the managed relational database appears as a data store with a boundary between your application and the platform the provider operates. Below that line sit host and engine patching, hypervisor and physical access, storage media, and the backup and failover mechanism. Above it sit everything you express: the schema, the queries, credential issuance and rotation, and which principal may read which rows. So a co-tenant of your application reading another customer's rows through a missing tenant predicate is information disclosure entirely on your side, even though the bytes physically live on the provider's disk - the location of the data never decides ownership of the threat. Two consequences follow. Threats below the line do not vanish from the model; they stay enumerated with the mitigation owned by someone you cannot audit directly. And the service adds a boundary you did not have before: the provider's management or control-plane path into that same store, usually with credentials far stronger than your application's.
go deeper
Know that a managed service splits duties: the provider runs the host, patching and backups, while your schema, queries and credentials remain yours. Be able to place one example task on the right side.
Explain the split precisely and defend a hard case - a cross-tenant read through a missing tenant predicate is yours because the flaw and the fix are in code you own, not because of where the bytes sit.
Demonstrate that you keep inherited threats in the model rather than deleting them, and that you draw the administrative control plane as its own crossing with stronger privilege than the application path.
Own the tradeoff: what your organisation gains by inheriting a provider's controls, what dependency that creates, and how you keep a named owner for every threat that now sits below the line.
## The line is a trust boundary like any other When part of your system is run by someone else, the split of duties between you and them is a trust boundary on the diagram, and it obeys the same rule as every other boundary: it goes where **trust and privilege change**, not where the network or the invoice changes. The provider operates a platform; you operate what you built on it. Drawing that line is not paperwork - it is what turns *we use a managed service* into a specific list of threats you must mitigate yourself. Take a managed relational database service behind a multi-tenant application. **Below the line - the provider's side** - Patching the database engine and the host operating system. - Hypervisor and physical access to the machine; disposal of failed media. - The storage layer, at-rest encryption machinery, and the backup and restore mechanism. - Availability of the engine within whatever service level is offered. **Above the line - your side** - The schema, including whether a tenant identifier exists on every row that needs one. - Every query, and therefore whether the tenant predicate is present on each read and write. - Credentials: who gets a database user, how it is scoped, how it rotates, where it is stored. - Which application principal may reach which data, and what your application puts in the tables in the first place. - Configuration you own even though the provider offers it: public network exposure, which identities can connect, whether backups are shared out. ## The exercise that separates candidates Give someone a cross-tenant read - tenant B's rows returned to tenant A because a WHERE clause lost its tenant predicate - and ask which side of the line it lands on. The weak answer reaches for physical location: *the data is on their storage, so it involves them*. The correct answer is that the flaw, the vulnerability and the control all live in code and schema you own; the provider faithfully executed the query you sent. Ownership of a threat follows **who can prevent it**, not who holds the disk. Run the mirror case too. Say a defect in the engine allows one database instance to read another's pages. You cannot write a control for that. It is still enumerated in your model, marked as inherited: the mitigation belongs to the provider, and what remains yours is *blast-radius* work - minimising what you store, holding keys for the most sensitive fields yourself where that is feasible, and choosing an isolation model that limits what a single failure exposes. ## Using a managed service does not shrink the enumeration This is the most useful thing to say in an interview. Moving a component to a managed service changes the **owner of the mitigation column**, not the **length of the threat list**. Spoofing of the data store, tampering with rows, disclosure of the whole table, denial of service, and an unattributable administrative change are all still on the list. Some now carry the note *mitigated by the provider*, which is a real and usually good trade: they patch faster than you do. But the model that quietly deletes those rows produces a diagram that looks safer than the system is, and it has no record of what you are depending on when a provider incident lands. And the trade is not free of new threats. Adopting a managed service adds: - **A control plane.** There is now an administrative API that can resize, snapshot, restore, replicate or delete your database, reachable with credentials that are usually more powerful than the application's database user. That is a second entry point into the same data store, drawn as its own flow crossing its own boundary, and it deserves its own enumeration - most obviously elevation of privilege and tampering, plus repudiation if administrative actions are not attributable to a named human. - **A support and operations path.** Provider staff have some defined ability to operate the platform. That is another principal with access, and it belongs on the diagram rather than in the small print. - **Configuration surface.** The most common real-world failure here is not an exotic escape but a setting you owned and left open. ## Responsibility moves; accountability does not You can transfer the *work* of a control to a provider. You cannot transfer being the party who answers for the data to your customers. Model accordingly: a threat whose mitigation sits below the line still needs an owner on your side who watches for it, knows the failure signature, and has a plan for the day the provider announces something. In practice that means the inherited items get named in the model with a dependency noted, not silently dropped. ## How to draw it Draw the managed component as a normal data store, then run a boundary through the diagram separating your operated elements from the provider-operated platform, and let the flows cross it explicitly. Two flows will usually cross: the application's data path, and the administrative or control-plane path. Enumerate on each crossing separately - they carry different principals, different privileges and different threats, and the administrative one is the one teams forget.
- A defect lets one database instance read another's pages. Is that out of scope for your model?No - it stays enumerated as an inherited threat whose mitigation is owned elsewhere. What is in your control is blast radius: store less, keep the most sensitive fields under keys you hold, and pick an isolation model that limits what one failure exposes. Deleting the row from the model just hides a dependency you still carry.
- Does moving a component to a managed service reduce the number of threats you enumerate?It reduces the number you mitigate yourself, not the number you enumerate. The same categories still apply to the data store; some entries simply change owner in the mitigation column. It also adds threats - the administrative control plane and the provider's operations path are new entry points that did not exist when you ran the engine.
- Where does the provider's control plane belong on the diagram?As its own flow into the same data store, crossing its own boundary, because it carries a different principal and much stronger privilege than the application's database user. It can snapshot, restore, replicate or destroy. Enumerate it separately: elevation of privilege and tampering first, and repudiation if administrative actions are not attributable to a named person.
- How do you decide whether an isolation model is your problem or the provider's?Ask which side could implement the fix. Isolation you express - a tenant column, a per-tenant schema, a per-tenant database you provision - is yours to enforce and test. Isolation between the provider's own customers is theirs. The word isolation appearing on both sides of the line is exactly why the line has to be drawn before you argue about it.
saying these in an interview costs you the question
- Assigns a threat by where the data physically sits
- Deletes provider-owned threats from the model instead of marking them inherited
- Says a managed service means fewer threats to enumerate
- Forgets the administrative control plane as a second entry point
- Believes buying a service transfers accountability for the data