Exams / AIP-C01 / Study guide / Switching models and providers without code changes (AppConfig, gateways, inference profiles)
Switching models and providers without code changes (AppConfig, gateways, inference profiles): AIP-C01 study notes and practice questions
What to know about Switching models and providers without code changes (AppConfig, gateways, inference profiles) for the AIP-C01 exam, from the Foundation Model Integration, Data Management, and Compliance domain (31% of the exam guide), then 1 free question to test it. Part of the AIP-C01 study guide.
Typical scenarios: a team wants a cheaper or newer model, wants to test one on a slice of users, or must roll back fast when quality drops. The answer combines configuration, a stable API and a controlled rollout.
Keep the model ID out of code
Store the model ID or inference profile ARN in an AppConfig configuration profile and read it at runtime. A model change becomes a configuration deployment.
Use an AppConfig deployment strategy for gradual rollout, for example 10 percent of traffic first, then 100 percent. Attach CloudWatch alarms as monitors so AppConfig rolls back automatically when an alarm fires.
Multi-variant feature flags in AppConfig split traffic between two models for a live comparison.
Keep one request shape
The Converse API uses one request and response structure across supported models. Switching model IDs rarely needs code changes. InvokeModel needs each model’s own body format.
Prompt Management variants let one prompt template carry several model-specific versions, so the prompt can change with the model.
Track cost and swap behind one ARN
An application inference profile is an ARN your app calls. It tags usage for cost allocation by app or team. The model behind it is fixed when you create it (only its tags can change), so to switch models you create a new profile and point the app at the new ARN, ideally through an AppConfig value. It does not reserve capacity; that is Provisioned Throughput.
Abstraction layer for many providers
When an application must call several providers or self-hosted models, put API Gateway and Lambda in front. The Lambda maps one internal request to each provider, applies logging, quotas and fallback, and the application never sees the provider. This adds a hop and an operational component, so use it only when several providers are a real need.
Rollback
Rollback should be a configuration action: revert the AppConfig version, or let the alarm trigger it. Keep the old model ID and prompt version available until the new one passes evaluation.
How to choose
Scenario wording
Choose
“Move 10 percent of users to a cheaper model, revert on errors”
AppConfig gradual deployment with a CloudWatch alarm monitor
“One code path calls several Bedrock models”
Converse API
“Track spend per team”
Application inference profile with cost allocation tags
“Compare two models on live traffic”
Multi-variant feature flag in AppConfig
“Several providers behind one internal API”
API Gateway and Lambda abstraction layer
“A prompt tuned differently for each model”
Prompt Management variants
Common traps
Hard-coding model IDs in many services, so every switch is a code release.
Writing a separate InvokeModel body for each model when Converse gives one shape.
Switching with no evaluation gate, so regressions reach users before anyone notices.
Manual rollback when an alarm-based AppConfig monitor would revert automatically.
Deleting the old configuration before the new model has proven itself.
Confusing an inference profile with Provisioned Throughput: profiles route and tag, they do not reserve capacity.
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 →
Study Switching models and providers without code changes (AppConfig, gateways, inference profiles)