AWS DVA-C02 Drill: AWS KMS GenerateDataKey - Correct Encryption Workflow

Jeff’s Note

#

Unlike generic exam dumps, ADH analyzes this scenario through the lens of a Real-World Lead Developer.

For DVA-C02 candidates, confusion often lies in how to use the GenerateDataKey API correctly in envelope encryption workflows. In production, this is about knowing exactly which key material (plaintext vs encrypted) to save and how to combine SDK calls with your own encryption logic. Let’s drill down.

The Certification Drill (Simulated Question)

#

Scenario

#

FinServeApps is developing a secure reporting tool that retrieves confidential financial data from an external API, then generates detailed PDF reports. Each PDF can exceed 1MB in size. For compliance, every PDF file must be encrypted before saving to disk using a customer-managed AWS KMS symmetric key. When a user requests a PDF, the application must decrypt it on demand. The data retrieval and PDF formatting functions are complete. Now, the developer needs to use the AWS KMS GenerateDataKey API to safely encrypt and decrypt the PDFs.

The Requirement:

#

Implement envelope encryption by correctly using the AWS KMS GenerateDataKey to encrypt and decrypt the PDF files, leveraging the plaintext key for local encryption and securely storing the encrypted key for later decryption.

The Options

#

• A) Write the encrypted data key (returned by GenerateDataKey) to disk for later use. Use the plaintext data key (returned by GenerateDataKey) and a local symmetric encryption algorithm to encrypt the PDF file.
• B) Write the plaintext data key from GenerateDataKey to disk for later use. Use the encrypted data key and a local symmetric encryption algorithm to encrypt the PDF file.
• C) Write the encrypted data key to disk for later use. Use the plaintext data key to encrypt the file by calling the KMS Encrypt API.
• D) Write the plaintext data key to disk for later use. Use the encrypted data key to encrypt the file by calling the KMS Encrypt API.

Google adsense

#

leave a comment:

Correct Answer

#

A

Quick Insight: The Developer Imperative

#

Proper envelope encryption demands saving the encrypted data key alongside ciphertext, while using the plaintext data key only transiently in memory to encrypt/decrypt local data. Persisting plaintext keys is a security risk. Also, GenerateDataKey is designed to return both forms so you do local encryption yourself — you don’t call KMS Encrypt with the plaintext key.

Content Locked: The Expert Analysis

#

You’ve identified the answer. But do you know the implementation details that separate a Junior from a Senior?

The Expert’s Analysis

#

Correct Answer

#

Option A

The Winning Logic

#

AWS KMS’s GenerateDataKey API returns two key versions:

• Plaintext key — used immediately for encrypting your data locally using symmetric encryption (AES-256, for example).
• Encrypted key — a ciphertext blob encrypted under the KMS CMK, which you safely store alongside your encrypted data.

When decrypting, you retrieve the encrypted key from disk and call Decrypt in KMS to retrieve the plaintext key again, then use it locally to decrypt the file. This pattern is called envelope encryption.

Critically:

• You never store the plaintext key to disk (to maintain security).
• You do not call KMS Encrypt passing the plaintext data key; the local encryption uses your own crypto library and the plaintext key directly.

The Trap (Distractor Analysis):

#

• Why not B? Persisting the plaintext data key to disk endangers secret material and breaks security best practices. Also, encrypting with the encrypted key blob is invalid — it’s ciphertext and can’t be used directly for data encryption.
• Why not C? The KMS Encrypt API expects plaintext data to encrypt, not keys. You cannot encrypt file data simply by passing the plaintext key through the KMS Encrypt call. This misunderstands the purpose of GenerateDataKey.
• Why not D? Same as B and C combined — persisting plaintext keys and misusing KMSEncrypt API is incorrect.

The Technical Blueprint

#

# Pseudocode to illustrate correct GenerateDataKey workflow
response=$(aws kms generate-data-key --key-id alias/my-cmk --key-spec AES_256)
plaintext_key=$(echo "$response" | jq -r '.Plaintext' | base64 --decode)
encrypted_key=$(echo "$response" | jq -r '.CiphertextBlob')

# Encrypt the PDF locally with plaintext_key (using AES-256) - in app code
encrypt_pdf_with_key plaintext_key pdf_file.pdf encrypted_pdf_file.enc

# Store encrypted_pdf_file.enc and encrypted_key persistently

# To decrypt later
# Retrieve encrypted_key and decrypt it with KMS to get plaintext_key again
decrypted_key=$(aws kms decrypt --ciphertext-blob fileb://encrypted_key | jq -r '.Plaintext' | base64 --decode)

# Decrypt the PDF file locally with plaintext_key
decrypt_pdf_with_key decrypted_key encrypted_pdf_file.enc output.pdf

The Comparative Analysis

#

Real-World Application (Practitioner Insight)

#

Exam Rule

#

When you see GenerateDataKey, always store the encrypted data key securely and use the plaintext key only transiently in memory for local encryption.

Real World

#

In production, this means integrating KMS key management with your application’s encryption libraries to handle data confidentiality securely and efficiently without sending large files to KMS.

(CTA) Stop Guessing, Start Mastering

#

Disclaimer

This is a study note based on simulated scenarios for the DVA-C02 exam.