Update the Lambda, publish a new version, reference it in the API integration, and deploy the API to a separate stage for the new version is correct because it provides two independent API Gateway stages that point to different Lambda versions so clients can continue using the existing endpoint while early adopters move to the new one.

Publishing a new Lambda version and wiring the API integration to that version in a new stage creates distinct invoke URLs and immutable backends. This lets the team test and validate the new release, allow gradual migration, and retire the old stage on a planned schedule without disrupting current users.

Update the Lambda code, publish a new version, point the API integration to that version, and redeploy the API to the same stage is incorrect because redeploying to the same stage replaces the previous deployment and removes the old endpoint so clients cannot use both versions side by side.

Publish the update as a new Lambda version and expose it via a Lambda function URL instead of API Gateway is incorrect because function URLs bypass API Gateway features such as authorization, throttling, and usage plans and they do not provide two API Gateway endpoints for a controlled migration.

Enable an Amazon API Gateway canary release on the existing stage to shift 10% of traffic to the new deployment is incorrect because canary releases shift traffic for a single stage and URL rather than providing two stable endpoints that clients can explicitly choose between for a long side by side migration.

Full AWS Practitioner Certification Question