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 how to securely encrypt transient local storage in Lambda without native volume encryption support. In production, this is about knowing exactly how to integrate AWS KMS data keys securely while managing ephemeral data within Lambda’s constrained /tmp storage. Let’s drill down.
The Certification Drill (Simulated Question) #
Scenario #
DyneHealth Inc., a healthcare startup, is building a highly secure, serverless application on AWS Lambda to process sensitive patient data. The application temporarily writes intermediate sensitive data to the Lambda function’s local /tmp directory for performance reasons before sending it upstream for permanent storage. Due to compliance requirements, all data written to /tmp must be encrypted at rest. DyneHealth’s developers need to ensure the encryption/decryption process is secure while maintaining low latency and minimizing external dependencies.
The Requirement: #
How should DyneHealth’s developers encrypt the temporary data written to the Lambda function’s /tmp storage?
The Options #
- A) Enable Amazon EBS volume encryption with an AWS KMS key in the Lambda function configuration so that all storage attached to the Lambda function is encrypted.
- B) Set up the Lambda function with a role and key policy to access an AWS KMS key. Use the key to generate a data key used to encrypt all data prior to writing to
/tmpstorage. - C) Use OpenSSL to generate a symmetric encryption key on Lambda startup. Use this key to encrypt the data prior to writing to
/tmp. - D) Use an on-premises hardware security module (HSM) to generate keys, where the Lambda function requests a data key from the HSM and uses that to encrypt data on all requests to the function.
Google adsense #
leave a comment:
Correct Answer #
B
Quick Insight: The Developer Imperative #
Using AWS KMS to generate a data key that the Lambda function encrypts locally ensures secure, auditable key management without external hardware dependencies. Lambda’s
/tmpstorage is ephemeral and unencrypted by default; there is no EBS volume attached, so volume-level encryption is not an option (A is invalid). Generating keys locally without KMS (C) breaks security best practices, while relying on on-prem HSMs (D) adds unnecessary latency and complexity.
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 B
The Winning Logic #
AWS Lambda does not provide encrypted ephemeral /tmp storage out-of-the-box; no EBS volumes are involved, so option A is not applicable. The best practice is to use the AWS KMS GenerateDataKey API to generate a unique symmetric data key inside the function execution environment. You then use the plaintext data key to encrypt data locally before writing to /tmp. The ciphertext of the data key is stored to re-decrypt later when needed—this approach leverages KMS’s secure key storage and audit capabilities while enabling low-latency local encryption.
- Option C, generating keys locally with OpenSSL, lacks the key lifecycle management and audit trail provided by KMS.
- Option D, requesting keys from an on-prem HSM, introduces latency, network complexity, and is operationally burdensome for Lambda’s ephemeral context.
The Trap (Distractor Analysis): #
- Why not A? Lambda’s ephemeral storage is not backed by EBS volumes, so enabling EBS volume encryption is irrelevant to
/tmp. - Why not C? Too risky from a security compliance perspective—managing keys locally inside ephemeral functions undermines KMS advantages.
- Why not D? Adds high latency and external dependencies that decrease reliability and increase attack surface.
The Technical Blueprint #
# Extract an AWS KMS data key using AWS SDK for Node.js inside Lambda
const AWS = require('aws-sdk');
const kms = new AWS.KMS();
async function getDataKey() {
const params = { KeyId: 'alias/my-kms-key', KeySpec: 'AES_256' };
const data = await kms.generateDataKey(params).promise();
// data.Plaintext = Buffer with plaintext key to encrypt data
// data.CiphertextBlob = Buffer with encrypted data key to store securely
return data;
}
The Comparative Analysis (Developer Lens) #
| Option | API Complexity | Performance | Use Case |
|---|---|---|---|
| A | Invalid (no EBS vol) | No benefit | Misapplied EBS encryption |
| B | Moderate (KMS calls) | Low latency/local enc | Best practice for secure local encryption |
| C | Low (local key gen) | Low latency | Insecure key management |
| D | High (network I/O) | High latency | Overcomplicated for serverless |
Real-World Application (Practitioner Insight) #
Exam Rule #
“For the exam, always pick GenerateDataKey when you see Lambda with local /tmp encryption requirements.”
Real World #
“In real-world builds, teams lean heavily on KMS data keys for ephemeral Lambda encryption to meet compliance without sacrificing performance. Local key generation almost always gets flagged by auditors.”
(CTA) Stop Guessing, Start Mastering #
Disclaimer
This is a study note based on simulated scenarios for the AWS DVA-C02 exam.