# Design a key management service like AWS KMS: system design interview question

> A security service with tenant isolation, key rotation, cryptographic operations, and durable access records.

Source: https://sysround.com/questions/design-key-management-service-like-aws-kms
Updated: 2026-11-05


Difficulty: hard. Levels: Senior, Staff+.

## How the interviewer opens it

"Design a managed key service that lets tenants create encryption keys and perform cryptographic operations without exposing those keys. The service must support key rotation and an audit record of access."

## What to clarify first

- Cryptographic operations
- Scale
- Traffic and read:write mix
- Latency and availability
- Security boundary
- Consistency and access changes
- Rotation
- Key lifetime and durability
- Audit requirements
- Product boundaries

## Scope of a strong answer

Core requirements:

- Create and manage encryption keys for each tenant.
- Encrypt and decrypt small payloads without exposing service keys.
- Rotate keys while preserving access to earlier ciphertext.
- Enforce access policies and retain durable audit records.

Usually out of scope:

- Build an identity provider or cryptographic hardware.
- Encrypt large files directly.
- Support asymmetric keys, signatures, or imported keys.
- Support multiple regions or regional disaster recovery.

## What interviewers probe

### Key protection and request volume

The service must protect key material while it serves high request volume. Hardware capacity and recovery rules constrain the design.

### Tenant access

Tenants share the service, but each key has separate permissions. Stale permission decisions can violate the required access guarantees.

### Key rotation and old ciphertext

Rotation changes future encryption without breaking old ciphertext. Partial failures can leave metadata and cryptographic material in different states.

### Audit completeness

A cryptographic operation and its audit record use separate components. A crash can leave an uncertain result or a missing record.

## Common mistakes

- Confuses service key secrecy with a ban on returning decrypted client data.
- Assumes a key identifier grants access to the key.
- Uses stale permissions after a successful policy change.
- Deletes old key versions during routine rotation.
- Ignores hardware capacity, nonce safety, or root key recovery.
- Returns a cryptographic result before durable audit capture.

## The bar by level

- **Senior:** Defines atomic version activation and management retry behavior. Handles permission revocation, nonce safety, audit failure, and one zone failure. Estimates hardware and audit capacity.
- **Staff+:** Defines the threat model and residual risks. Explains uncertain audit outcomes and hardware recovery. Tests deletion guarantees across backups. Quantifies capacity under failure and states where security requires rejection.

Practice this question with an AI interviewer: https://sysround.com/practice/new?problem=key-management-service


---
SysRound (https://sysround.com) is an AI practice tool for system design interviews. It has a voice or typed AI interviewer and a shared whiteboard. At the end, you get feedback on each skill and a model answer. The AI feedback can be wrong.