AWSAWS Certified Generative AI Developer - Professional2026-101.2 Select and configure FMs
Move model choices behind a validated contract
Completed by the knowledge check
Learning objective
Decouple model selection from application code using provider adapters and AWS AppConfig with Lambda or API Gateway. Make a model change a controlled routing release rather than a search through feature code.
Core idea
Separate three responsibilities: the application defines the task contract, an adapter translates it into a model interface, and configuration selects an approved target. AWS AppConfig distributes and validates configuration; it does not implement the adapter or establish that two models behave identically.
A stable interface reduces the code required to change a model. It does not eliminate compatibility testing. A replacement still needs the required modalities, prompt interpretation, response shape, location policy, and operating envelope. Decoupling makes those differences explicit at one boundary.
How it works
Define the application boundary
Expose operations that reflect the application’s needs, such as generating a draft from approved evidence. Give each request a task identity, normalized inputs, response budget, and deadline. Give each response normalized content, a completion outcome, usage information where available, and the identity of the configuration used.
Keep provider-specific field names out of business logic. For supported message models, Amazon Bedrock’s Converse provides a consistent API with messages, modelId, and inferenceConfig. Model-specific settings can be supplied through additionalModelRequestFields. This reduces translation work but does not make unsupported features appear in every model.
For a model using a different interface, the adapter owns serialization and response parsing. As an illustrative native schema, the documented Titan Text request uses inputText and textGenerationConfig, while its response exposes outputText and completionReason inside results. This interface example does not establish deployment eligibility; see 1.2.1. Business code should consume a normalized result rather than interpret those fields itself. See 2.4.7 for routing strategies behind a model-agnostic request contract.
Fail a capability check before invocation when the selected adapter cannot honor a required input or operation. Do not discard an image, silently omit a tool, or accept an incomplete output merely to preserve the appearance of a common interface. The adapter represents differences; it does not hide them.
Make routing data reviewable
Use an AWS AppConfig application, environment, and configuration profile to describe the approved routing policy. A free-form configuration can map a task to an adapter, an exact model or inference-profile identifier, permitted Region, and bounded response settings. These are application-defined fields, not a built-in AppConfig model-router schema.
Keep credentials out of this configuration. A model target is a deployment choice; the execution identity’s permission to invoke it is a separate boundary. A routing update cannot grant missing authorization or override the application’s data-processing restrictions.
Validate free-form configuration with AppConfig’s JSON Schema validator for structural rules and a Lambda validator for semantic rules. A schema can require a target and reject unknown fields. Your Lambda validator can reject unsupported adapter names, incompatible modality requirements, or targets outside your approved inventory.
AWS AppConfig runs validators during StartDeployment and ValidateConfigurationActivity. Its Lambda validation limit is 15 seconds including startup latency, so keep semantic checks bounded. Treat full model benchmarking as an earlier release gate, not work performed synchronously inside the validator.
Retrieve configuration in the request runtime
In an API Gateway and Lambda architecture, the request reaches Lambda, which resolves the task’s approved routing configuration and invokes the adapter. API Gateway supplies the API boundary; the Lambda application performs selection. Do not assume API Gateway automatically reads AppConfig or understands model compatibility.
Attach the AWS AppConfig Agent Lambda extension as a layer to the function. The extension handles configuration retrieval and caching outside your business handler. This provides a concrete retrieval mechanism instead of requiring every invocation to build its own polling implementation.
Resolve one configuration snapshot for the request and record its version with the result. If a long request crosses a configuration update, keep its model and response-handling choices coherent. A fallback policy should belong to that same snapshot; see 1.2.5. Mixing a new fallback list with an old primary decision makes the request difficult to reconstruct.
Define startup and unavailable-configuration behavior. An application can retain a previously validated local configuration under its own freshness policy, or return a controlled unavailable response when no acceptable configuration exists. Do not fabricate a default target that bypasses review. AppConfig retrieval is a delivery mechanism, while the application’s fallback policy remains your responsibility.
Release and observe the routing change
Use an AppConfig deployment strategy to introduce the new routing version gradually and retain a bake period. Associate CloudWatch alarms with the AppConfig environment so deployment problems can trigger rollback. API Gateway’s 5XXError, Latency, and IntegrationLatency help detect operational regressions; a task-quality signal requires your own measured application metric.
AppConfig can roll back an in-progress deployment when a configured alarm enters ALARM or INSUFFICIENT_DATA. Alarm actions and monitoring permissions must be configured correctly. StopDeployment provides a manual rollback path; the documentation also describes AllowRevert for a completed deployment. Rolling back configuration only helps if the previous target remains usable.
Key distinctions and trade-offs
Adapter versus router: The adapter translates the interface. The router selects the target. Changing the route cannot repair an adapter that parses the replacement model incorrectly.
Configuration validity versus model fitness: Validators establish that routing data obeys your rules. Benchmark evidence establishes that the selected model meets the task; see 1.2.2.
Configuration rollback versus artifact rollback: Returning to a previous route changes future selection. It does not rebuild or restore missing custom weights.
More abstraction can make cross-provider changes easier but also obscure useful model capabilities. Keep a common required contract and explicit optional capabilities. Prefer a visible unsupported-operation result to a universal interface that silently changes task meaning.
Architecture / decision scenario
A support API hardcodes a model ID in each feature handler. A replacement requires coordinated code releases, and one forgotten handler continues using the old model.
You introduce a shared generation adapter and a task-to-target map in AppConfig. Lambda obtains the configuration through the Agent extension and records the routing version with each request. A JSON Schema rejects malformed maps; a Lambda validator rejects targets outside the approved inventory.
A gradual routing deployment raises the API’s 5XXError alarm because the replacement’s response adapter is incomplete. AppConfig restores the previous route while the team fixes the adapter. The business handlers remain unchanged because their contract did not depend on the provider response.
Common exam traps
- Treating AppConfig as a built-in FM inference router.
- Assuming a consistent
Converseinterface guarantees identical capabilities. - Placing model-specific parsing in every feature handler.
- Using configuration to bypass authorization or processing-location policy.
- Expecting JSON Schema validation to prove response quality.
- Calling a routing rollback sufficient after deleting the previous target.
What to remember
- Keep task behavior, model translation, and target selection separate.
- Use
Conversewhere supported and explicit adapters for other interfaces. - Validate AppConfig routing data structurally and semantically.
- Retrieve configuration through the Agent Lambda extension and record its version.
- Release routing changes gradually with configured alarms and a usable previous target.
Knowledge check
Business handlers parse provider-specific response fields in many places, so every model change means editing each handler. Which component should absorb those differences?
An AppConfig routing map is valid JSON with every required field, but it names a model target outside the approved inventory. Which check should reject it?
A long Lambda request is still running when a new routing version deploys. Which configuration should the request use for its primary and fallback choices?
During a gradual AppConfig rollout of a new routing version, an alarm on the environment enters ALARM. The previous version routes to a custom model deployment that the team deleted last week. What does the rollback achieve?