A payment processor must meet a regulator requiring payment keys be generated in its on-premises HSM, usable in AWS KMS for EBS and S3 encryption, automatically expiring yearly, with immediate revocation on demand. Cloud-only keys are rejected. Which imported key material design satisfies regulatory control and revocation?

The correct design meets all constraints because external-origin import keeps the on-premises HSM as the root of trust while still letting KMS issue data keys for native EBS and S3 encryption, imported expiration enforces the yearly lifetime, importing new key material (on-demand rotation) or reimporting before expiry handles renewal without creating cloud-native material, and deletion of key material provides immediate revocation. The import-plus-automatic-rotation design fails on lifecycle mechanics because KMS automatic rotation does not apply to imported key material, so enabling it creates false yearly renewal while the material remains valid past expiry or breaks without proper reimport. The CloudHSM-generated import design fails on provenance because it replicates expiration and deletion correctly but substitutes a VPC-hosted cloud HSM for the mandated on-premises HSM, which the regulator explicitly rejects despite strong security. The on-premises-only envelope-encryption design fails on integration because keeping keys outside KMS and encrypting in application code preserves custody but cannot satisfy KMS-mediated EBS and S3 protection and adds audit complexity. Exam caveat is to distinguish ExpireOn plus reimport from automatic rotation, because automatic rotation is not supported for imported key material, so renewal is a manual import. Practical check is to describe the key for external origin and expiration and rehearse deletion and reimport in staging to prove fail-closed revocation.