AWS DVA-C02 Drill: Lambda Data Access - Managing Shared Libraries & Reference Data

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 which persistence mechanism best suits Lambda’s ephemeral compute environment and multi-team ownership. In production, this is about knowing exactly how Lambda integrates with scalable, shared file systems like EFS to support code and data modularity without packaging complexity. Let’s drill down.

The Certification Drill (Simulated Question)

#

Scenario

#

A software team at Quantum Analytics develops AWS Lambda functions that require access to the company’s internally developed data processing libraries and a set of frequently updated reference datasets. Different organizational groups manage the code libraries and the reference datasets independently. The Lambda functions operate inside Quantum Analytics’ centralized VPC. The solution must allow both teams to continue updating their respective assets without requiring Lambda developers to repackage or redeploy functions.

The Requirement:

#

Which architecture should be used to enable the Lambda functions to access the internal libraries and reference data while supporting independent updates by different teams?

The Options

#

• A) Attach an Amazon Elastic Block Store (Amazon EBS) volume to the Lambda functions by using EBS Multi-Attach in the central VPC. Update the Lambda function execution roles to grant access to the EBS volume. Modify the Lambda code to reference the files on the EBS volume.
• B) Compress the libraries and reference data into the Lambda /tmp folder at runtime. Modify the Lambda code to reference the files from the /tmp directory.
• C) Configure an Amazon Elastic File System (Amazon EFS) with mount targets in the central VPC. Configure the Lambda functions to mount the EFS file system. Update the Lambda execution roles to allow access to the EFS file system.
• D) Set up an Amazon FSx for Windows File Server file system with mount targets in the central VPC. Configure the Lambda functions to mount the FSx file system. Update execution roles accordingly.

Google adsense

#

leave a comment:

Correct Answer

#

C

Quick Insight: The Developer Imperative

#

• Lambdas have ephemeral storage and no direct native support for EBS connections. EFS is the only scalable, multi-client, shared file system natively supported by Lambda for persistent storage within a VPC.
• This enables independent updates to the shared libraries or datasets without packaging overhead or redeployment.
• FSx is Windows-based, adding unnecessary complexity unless Windows-specific features are needed.
• /tmp is ephemeral and limited to 512MB, unsuitable for large or changing datasets managed independently.

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

#

Amazon EFS provides a fully managed, elastic NFS file system that can be mounted concurrently by multiple Lambda functions operating inside a VPC. This allows separate teams to update shared libraries and reference data independently without requiring changes to Lambda deployment packages. The Lambda execution role is granted permissions to access the EFS mount target. This model fits well with Lambda’s stateless nature and ephemeral containers by providing persistent, shared storage accessible at runtime.

The Trap (Distractor Analysis):

#

• Why not A?
  EBS volumes cannot be directly attached to Lambda functions. Multi-Attach works only for EC2 instances; Lambda lacks the capability to mount EBS volumes. This is a conceptual mismatch in the Lambda execution model.

• Why not B?
  Using the Lambda /tmp directory requires bundling the data and decompressing it during invocation, which is inefficient and limited to 512MB. This also forces redeployment to update content, violating the requirement for independent updates by separate teams.

• Why not D?
  Amazon FSx for Windows File Server is a robust file storage option but is optimized for Windows workloads and SMB protocol. It is rarely used with Lambda, which favors NFS mounts via EFS. Also, FSx increases operational complexity and cost without clear justification here.

The Technical Blueprint

#

# Example IAM policy snippet to allow Lambda to access EFS
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "elasticfilesystem:ClientMount",
        "elasticfilesystem:ClientWrite",
        "elasticfilesystem:ClientRootAccess"
      ],
      "Effect": "Allow",
      "Resource": "arn:aws:elasticfilesystem:region:account-id:file-system/fs-12345678"
    }
  ]
}

# Example Lambda function snippet to mount EFS via VPC config (in Lambda console or CloudFormation)
# Note: Mount path typically /mnt/efs

The Comparative Analysis

#

Real-World Application (Practitioner Insight)

#

Exam Rule

#

For the exam, always pick Amazon EFS when you see Lambda functions needing shared, persistent, and frequently updated code/data accessible by multiple teams.

Real World

#

In real-world projects, we prefer EFS because it decouples code deployment from data management. Teams can update libraries or datasets independently without triggering Lambda redeployments, reducing risk and improving agility.

(CTA) Stop Guessing, Start Mastering

#

Disclaimer

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