A healthcare SaaS must prepare document signing and key exchange for quantum resistance. Policy requires NIST-approved lattices for signatures and key establishment, centrally managed keys, and crypto agility without self-built libraries. Which post-quantum cryptography strategy in AWS meets both uses?

The correct strategy succeeds because ML-DSA (FIPS 204) and ML-KEM (FIPS 203) are the NIST-selected lattice standards for signatures and key establishment, AWS KMS provides centrally managed lifecycle, policy, auditing and rotation, and hybrid modes combine classical and quantum-resistant algorithms for crypto agility without custom code. The KEM-only TLS approach fails completeness because it secures session establishment but provides no long-term lattice signature for document signing, leaving half the stated dual-use requirement unmet despite correct management and agility. The SLH-DSA plus ML-KEM approach fails algorithm scope because SLH-DSA (FIPS 205) is NIST-approved stateless hash-based, not lattice-based, so it violates the explicit policy mandate for lattices for both uses even though management and agility are sound. The CloudHSM client-managed approach fails control model because CloudHSM places exclusive key custody and crypto operations in the customer-controlled HSM partition rather than KMS centralized custody and IAM policy enforcement, violating centrally managed keys and increasing operational burden despite using correct lattices for both uses. Exam caveat is to read whether the question demands lattice-only versus any NIST-approved quantum-safe primitive and whether it demands both signing and establishment versus one, since many real designs correctly use single-use or hash-based signatures. Practical check is to confirm in the KMS console and CloudTrail that key specs show lattice signing and encapsulation, key policies enforce central administration, and document and TLS workflows negotiate hybrid mechanisms with ability to rotate without redeploying application crypto code.