Correct Answer: A.
Option A is CORRECT because with this you are pointing to your actual production code with the version 1 of Lambda.
If you make modifications to the code this will not affect the version 1
After you complete your changes you can point to the $LATEST version of the Lambda.
More details: https://docs.aws.amazon.com/lambda/latest/dg/configuration-versions.html.
Option B Is incorrect because ${lambdaenv} is not correct to refer to lambdaenv stage variable.
The correct statement is${stageVariables.lambdaenv}
More details: https://aws.amazon.com/blogs/compute/using-api-gateway-stage-variables-to-manage-lambda-functions/#:~:text=There's%20a%20new%20feature%20on,the%20API%20is%20running%20on.
Option C Is incorrect because you are pointing to the latest version of your Lambda and every modification that you make to the code will affect your customers.
Option D Is incorrect because there is no $initial version of Lambda by default.
The only default version is $latest.More details: https://docs.aws.amazon.com/lambda/latest/dg/configuration-aliases.html.
The correct answer is A.
Explanation:
In order to make code improvements to a Lambda function without disrupting customers, a version of the Lambda function should be created with the current code, and this version should be used by API Gateway in production. Then, the code improvements can be made to a new version of the Lambda function, and once the improvements are complete, the production traffic can be switched to the new version of the Lambda function without any disruptions. Here are the steps to achieve this:
Create a version in the Lambda with the actual code. This version will be named "1".
Start to make the modifications to the code.
In the integration request of API Gateway, set the Lambda function to ${stageVariables.Lambdaenv}.
Create a stage variable called "lambdaenv" in API Gateway Prod stage. Set lambdaenv to the ARN of version "1" of the Lambda function.
After finishing the modifications, set lambdaenv to the $latest Lambda function ARN.
Explanation of other options:
B. This option is similar to option A, except that it uses ${lambdaenv} instead of ${stageVariables.Lambdaenv} in the integration request. This is incorrect as the variable should be created as a stage variable.
C. This option is incorrect because it sets lambdaenv to the ARN of the $latest version of the Lambda function instead of version "1".
D. This option is incorrect because it sets lambdaenv to the ARN of version $initial of the Lambda function instead of version "1". The $initial version is the first version of the Lambda function, which may not be the same as the version that has the current code.