A regulated bank generates AES-256 keys in its on-premises HSM and requires that AWS never persist the plaintext key material, that the bank retains exclusive control of rotation, and that KMS-encrypted EBS volumes remain usable. Which key management design should the engineer select to manage imported and external key material?
Select an answer to reveal the explanation.
Short Explanation
You're told AWS must never hold the key — that's the giveaway. Externalization keeps material in your HSM while KMS proxies every use.
Full Explanation
The correct approach uses a KMS external key store where KMS never stores the key material and each encrypt or decrypt request is proxied through the bank-operated XKS proxy (TLS with SigV4-signed requests) to the bank-owned external key manager backed by the on-premises HSM, satisfying exclusive control, no persistence and continued EBS support through KMS. Imported key material into KMS, even with expiration and reimport for rotation, still stores the key material inside KMS boundary between rotations, so it fails the never-persist requirement despite supporting customer-controlled rotation. AWS-generated KMS key material with automatic rotation keeps all material inside KMS and cedes rotation control to AWS, missing both external origin and exclusive-control facts. CloudHSM provides dedicated HSMs but EBS and most AWS services integrate with KMS key IDs rather than calling CloudHSM directly as a KMS key, so referencing a CloudHSM key ARN does not provide the required KMS integration. For the exam, distinguish BYOK import which stores material in KMS from XKS which never stores it and requires high availability of the proxy, and practically test proxy latency, disconnect behavior and CloudTrail XKS entries.