Two school districts share one SaaS-style deployment of a student services app. Queries must never return another tenant's student rows even if object IDs are similar. What multi-tenant data pattern should the code enforce?
Select an answer to reveal the explanation.
Short Explanation
Shared SaaS is a duplex apartment: each district gets its own locks, not a hallway dump of every student's file. Put tenantId in the key or filter and check it on every read — UUIDs alone are not walls.
Full Explanation
Two school districts sharing one SaaS-style student services deployment must enforce tenant isolation on every data access path. The code should include tenant identity in keys or query filters and reject requests that attempt to read another tenant's student rows even when object IDs look similar. Multi-tenant municipal and education SaaS patterns fail open if isolation is left to the browser or to UUID obscurity; server-side tenant predicates are the durable control.
Using a single global table scan and filtering in the browser fails because clients can skip the filter and exfiltrate other districts' rows. Relying on UUID obscurity without embedding tenant identity in access checks fails conceptually—guessable or leaked IDs cross tenants without a server check. Granting every district role DynamoDB full-table Scan fails because it removes isolation at the data plane and invites cross-tenant reads from any compromised reporting tool.
Exam caveat: tenant checks must apply to queries, batch gets, GSIs, and exports—not only the primary GetItem happy path. Operational check: attempt cross-tenant reads with a valid token for District A using District B object IDs, confirm denials, and review IAM conditions or app filters that bind tenantId on every access path.