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

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.”

The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.

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

The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.

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 ask about

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 (L5/E5): 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 (L6+/E6+): 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.

Sources · 2 references

These records explain where the question appears. A company tag or candidate report does not guarantee a future interview question.

PracHub · 1 record

Google
Design key management service
Reported Sep 6, 2025
Software Engineer
Source snapshot: Nov 12, 2026

SysRound · 1 record

No company association
Design a key management service like AWS KMS
Reported date not specified
Source snapshot: Nov 12, 2026
View source

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.”

The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.

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

The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.

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 ask about

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 (L5/E5)

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 (L6+/E6+)

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.