AWSAWS Certified Generative AI Developer - Professional2026-100 Prerequisites
Resolve model targets before invoking Bedrock
Completed by the knowledge check
Learning objective
Navigate Amazon Bedrock model access, model IDs, inference profiles, and runtime versus control-plane APIs.
Core idea
A Bedrock request needs more than a model’s marketing name. It needs an exact target supported by the selected API, an endpoint in the intended Region, and an account and calling identity permitted to use it. Model discovery, account-level activation, IAM authorization, and runtime inference are separate parts of that contract.
The modelId parameter can identify different resource types. A foundation model ID selects a base model; an inference profile selects a resource describing a model and its routing Regions. These values are not interchangeable merely because both fit in the same parameter. Check the resource behind the identifier before reasoning about where a request runs or how usage is attributed.
Use control-plane operations to discover and inspect resources. Use runtime operations to submit inference. Keeping these boundaries explicit prevents a catalog response or successful setup call from becoming false evidence that the application can generate an answer.
How it works
Discover the exact target
For AWS-native Bedrock discovery, use the bedrock SDK client. ListFoundationModels lists foundation models, and GetFoundationModel retrieves information for a particular model. ListInferenceProfiles lists inference profiles. The returned model and profile identifiers, together with the model’s documentation, are the input to your runtime configuration.
Do not construct a model ID from a display name or remove a version suffix because it looks redundant. Use the exact identifier supported by the chosen endpoint and API. AWS’s discovery documentation notes that listing responses can also include deprecated or backward-compatible IDs. Presence in a listing is not the entire selection decision; see 1.2.1 for capability shortlisting and 1.2.9 for lifecycle management.
InvokeModel.modelId accepts a base-model ID or ARN, and an inference-profile ID or ARN for the corresponding inference paths. Other documented resource types, such as Provisioned Throughput, use their own target ARNs. An application should preserve the target type with the identifier so a configuration change cannot silently change its operating assumptions.
Verify account activation separately
AWS documents access to many foundation models as enabled by default with the correct AWS Marketplace permissions. For applicable third-party serverless models, the first invocation initiates subscription setup in the background. This is not a universal instruction to request every model manually before making a call, nor a guarantee that every listed model is available to every account.
The activation prerequisites include the applicable AWS Marketplace permissions aws-marketplace:Subscribe, aws-marketplace:Unsubscribe, and aws-marketplace:ViewSubscriptions, plus a valid payment method. Once a model is enabled for the account, ordinary callers do not need Marketplace subscription permissions merely to invoke it. Separate a controlled activation identity from the production runtime’s narrower inference grant.
Anthropic models require first-time use-case submission through the console or PutUseCaseForModelAccess for the documented AWS-native path. AWS explicitly exempts Anthropic access through bedrock-mantle from this requirement. A successful submission can still leave an agreement pending; do not interpret submission success as immediate inference readiness.
Use GetFoundationModelAvailability to inspect availability. Its response includes agreementAvailability.status, authorizationStatus, entitlementAvailability, and regionAvailability. Agreement status can be AVAILABLE, PENDING, NOT_AVAILABLE, or ERROR; for an error, inspect errorMessage. A pending agreement can cause AccessDeniedException until setup completes. Some models require additional account-level access even after activation prerequisites are satisfied.
Deleting a model agreement or denying aws-marketplace:Subscribe alone is not a complete runtime-use block. AWS warns that an initial invocation can occur while automatic subscription proceeds. Enforce restrictions through the relevant Bedrock inference permissions as well.
Inspect inference profiles as resources
An inference profile defines a model and one or more Regions to which Bedrock can route invocation requests. System-defined cross-Region profiles are predefined by Bedrock. Application inference profiles are user-created resources for tracking model usage and costs; they can reference a foundation model in one Region or a system-defined cross-Region profile.
GetInferenceProfile takes inferenceProfileIdentifier, an ID or ARN. Its response includes inferenceProfileId, models[].modelArn, status, and type. The type is SYSTEM_DEFINED or APPLICATION; ACTIVE indicates readiness of the profile resource. Read these fields instead of assuming a friendly profile name proves a particular routing scope.
An application profile is not automatically a cross-Region profile. Nor does a profile mean that Bedrock selects among unrelated models by judging the prompt. It describes a model route, with usage attribution for application profiles. Residency and destination authorization require a separate review; see 1.2.4.
Send inference to the runtime surface
For AWS-native inference, use the bedrock-runtime client. InvokeModel sends a model-specific request body. Converse provides a consistent message interface for models that support it, with the target in modelId and conversation input in messages. The streaming counterparts are InvokeModelWithResponseStream and ConverseStream.
Converse requires bedrock:InvokeModel, even though the API operation’s name differs from the IAM action. Denying both bedrock:InvokeModel and bedrock:InvokeModelWithResponseStream on the target blocks the corresponding Invoke and Converse inference paths. Request construction and serialization belong to 1.3.6 and 1.3.7.
AWS also provides a bedrock-mantle inference endpoint. It is an inference surface, not the bedrock control plane, and it does not support InvokeModel or Converse. Conversely, bedrock-runtime also supports documented compatible API surfaces, so it should not be described as exclusively an Invoke/Converse endpoint. Choose the API and endpoint together and verify the model’s support for that combination.
Key distinctions and trade-offs
Model name versus model ID: A display name helps people recognize a model. An exact ID or supported ARN selects the runtime target. Configuration must retain the latter.
Model ID versus profile ID: A foundation model and an inference profile are different resources. A shared parameter name does not erase routing or attribution differences.
Activation versus invocation permission: Marketplace setup enables applicable account access. IAM grants still determine what a runtime identity can invoke. Successful activation does not authorize every principal.
Control plane versus runtime: Listing, inspecting, and configuring resources do not generate model responses. A private endpoint or SDK client for one plane does not substitute for the other; see 0.14.
Architecture / decision scenario
A team launches a support assistant using an Anthropic model through the AWS-native Bedrock runtime. Its setup identity discovers the exact model with ListFoundationModels, submits the required use case, and checks GetFoundationModelAvailability rather than relying on a successful form submission.
The deployment selects an application inference profile referencing an approved system-defined profile. GetInferenceProfile confirms the resource type and model ARNs, and the team reviews the processing Regions as described in 1.2.4. The application preserves the profile identifier as its runtime target.
The runtime role needs bedrock:InvokeModel on the application profile ARN and the foundation model in each associated Region; a bedrock:InferenceProfileArn condition on model-resource grants can restrict invocation to that profile (see 1.2.4). The application sends Converse to bedrock-runtime with the profile in modelId, then verifies a representative invocation before promotion. A control-plane listing, an active profile, and an available agreement each provide useful evidence, but only the tested runtime path proves that this caller, target, Region, and request work together.
Common exam traps
- Using a model display name where the API requires an exact identifier.
- Treating a listing response as account-level inference access.
- Giving all runtime callers subscription permissions after activation.
- Assuming every application inference profile routes across Regions.
- Calling
InvokeModelthrough the control-plane or Mantle client. - Treating successful use-case submission as a completed agreement.
What to remember
Discover with the control plane, inspect the target resource, verify account availability and IAM permissions, then invoke through the supported runtime surface. Preserve both the identifier and its resource type. Model access, profile readiness, endpoint compatibility, and successful inference are separate checks.
Knowledge check
A developer configures modelId as amazon.nova-pro instead of amazon.nova-pro-v1:0, reasoning that the version suffix is redundant. What should the runtime configuration hold?
A third-party model has already been enabled for the account. A new production service role needs to call it. What does that role still need?
A team created an application inference profile to attribute a product’s model usage, and a reviewer states that its requests therefore route across Regions. What settles whether that is true?
type , which is APPLICATIONGetInferenceProfile returns for itstatus , which is ACTIVEACTIVE only reports that the resource is ready.A team called PutUseCaseForModelAccess for an Anthropic model on the AWS-native path and the call succeeded. The runtime role has bedrock:InvokeModel on the model, yet Converse returns AccessDeniedException. What should the team check?
agreementAvailability status from GetFoundationModelAvailabilitybedrock:Converse action in the runtime role’s policyPENDING , and invocation returns AccessDeniedException until the status is AVAILABLE . Converse is authorized by bedrock:InvokeModel , which the role already has.A setup script discovers models with the bedrock client. The application must now send AWS-native Converse requests. Which surface should it call?
bedrock client used for discoverybedrock-runtime client and endpointbedrock-mantle inference endpointbedrock is the control plane for listing and inspecting resources; Converse is a runtime operation on bedrock-runtime . bedrock-mantle is an inference endpoint, but it does not support InvokeModel or Converse .