A Lambda that preprocesses large GIS libraries for a parks department exceeds practical zip size and dependency constraints. Which packaging guidance should the team apply?
Select an answer to reveal the explanation.
Short Explanation
Tiny zip, huge GIS stack—pick the box that fits. Lambda container images handle fat preprocessing deps; zip stays great for lean handlers. Crowbar-fitting libraries into mapping templates or pretending Lambda has no image option misses the packaging menu.
Full Explanation
When a Lambda that preprocesses large GIS libraries for a parks department exceeds practical zip size and dependency constraints, prefer a Lambda container image and reserve zip packages for smaller runtimes that fit zip limits. Container images from ECR allow custom OS packages and larger dependency sets that municipal GIS preprocessing often needs, while still deploying as Lambda. Packaging guidance in Domain 3 is about matching artifact form to dependency reality.
Always using a zip and splitting libraries across dozens of manual console uploads fails because it is fragile, non-reproducible, and fights platform limits. Packaging the function only as an EC2 user-data script because Lambda cannot use containers fails conceptually—Lambda does support container images. Embedding GIS libraries in API Gateway mapping templates fails because mapping templates are not a dependency packaging mechanism for native GIS stacks.
Exam caveat: container-based Lambda still has practical image size and startup considerations; huge images can hurt cold starts for interactive civic APIs. Operational check: build the GIS function as an image in CI, push to ECR, configure the Lambda to use that image URI, and invoke a representative preprocess job in test before promotion.