To prove integrity (and authenticity) of data in transit, the correct cryptographic primitive is a digital signature. AWS KMS supports signing and verification operations using asymmetric KMS keys designed for signing (for example, RSA_SIGN_PSS, RSA_SIGN_PKCS1, or ECC_NIST_P256 key specs). The developer signs the data (or more commonly, a hash of the data) using the private key, and the external recipient verifies the signature using the corresponding public key. If the data is modified in transit, signature verification fails, proving the content was changed.
Option C exactly describes this model: sign with the private key, share the public key. The private key remains protected (ideally never leaving KMS). The public key can be distributed safely because it cannot be used to forge signatures.
Option A (encryption) provides confidentiality, not integrity proof to a third party, and sharing a symmetric encryption key is insecure and breaks key management principles.
Option B is incorrect because symmetric keys do not provide non-repudiation and generally require the verifier to possess the same secret key, which would allow the verifier to forge signatures too. While HMAC can validate integrity between trusted parties, it does not meet the typical “prove integrity” requirement to an external party without sharing a secret.
Option D is backward and insecure: you never share a private key.
Therefore, use an asymmetric KMS signing key to sign with the private key and provide the public key for verification.
