Which solution will meet these requirements with the LEAST operational overhead?

Explanations:

Modifying environment variables of a published Lambda function version directly will not change the version being invoked by the application. Users will still face disruptions as they need to use the specific version ARN, and changes to the function would still require publishing new versions. Additionally, using the$LATESTversion for testing can lead to unpredictable behavior in production, as the$LATESTversion is not stable.

While using a DynamoDB table to store image processing parameters allows for dynamic retrieval of parameters without changing the Lambda version, it does not simplify the invocation process. The Lambda function still needs to be modified to read from DynamoDB, which increases operational overhead. Furthermore, this approach introduces additional latency due to the read operation from DynamoDB.

Hardcoding parameters within the Lambda function requires publishing a new function version every time the parameters change, which defeats the purpose of minimizing disruptions. This approach leads to more frequent deployments and version management, increasing operational overhead and complexity without addressing the need for flexibility in updating parameters.

Creating a Lambda function alias allows the client application to invoke the alias ARN instead of a specific version ARN. The alias can be reconfigured to point to new function versions after testing without needing to change the application. This solution minimizes user disruption and reduces operational overhead as it centralizes the management of version updates, allowing seamless transitions between versions.