Three municipal Lambdas share the same GIS SDK and logging library, and copying those zip dependencies into every function bloats packages. What should the team use?
Select an answer to reveal the explanation.
Short Explanation
One shared toolbox on the truck beats packing the same wrenches into three separate kits. A Lambda layer carries the common GIS SDK and logging library so each function zip stays lean. Duplicating zips, Glacier thaws on cold start, or pasting SDKs into source are the bloated paths.
Full Explanation
Three municipal Lambdas that share the same GIS SDK and logging library should attach a Lambda layer that hosts the shared libraries rather than copying zip dependencies into every function. Layers shrink deployment packages, speed updates to business code, and provide one place to patch the SDK when a vulnerability drops. That matters when GIS clients are large and parks, planning, and utilities all need the same supported version without triplicating vendor trees in Git.
Duplicating dependencies in each deployment package accepts avoidable size growth and multiplies patch toil across teams. Storing the SDK only in Glacier and thawing it during every cold start destroys latency budgets for interactive map tools. Inlining the entire GIS SDK as string literals inside each handler is unmaintainable and still bloats what Lambda must download at init.
Exam caveat: layers have size quotas and versioning semantics—pin versions deliberately and test before advancing aliases. Native binaries must match the Lambda OS and architecture (x86_64 vs arm64). Secrets and environment-specific config do not belong in layers.
Operational check: publish a versioned layer with GIS SDK and logging; attach it to the three functions; remove duplicated vendor trees from function zips; regression-test imports and cold starts after layer updates; and document the owner who patches the shared layer.