A developer packages a Python Lambda function whose dependencies, including a large machine learning library and its native binaries, total around 900 MB once unzipped. The deployment must be a single artifact that Lambda can run directly. The developer wants the simplest packaging option that supports this artifact size. Which deployment package format should the developer use?
- AUpload the function as a .zip archive directly through the Lambda console, since direct uploads accept artifacts of this unzipped size without extra steps.
- BStore the .zip archive in an S3 bucket and point Lambda at the object, because the S3 path raises the unzipped limit high enough for this dependency set.
- CBuild the function as a container image, push it to Amazon ECR, and create the function from that image, because image packages support far larger artifacts. Correct
- DSplit the dependencies across five Lambda layers so each stays small, then attach all five layers to the function to assemble the full library at runtime.
Why A is wrong: A direct console .zip upload is capped at fifty megabytes zipped, and the unzipped code and dependency limit for zip packages is far below nine hundred megabytes, so this artifact cannot be deployed that way.
Why B is wrong: Loading the zip from S3 raises the upload size but the unzipped code and layers still cannot exceed two hundred and fifty megabytes, so a nine hundred megabyte payload remains over the zip format limit.
Why C is correct: Lambda container images support sizes up to ten gigabytes, comfortably holding a nine hundred megabyte dependency set, and Lambda runs the image directly as a single deployment artifact.
Why D is wrong: Layers share the same two hundred and fifty megabyte unzipped ceiling that the function plus all attached layers must fit within, so splitting the library across layers does not raise the total budget.