A fintech tenant must never read or write another tenant’s rows. Show the effective-role threat model across GRANT, RLS, table ownership, referential integrity, and SECURITY DEFINER functions.
Row-level security is enabled, therefore tenants are isolated is the answer this question exists to catch. Row filtering governs ordinary row access for roles that are subject to it, which is a narrower promise than most people hear. Several identities skip it entirely, one common function pattern silently changes which identity is in force, and a couple of table-level privileges are not row-filtered at all. Interviewers on regulated products want to hear you reason about the effective role, meaning whoever is actually executing at the moment the row is touched, rather than the role the application believes it is using. This page covers building that matrix, the two policy directions, and the leak paths that survive a correct policy.
What the interviewer is scoring
Weak answer: “RLS is enabled, so isolation is complete,” grants tenant roles TRUNCATE or REFERENCES, or runs a definer function as the table owner.
In short: RLS protects normal row access, not every table operation. Test the effective identity, both policy paths, bypass roles, non-RLS privileges, and constraint-error channels.
The spoken answer and the reasoning behind it
- The full 90-second answer, written first person, the way you would actually say it
- How I reason through it: the mechanism, the decision points, and where the claim stops
- Verification steps with a written summary of what a controlled lab run showed, labelled as a summary rather than a transcript.
- Worked responses to the 3 follow-up probes listed above, plus the traps that lose the point
Card required. Cancel before day 7 and you are not charged.
How to reason through it
- Grant only required table and column operations; enable RLS and confirm default deny when no applicable policy exists.
- Test USING for existing rows and WITH CHECK for inserted or updated rows; reason about how permissive and restrictive policies combine.
- Build an effective-role matrix for application, report, function owner, table owner, superuser, and bypass roles; forcing RLS binds the owner, not superusers or bypass roles.
- Deny tenant roles TRUNCATE and REFERENCES; test referential-integrity bypass and row-existence leakage through constraint errors.
- Prefer SECURITY INVOKER; where a definer function is necessary, own it with a dedicated non-owner, non-bypass role holding only required grants.
- Fix the function search path to trusted schemas, revoke the default public execute privilege, grant execution narrowly, and test each role in a separate session.
What I would verify
- Check the effective identity at the moment the row is touched, not the role the application connected as.
- Test both policy directions: reading an existing row, and writing one that must not be creatable.
- Confirm default deny by querying with RLS enabled and no applicable policy present.
- Attempt the documented bypass paths deliberately: as owner, as a bypass role, and through a definer function.
- Probe whether a constraint error reveals the existence of another tenant's row.
Follow-ups they push on
- Forcing row security is on. Is the owner now subject to policies?
- How can a tenant learn about a row they cannot read?
- You need a definer function. How do you make it safe?
The probes are open. Pro carries the spoken answer, the reasoning behind it, and the verification steps, including a worked response to each of these.
Concepts tested
Learn it, run it, then say it
Three steps, in order. Nothing here is a detour.
1 · Learn the mechanism
Understand it before you try to say it.
2 · Practise it for real
Run it once so the answer describes something you have seen.
3 · Rehearse the next question
Keep going while the mechanism is fresh.
Questions that go with this one
- senior · ProA customer says “the database is down.” In five minutes, how do you separate a broken connection path, connection saturation, wrong-node routing, lock waits, and a query-specific failure—and what do you communicate before you know root cause?Where tenant boundaries reappear as blast radius under time pressure.
- staff · ProStart with the highest-severity issue you've personally owned, the one that pushed your limits.If your worst incident involved data reaching the wrong tenant, that story lands here.