Jeff’s Note #
Unlike generic exam dumps, ADH analyzes this scenario through the lens of a Real-World Lead Developer.
For DVA-C02 candidates, the confusion often lies in how to reliably share files between multiple Lambda functions while supporting file appends. In production, this is about knowing exactly which AWS storage options support concurrent access and file append semantics in Lambda running inside a VPC. Let’s drill down.
The Certification Drill (Simulated Question) #
Scenario #
Your startup, DataSense Labs, is building a serverless analytics pipeline. An AWS Lambda function runs inside a VPC and triggers each time a new file is uploaded to an S3 bucket. This Lambda function processes the file and produces two outputs:
- An analytics result file
- A log file capturing a line entry for each processed object
These files must be shared and accessible by other Lambda functions, AWS services, and on-premises systems. Additionally, each new log entry must be appended to the existing shared log file.
The Requirement: #
You need a solution that enables your Lambda to share files, supports safe append operations to an existing log file, and works seamlessly with Lambda in VPC mode.
The Options #
-
A) Create an Amazon Elastic File System (Amazon EFS) file system. Mount the EFS file system in Lambda. Store the result files and log file in the mount point. Append the log entries to the log file.
-
B) Create an Amazon Elastic Block Store (Amazon EBS) Multi-Attach enabled volume. Attach the EBS volume to all Lambda functions. Update the Lambda function code to download the log file, append the log entries, and upload the modified log file to Amazon EBS.
-
C) Create a reference to the
/tmplocal directory. Store the result files and log file by using the directory reference. Append the log entry to the log file. -
D) Create a reference to the
/optstorage directory. Store the result files and log file by using the directory reference. Append the log entry to the log file.
Google adsense #
leave a comment:
Correct Answer #
A
Quick Insight: The Developer Imperative #
Lambda functions running inside a VPC have no outbound internet by default and ephemeral local storage (
/tmp) is isolated per function instance—not shared. EBS volumes cannot be attached to multiple Lambda functions concurrently. Amazon EFS is the only fully managed, shared, network file system that Lambda functions in VPC can mount concurrently to read/write and safely append to files. Understanding these storage service constraints is key for building robust serverless shared file solutions.
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 #
Amazon EFS is a fully managed NFS file system allowing multiple clients— including Lambda functions running inside a VPC—to mount the same file system concurrently. This concurrency enables safer appends and updates to files like shared logs and result files without the complexity and risks of copying local files around. The persistence and high durability of EFS also supports durable storage accessible across Lambda invocations and other AWS resources.
- Lambda supports mounting EFS file systems directly.
- EFS supports file append operations natively.
- EFS scales automatically, removing administration overhead.
- Lambda functions in a VPC can securely access EFS through VPC mount targets.
The Trap (Distractor Analysis): #
-
Option B (EBS Multi-Attach): EBS Multi-Attach is designed for EC2 instances, not Lambda functions. Lambda does not support attaching EBS volumes at runtime, and the data access model would require complex downloads/uploads each invocation—not recommended or supported.
-
Option C (/tmp local directory): The Lambda
/tmpdirectory is local to each function instance and not shared across concurrent invocations or functions. Files here cannot be accessed or appended from other Lambda functions or services. -
Option D (/opt storage directory): The
/optdirectory is read-only and intended for deployment packages or layers. It cannot be used for persistent file storage or appending dynamic data.
The Technical Blueprint #
# Mount an EFS file system into Lambda's /mnt/efs and append a log entry example in Python:
import os
LOG_FILE_PATH = '/mnt/efs/shared-log.txt'
def lambda_handler(event, context):
log_entry = "Processed file at {}\n".format(event['Records'][0]['s3']['object']['key'])
# Append safely to the shared log file on EFS
with open(LOG_FILE_PATH, 'a') as log_file:
log_file.write(log_entry)
# Additional processing and file writes to EFS...
return {'statusCode': 200}
The Comparative Analysis #
| Option | API Complexity | Performance | Use Case |
|---|---|---|---|
| A | Low - native EFS mount & POSIX FS calls | High - shared, low latency | Shared file access & append for Lambda in VPC |
| B | Very High - Not supported for Lambda directly | Poor - requires download/upload | Intended for EC2 use only |
| C | Low - local filesystem | Low - isolated per instance | Temporary local storage, no sharing |
| D | N/A - read-only | N/A - cannot write | Deployment package contents only |
Real-World Application (Practitioner Insight) #
Exam Rule #
For the exam, always pick Amazon EFS when you need shared, persistent file storage with concurrency and append support for Lambda in a VPC.
Real World #
In actual projects, you might weigh EFS costs and latency against alternatives like S3 for append-light logs or DynamoDB for log metadata, but for true shared file append access, EFS is the robust answer.
(CTA) Stop Guessing, Start Mastering #
Disclaimer
This is a study note based on simulated scenarios for the AWS DVA-C02 exam.