A regulated bank migrates HSM-backed keys to AWS KMS. Policy requires the bank to generate key bytes on-premises, control rotation timing, and prove deletion by expiring material, while another workload allows AWS to fully manage randomness and rotation. Which key-origin design correctly reflects the difference between imported and AWS-generated key material?

The correct design uses imported key material with expiration and manual rotation for bank keys and AWS-generated material with automatic rotation for the managed workload because import preserves on-premises HSM randomness under KMS enforcement, manual reimport enforces bank-controlled timing, and expiration disables material after ValidTo to prove deletion without deleting the KMS key, while AWS origin lets KMS generate randomness in its HSM boundary and support fully managed rotation. The no-expiration import approach fails verifiable deletion because without ValidTo removal relies on administrative action and audit assertion rather than time-enforced unusability. The dual-manual-rotation approach fails workload fit because manual rotation of AWS-origin keys is valid but rejects the allowed automated yearly rotation and retains avoidable burden. The auto-rotated import approach fails service behavior because KMS does not support automatic rotation for imported or custom-store material and requires reimport before expiration. As an exam caveat, material deletion is not key or alias deletion, and CloudHSM or Secrets Manager does not change KMS origin properties. As a practical check, verify DescribeKey shows EXTERNAL with ExpirationModel and ValidTo for bank keys and AWS_KMS with RotationEnabled for the managed key.