AWS DVA-C02 Drill: Client-Side Encryption - Mastering GenerateDataKey for Lambda Uploads

Jeff’s Note

#

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

For AWS DVA-C02 candidates, the confusion often lies in knowing when to leverage AWS KMS APIs for client-side encryption versus relying on server-side encryption options. In production, this is about knowing exactly how to correctly use GenerateDataKey to encrypt data locally before uploading, ensuring sensitive data never leaves your code unencrypted. Let’s drill down.

The Certification Drill (Simulated Question)

#

Scenario

#

A fintech startup called “Finexia” has a daily AWS Lambda function that generates a 3 MB JSON report containing sensitive customer financial data. The function needs to securely upload this file each day to an S3 bucket. To comply with strict regulatory requirements, the encryption must be applied before the file leaves the Lambda environment — meaning client-side encryption. The engineering lead wants to implement a solution that ensures the file is encrypted locally within the Lambda function prior to upload.

The Requirement:

#

Which implementation approach should the developer follow to correctly encrypt the file locally using AWS Key Management Service (KMS) before uploading it to the S3 bucket?

The Options

#

• A) Use the default AWS KMS key for Amazon S3 within the Lambda function code to encrypt the file.
• B) Use the S3 managed key and call the GenerateDataKey API inside the Lambda function to encrypt the file.
• C) Call the GenerateDataKey API from Lambda code, then use the returned plaintext data key to encrypt the file locally before uploading.
• D) Use a customer managed AWS KMS key for Amazon S3 directly within the Lambda function code to encrypt the file.

Google adsense

#

leave a comment:

Correct Answer

#

C

Quick Insight: The Developer’s Encryption Imperative

#

• For Developer candidates, the key is understanding that GenerateDataKey returns both a plaintext data key and an encrypted data key. You use the plaintext key locally to encrypt data, and store the encrypted key for decryption later. This is the foundation of client-side encryption.
• Options that rely solely on server-side keys for upload (A, B, D) do not encrypt the file locally and thus do not meet the requirement.

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 C

The Winning Logic

#

Option C correctly uses the KMS GenerateDataKey API in the Lambda function to retrieve both a plaintext data key and an encrypted copy of the key. The plaintext key is used locally within the Lambda function to encrypt the sensitive 3 MB JSON data before writing it to disk or memory. The encrypted data key is stored alongside the encrypted file in S3. Later, to decrypt, the encrypted key is sent back to KMS to return the plaintext key for decryption. This approach implements client-side encryption — ensuring data is protected before leaving the Lambda environment.

• From an API perspective, simply using the default KMS key or S3 managed key for server-side encryption (Options A, B) without local encrypting the data does not meet the “encrypt before upload” requirement.
• Option D referencing a customer managed key “directly in Lambda code” does not specify that the GenerateDataKey API method is used, so it misses the client-side step of obtaining the plaintext key.
• The core principle: GenerateDataKey is the API designed to enable client-side encryption workflows by giving you a data key to encrypt locally.

The Trap (Distractor Analysis):

#

• Why not A? This assumes server-side encryption handled by S3 with the default key, which happens after data upload — violating the requirement to encrypt before upload.
• Why not B? Calling GenerateDataKey is on track, but using the S3 managed key is not typical as S3 managed keys do not expose GenerateDataKey for developers; plus the option does not clarify decrypting the data locally.
• Why not D? Using a customer managed key is good practice, but the option misses explicitly calling GenerateDataKey to get the plaintext key to encrypt data before upload.

The Technical Blueprint

#

import boto3
from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes
import os

# Initialize KMS client
kms_client = boto3.client('kms')

# Generate data key from a customer managed key
response = kms_client.generate_data_key(KeyId='alias/finexia-data-key', KeySpec='AES_256')

plaintext_key = response['Plaintext']
encrypted_key = response['CiphertextBlob']

# Encrypt the JSON data locally using the plaintext key + AES-GCM (example)
iv = os.urandom(12)
encryptor = Cipher(algorithms.AES(plaintext_key), modes.GCM(iv)).encryptor()

plaintext = b'{"customer":"Jane Doe","balance":12500}'  # example payload
ciphertext = encryptor.update(plaintext) + encryptor.finalize()

tag = encryptor.tag

# Upload the encrypted file and store 'encrypted_key' with it in S3 metadata or as a separate object

The Comparative Analysis

#

Real-World Application (Practitioner Insight)

#

Exam Rule

#

For the exam, always pick GenerateDataKey client-side encryption when you see the phrase “encrypt before upload”.

Real World

#

In production, you often combine GenerateDataKey with Amazon S3 Multipart Upload for large files ensuring both encryption and efficient upload. For sensitive data, customer managed keys improve audit and access control beyond AWS-managed defaults.

(CTA) Stop Guessing, Start Mastering

#

Disclaimer

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