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 handle Lambda deployment packages exceeding the 250 MB unzipped size limit. In production, this is about knowing exactly when to use container images instead of zipped deployment packages or S3 references for Lambda functions. Let’s drill down.
The Certification Drill (Simulated Question) #
Scenario #
Acme Innovations, a tech startup specializing in real-time data processing, is developing a new serverless application using AWS Lambda. The function’s business logic relies on a set of third-party libraries and data files, with the total size of these dependencies around 500 MB. The development team needs to deploy this code to Lambda in a way that meets AWS Lambda’s packaging size constraints and supports efficient deployment and execution.
The Requirement: #
Determine the best deployment method for a Lambda function whose code and dependencies total about 500 MB in size.
The Options #
- A) Compress the application code and dependencies into a .zip file. Directly upload the .zip file as a deployment package for the Lambda function instead of copying the code.
- B) Compress the application code and dependencies into a .zip file. Upload the .zip file to an Amazon S3 bucket. Configure the Lambda function to run the code from the .zip file in the S3 bucket.
- C) Package the application code and dependencies into a container image. Upload the image to an Amazon S3 bucket. Configure the Lambda function to run the code in the image.
- D) Package the application code and dependencies into a container image. Push the image to an Amazon Elastic Container Registry (Amazon ECR) repository. Deploy the image to the Lambda function.
Google adsense #
leave a comment:
Correct Answer #
D
Quick Insight: The Developer Imperative #
For DVA-C02, understanding that Lambda deployment packages have specific size limits is essential:
- The zipped deployment package must be under 50 MB directly uploaded, or 250 MB unzipped (code + dependencies).
- For larger application bundles, container images are the scalable approach. Container images are pushed to Amazon ECR and can be up to 10 GB in size, resolving large dependency issues gracefully.
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 D
The Winning Logic #
Packaging the Lambda function code and dependencies into a container image and pushing it to Amazon Elastic Container Registry (ECR) is the best approach when your deployment artifact exceeds the Lambda zip size limits. Lambda supports container images up to 10 GB, which easily accommodates a 500 MB dependency set.
- Lambda container images use formats compatible with Docker, allowing familiar CI/CD pipelines.
- Deployment is simplified by referencing the container image in ECR when configuring the Lambda function.
- This approach supports all Lambda runtimes and allows consistent, repeatable builds with full control of the execution environment.
The Trap (Distractor Analysis) #
- Why not A? Directly uploading a compressed .zip exceeding Lambda’s 50 MB limit is impossible. Even if uploaded via the console or CLI, the unzipped size must be < 250 MB, which is violated here.
- Why not B? While uploading a zipped package to S3 and referencing it in Lambda supports larger code than a direct upload, the size limitation is still 250 MB unzipped. This won’t support a 500 MB dependency bundle.
- Why not C? Lambda cannot run container images directly from an S3 bucket. Container images must be pushed to Amazon ECR and referenced from there.
The Technical Blueprint #
# Build your Lambda container image locally:
docker build -t my-lambda-function .
# Authenticate Docker to Amazon ECR
aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin <account_id>.dkr.ecr.us-east-1.amazonaws.com
# Tag and push the image:
docker tag my-lambda-function:latest <account_id>.dkr.ecr.us-east-1.amazonaws.com/my-lambda-function:latest
docker push <account_id>.dkr.ecr.us-east-1.amazonaws.com/my-lambda-function:latest
# Create/update Lambda function to use the image:
aws lambda create-function --function-name myLargeDepFunction \
--package-type Image \
--code ImageUri=<account_id>.dkr.ecr.us-east-1.amazonaws.com/my-lambda-function:latest \
--role arn:aws:iam::123456789012:role/lambda-exec-role
The Comparative Analysis #
| Option | API Complexity | Performance | Use Case |
|---|---|---|---|
| A | Low | N/A | Not feasible for >250 MB size |
| B | Medium | Good | For code ≤250 MB uncompressed |
| C | Invalid | N/A | Lambda does not run images from S3 |
| D | Medium-High | Best | Large packages via container images up to 10 GB |
Real-World Application (Practitioner Insight) #
Exam Rule #
For the exam, always pick container image deployment via ECR when you see large Lambda code bundles >250 MB.
Real World #
In reality, container images also offer advantages in build consistency and environment control, making this the preferred approach for heavy dependencies or complex Lambda runtimes.
(CTA) Stop Guessing, Start Mastering #
Disclaimer
This is a study note based on simulated scenarios for the AWS DVA-C02 exam.