AIP-C01 practice question: Switching models and providers without code changes (AppConfig, gateways, inference profiles)
Foundation Model Integration, Data Management, and Compliance A free question from our original AIP-C01 practice exam. Try it, then open the answer to see why each option is right or wrong.
A handmade-goods marketplace generates product descriptions with a model on Amazon Bedrock. The team wants to move from its current model to a newer one.
The switch must happen without a code deployment, and the new model should first receive about 5 percent of requests. If its error rate or review scores get worse, traffic must return to the old model within minutes.
The model IDs must live outside the application code, and the generator must keep running on managed Bedrock models, with no self-hosted model servers.
Which TWO actions meet these requirements? (Choose two.)
Choose two answers.
AA. Store the model ID and its variants as a free-form configuration in AWS AppConfig, deploy a 5 percent canary, and attach a CloudWatch alarm so that AppConfig rolls back automatically on errors.
BB. Hardcode the new model ID in the generator's Lambda function, and shift traffic between two Lambda aliases with CodeDeploy, so the change is rolled out through the normal release pipeline.
CC. Keep the two model IDs and their traffic weights in Parameter Store, and have the Lambda function pick the model for each request. Change the weights to move traffic, and set them back to roll back.
DD. Move the generator to a SageMaker AI real-time endpoint that hosts the new open-weight model, and use production variant weights to send 5 percent of traffic to it.
EE. Keep one model ID in the code, and switch the generator to a different Bedrock service tier when the new model is ready, so that the new model gets faster responses for the same requests.
B. Wrong: The model ID would still live in the code, which the requirements forbid. Each model change would also need a code deployment instead of a configuration change.
C. Right: The Lambda function reads the weights at runtime, so shifting from 5 percent to a full rollout is a parameter change with no deployment. Setting the weight back to zero returns traffic to the old model within minutes.
D. Wrong: A production variant weight does split traffic, but the requirement forbids self-hosted model servers. This option adds an endpoint to run and patch, which the team wants to avoid.
E. Wrong: Service tiers change priority and price for a request, not which model answers it. The model ID would stay in the code, so this option does not make the switch or the rollback possible.
Explanation
AppConfig and Parameter Store both hold the model choice outside the code, so the switch needs no deployment. AppConfig adds staged rollout with alarm-based rollback, while the Lambda weight approach gives the same control with code that the team owns. Hardcoded IDs, self-hosted endpoints and service tiers each fail one stated requirement.
Want more on Switching models and providers without code changes (AppConfig, gateways, inference profiles)? The 5 full-length practice sets have 6 more Switching models and providers without code changes (AppConfig, gateways, inference profiles) questions, 375 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →