In a multi-tenant SaaS, would you use one data encryption key for all tenants or one per tenant? Justify.

What the interviewer is testing

Whether you can connect key granularity to blast radius and to erasure, rather than treating encryption as a compliance checkbox.

The case for per-tenant keys

Blast radius. A compromised data key exposes exactly the data it encrypted. One key for all tenants means one compromise exposes everything; per-tenant keys bound the exposure to one customer.

Crypto-shredding. Destroying a tenant's key makes their ciphertext permanently unreadable, which is how erasure is implemented in immutable stores, backups and archives that cannot be edited. This is frequently the deciding argument, because contractual deletion obligations on offboarding are otherwise very hard to satisfy across backups.

Customer-managed keys. Enterprise customers increasingly require the ability to hold or revoke their own key, which is impossible with a shared key. This is a commercial capability as much as a security one.

Auditability. Key usage per tenant is visible in the key service's audit log, which gives a data access signal independent of the application.

The costs

More key management operations, and an unwrap call per tenant rather than one — mitigated by caching unwrapped data keys briefly for high-throughput paths.

Key lifecycle complexity: creation on tenant provisioning, rotation, and destruction on offboarding, each of which must be reliable.

And a genuine hazard: losing a tenant's key destroys their data irrecoverably. Key backup and recovery must be as robust as data backup, and the recovery path must be tested.

The recommendation

Per tenant, with envelope encryption: a data key per tenant, wrapped by a master key in the key management service. The blast radius and erasure arguments dominate, and the operational cost is manageable with caching.

For very high tenant counts, per-tenant keys with a hierarchical structure keep the key count tractable.

What a strong answer adds

Extending the reasoning: within a tenant, a separate key for particularly sensitive data categories allows different retention and access policies to be enforced cryptographically. And noting that the master key never leaves the hardware boundary, which is what makes the whole scheme defensible to an assessor.

Common weak answers

One key for simplicity, without addressing erasure. Per-record keys, which is unmanageable at scale.