Answer - C.
The AWS Documentation mentions the following.
Canary release deployment in API Gateway.
In API Gateway, a canary release deployment uses the deployment stage for the production release of the base version of an API and attaches to the stage a canary release for the new versions, relative to the base version, of the API.
The stage is associated with the initial deployment and the canary with subsequent deployments.
In the beginning, both the stage and the canary point to the same API version.
We use stage and production release interchangeably and use canary and canary release interchangeably throughout this section.
When you enable API execution logging, the canary release has its own logs and metrics generated for all canary requests.
They are reported to a production stage CloudWatch Logs log group as well as a canary-specific CloudWatch Logs log group.
The same applies to access logging.
The separate canary-specific logs are helpful to validate new API changes and decide whether to accept the changes and promote the canary release to the production stage or to discard the changes and revert the canary release from the production stage.
Options A and B are incorrect.
Even though possible, they would add too much of maintenance overhead.
Option C is CORRECT because a small portion of traffic goes to the canary version before the traffic is fully switched to the new release.
Option D is incorrect because this is not the right way for a new deployment.
