A developer needs to implement a custom machine learning (ML) library in an application. The size of the library is 15 GB. The size of the library is increasing. The application uses AWS Lambda…

Question

Options

• ASave the library in Lambda layers. Attach the layers to all Lambda functions.
• BSave the library in Amazon S3. Download the library from Amazon S3 inside the Lambda
• CSave the library as a Lambda container image. Redeploy the Lambda functions with the new
• DSave the library in an Amazon Elastic File System (Amazon EFS) file system. Mount the EFS file

• B
  5% (1)
• C
  10% (2)
• D
  85% (17)

Explanation

Option D is correct because Amazon EFS can be mounted directly to Lambda functions, supports files far larger than Lambda's limits, and scales automatically as the library grows - making it ideal for a large, expanding 15 GB ML library shared across all functions.

Why the distractors fail:

• A (Lambda Layers): Layers have a hard 250 MB unzipped size limit per function, which is far too small for a 15 GB library.
• B (S3 download): Downloading 15 GB on every Lambda invocation would be extremely slow, costly, and would exceed Lambda's 512 MB–10 GB ephemeral /tmp storage limit for most configurations - plus it adds significant cold-start latency.
• C (Container image): Lambda container images support up to 10 GB, still under the 15 GB requirement, and the library would need to be rebaked into a new image every time it grows - not a scalable solution.

Memory tip: Think of EFS as a shared network drive for Lambda - when your dependency is too big to package and needs to be shared across many functions simultaneously, EFS is the go-to. The pattern is: "Big + Shared + Growing = EFS."

No community discussion yet for this question.