The most efficient approach is to use Create a Lambda layer containing the common Python code and attach the layer to each function. Layers let you package shared libraries once, publish a new version when changes are needed, and have multiple functions reference that version to minimize redeployment work. Layers support up to five per function and are available for .zip-based Lambda functions. Store the shared Python modules in Amazon S3 and have each Lambda download them during initialization is operationally heavier and introduces cold-start latency, potential network failures, code drift, and additional IAM management, so it is not the preferred method for core dependencies. Containerize the functions and then add Lambda layers to the function configuration is incorrect because layers cannot be attached to container image functions. Dependencies must be baked into the image in that model. Use Lambda Extensions to inject the shared code into every function is not suitable because extensions are meant for telemetry, security, and governance tooling around the runtime, not for packaging or distributing business logic or libraries. For shared dependencies across many Lambda functions, think Lambda layers for .zip-based functions. If the question mentions container images, remember to bake dependencies into the image and that layers do not apply.