Your multi-tenant analytics platform stores all tenants in shared tables with a `tenant_id` column. What is the risk and how do you close it?

What the interviewer is testing

Whether you recognise that a discriminator column is one missing predicate away from a cross-tenant breach, and whether you can enforce it structurally.

The risk

Every query must include WHERE tenant_id = ?. The correctness of that depends on every developer, every analyst, every report and every ad hoc notebook getting it right, every time — including in a hurriedly written query during an incident.

It fails eventually, and the failure is a cross-tenant data exposure with contractual and regulatory consequence, typically discovered late because a query returning too much data produces no error.

The related failure: a join that filters one table by tenant and not another, which is much easier to get wrong than a single-table query.

Closing it

Enforce in the platform, not in the query. Row-level security policies attached to the table, so the predicate is applied regardless of how the data is accessed — BI tool, notebook, API, direct SQL. The tenant identity comes from the session's authenticated context, not from a parameter the caller supplies.

Or per-tenant views as the only granted access path, with the base tables not readable.

Either way, no principal has unfiltered access to the base table except a small, audited set of platform roles.

The performance consideration

Align the security predicate with the physical partitioning or clustering on tenant_id, so the policy prunes rather than scanning and filtering. A correctly secured platform that is slow will generate pressure to bypass the security layer.

When to go further

For tenants with contractual isolation requirements, or where a breach would be existential, separate storage — a schema, database or account per tenant — is the boundary that can be explained to an auditor. The cost is that cross-tenant analytics becomes a project rather than a query.

What a strong answer adds

Testing it: an automated test that authenticates as tenant A and attempts to read tenant B's data through every access path, run continuously. That is the control that proves the policy works rather than assuming it.

Common weak answers

Code review as the control. Relying on an application layer that not every access path goes through.