key management

'Yes, always' is the right default and the wrong answer. The interviewer wants the list of attackers it does nothing against.

Data keys, key-encryption keys, tenant isolation, rotation and crypto-shredding. The design is standard; the trade-offs at each level are the interview.

Most cryptographic failures are misuse of good primitives, not broken algorithms. The scored answer has a checklist that catches the common ones and a strong default to replace them.

Both keep keys out of application memory; they differ in who you must trust and what you can prove. The scored answer chooses by threat model and requirement, not by fashion.

Encryption at rest is the easy part; weights must be decrypted somewhere to be used. The scored answer controls where decryption happens, who can cause it, and how fast misuse is noticed.

The response differs sharply between a signing key and an encryption key. The scored answer contains use, rotates, revokes trust, assesses what the attacker could forge or read, and repairs what depended on it.

Issuing a certificate is easy. Knowing every certificate you issued, renewing them before they expire, and surviving the day a CA key leaks is the design.

An HSM's promise is narrow and strong: the key cannot leave in plaintext. Everything else, including who may ask the HSM to use the key, is your design.