Exam AWS Certified Developer - Associate DVA-C02 topic 1 question 313 discussion

The wording is screaming out weighted alias. During a canary deployment, we are moving code from testing to prod. We can define a subset of users i.e. 10% for a set period of time. After this the other users will be impacted as the percentage will increment or the deployment will push new code to 100% of users. With a weighted alias we can define a subset of users and use this as our guinea pigs to test new code. As this isn't a canary deployment we have no risk of more users becoming impacted. Operational overhead is minimal as we only need to point to a new alias. With weighted alias we can deploy for testing purposes. From my understanding lambda proxy is grouping lambda functions. the traffic splitting would need to be set at the lambda level as this is testing prior to deployment.

This is the least amount of effort. I originally thought answer A but then you will have more effort because will have to update API Gateway configuration to use new ARN etc. Unless there are other thoughts on this?

The simple answer is A. The Simple reason for the answer to not be D is why you would need to create a new Rest API endpoint.?

Best Solution: Option A: Create a new version of each Lambda function with a weighted alias. Configure a weight value for each version of the Lambda function. Update the new weighted alias Amazon Resource Name (ARN) in the REST API. This is the least complex and most efficient solution. By using weighted aliases for Lambda versions, you can control the traffic sent to the new version of the function, and it can be done with minimal operational overhead, without the need to create a new API or involve other services like AWS CodeDeploy.

Weight ed alias

Yes. Answer is Option A. B will eventually push all users to new alias as part of canary deployment.

B provides the least operational effort

I think A is direct

I am going with A, not sure if creating a new rest api is less effort then just managing the existing API config for the weight.

Option A is typically the most straightforward and requires the least operational effort while providing high control over traffic distribution directly from the Lambda configuration. This method avoids the overhead of managing additional services or creating new APIs and is directly supported by AWS services for testing purposes with actual users.

A is the correct answer.

It says: with the LEAST amount of operational effort B --- NEVER A!!!

Prefer A, because creating a new REST API (B) involves more operational overhead and complexity compared to using weighted aliases. Moreover, setting up a Lambda proxy integration to connect to multiple Lambda functions can increase complexity, especially when handling different versions for canary testing.

https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html

} El desarrollador debe crear una nueva API REST en Amazon API Gateway y configurar una integración Lambda sin proxy para conectarse a múltiples funciones Lambda. Luego, debe especificar los parámetros y propiedades necesarios en API Gateway y habilitar la configuración canary en la etapa de implementación. Especifique un porcentaje menor de tráfico API para ir a la nueva versión de la función Lambda. Al utilizar una nueva API REST en API Gateway con una configuración canary, el desarrollador puede probar las funciones Lambda actualizadas con nuevas características con un subconjunto de usuarios antes de la implementación completa. Esto permite realizar pruebas sin afectar a otros usuarios de la aplicación y con un menor esfuerzo operativo.

Should be B

Option A involves using weighted aliases for Lambda functions, which is a valid approach but requires more effort to manage and update the aliases in the API Gateway configuration.