DVA-C02 Security Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Store customer-managed keys on an HSM in your data center.

  Why it's wrong here

  AWS KMS is a managed service that securely stores and manages cryptographic keys internally within AWS's own HSM infrastructure. Customer-managed keys (CMKs) never leave the AWS KMS service boundary and cannot be exported to or stored on an HSM in your data center. If you need on-premises key generation or storage, you would use a separate service like AWS CloudHSM or an on-premises HSM solution, not AWS KMS. Therefore, storing customer-managed keys on an on-premises HSM is not a capability of AWS KMS.

• ✓

  Generate data keys for envelope encryption.

  Why this is correct

  Envelope encryption is a core pattern supported by AWS KMS through the GenerateDataKey API, which returns a plaintext data key and a copy of that key encrypted under a CMK. You use the plaintext data key locally to encrypt your actual data (which can be of any size), then apply best practices by deleting the plaintext key and storing only the encrypted data key alongside the ciphertext. Later, to decrypt, you call Decrypt with the encrypted data key to retrieve the plaintext key. This is the recommended approach for encrypting large payloads because the KMS Encrypt API is limited to 4 KB per request, whereas envelope encryption has no practical size limit.

• ✗

  Hash data using a keyed hash function.

  Why it's wrong here

  AWS KMS is designed to perform supported cryptographic operations such as encryption, decryption, signing, verification, and key generation. It does not offer hashing functions, including keyed hash functions like HMAC, because hashing is a one-way operation and is not an encryption mechanism. KMS's HSM hardware does not expose a raw hashing API to customers; you would compute HMACs locally using a key sourced from KMS, but KMS itself never performs the hash. Thus, using KMS to hash data is not an available operation and is not a valid method for encrypting data with KMS.

• ✓

  Encrypt data using a customer master key.

  Why this is correct

  The Encrypt API in AWS KMS lets you encrypt small amounts of data (up to 4 KB) directly under a customer master key (CMK). This operation is useful for protecting secrets, database passwords, or even the data keys used in envelope encryption, and it returns ciphertext that can only be decrypted with the same CMK. The CMK can be AWS managed or customer managed, and all encryption happens inside KMS's HSM, so the plaintext data never leaves the service during the operation. While this is a valid way to encrypt data with KMS, its 4 KB size limit makes it impractical for large files, which is why GenerateDataKey is often preferred for larger workloads.

• ✗

  Generate SSL/TLS certificates for a domain.

  Why it's wrong here

  SSL/TLS certificates are x.509 certificates that bind a public key to a domain name and are typically issued, renewed, and managed by a certificate authority. In AWS, this functionality is provided by AWS Certificate Manager (ACM), which integrates with services like CloudFront and Application Load Balancers to handle certificate lifecycle automatically. AWS KMS, in contrast, is a key management and cryptographic service for symmetric and asymmetric keys used for encryption and signing, not a certificate authority. KMS may generate the private key that backs a certificate, but the certificate itself is not issued from KMS. Therefore, generating SSL/TLS certificates for a domain is outside the scope of AWS KMS.