AWSAWS Certified Generative AI Developer - Professional2026-100 Prerequisites
Separate model resources from serving endpoints
Completed by the knowledge check
Learning objective
Distinguish Amazon SageMaker AI models, endpoints, inference containers, and JumpStart.
Core idea
In SageMaker AI, a model resource, an inference container, and an endpoint serve different purposes. A model resource describes what to deploy. A container implements the inference server and loads the model artifacts. An endpoint is the deployed serving resource that an application invokes. JumpStart helps you discover models and deploy them through SageMaker AI; it does not remove these resource boundaries.
The word “model” can refer to learned weights or to an AWS resource describing their deployment. Keep those meanings separate. Having a weights file in S3 does not mean an endpoint exists. Creating a SageMaker model resource does not mean that its container has started or can accept application traffic.
The foundational deployment path is model resource, endpoint configuration, endpoint, then invocation. Diagnose each stage using its own identifiers and readiness evidence. This lesson explains that resource vocabulary; detailed inference-mode selection belongs to 2.2.2.
How it works
Describe the deployable model resource
CreateModel creates a SageMaker AI model resource. Its ModelName names that resource. For a single-container deployment, PrimaryContainer describes the Docker image containing inference code, associated artifacts, and environment configuration. Containers supports an inference pipeline with multiple container definitions.
The container definition’s Image selects the inference image. A deployment can identify model artifacts through ModelDataUrl or ModelDataSource.S3DataSource. The image and artifacts have different responsibilities: the image supplies executable serving behavior; the artifacts supply the model data that behavior consumes. Changing one without checking the other can break the deployment contract.
ExecutionRoleArn names the IAM role SageMaker AI assumes to access artifacts and the Docker image for deployment. The caller of CreateModel needs iam:PassRole to pass that role. This is distinct from the application caller that later invokes the endpoint. Giving an application inference access does not automatically give the hosting service access to the model files; see 0.13 for role and permission fundamentals.
A model resource can also support a batch transform job through CreateTransformJob. It is therefore inaccurate to define every model resource as an already-running web service. Endpoint hosting is one use of that resource, not its identity.
Understand the inference container contract
SageMaker AI starts the inference image with the serve argument, overriding the image’s default CMD arguments. A compatible Docker image must behave as an inference server under that startup contract; a container that runs successfully on your laptop is not automatically compatible with managed hosting.
For the documented HTTP inference contract, the server listens on port 8080 and provides /invocations and /ping paths. /invocations handles inference requests, while /ping supports hosting health checks. Passing a health check does not establish that the model returns an acceptable answer for a business request. Your acceptance test must exercise inference too.
SageMaker AI copies artifacts into /opt/ml/model before the inference code uses them. This directory is read-only to the container. When you use ModelDataUrl, it must point to a tar.gz file that SageMaker AI decompresses into that directory. AWS also documents an uncompressed deployment path for large models; do not generalize the compressed-file requirement to every artifact mechanism.
For normal synchronous InvokeEndpoint, the container must respond within 60 seconds. This is a serving-contract limit, not a claim that every SageMaker AI inference mode has the same duration budget. A generation workload that cannot meet it needs an eligible delivery mode rather than an arbitrary increase to the client’s waiting time. Serialization details belong to 1.3.8.
Configure and create the endpoint
CreateEndpointConfig describes the models and resources SageMaker AI should deploy. For a conventional instance-backed endpoint, ProductionVariants identifies the hosted model through ModelName and includes settings such as InstanceType, InitialInstanceCount, and InitialVariantWeight. These settings belong to the serving topology; they do not alter the learned weights.
CreateEndpoint takes an EndpointName and an EndpointConfigName. SageMaker AI then provisions resources and deploys the models described by that configuration. The endpoint initially has status Creating; use DescribeEndpoint to verify that it reaches InService before depending on inference readiness.
The endpoint name is unique within an AWS account and Region. It is separate from the model name and endpoint-configuration name, even when you choose similar human-readable names. AWS requires a new endpoint configuration to update an endpoint; do not delete a configuration that a live endpoint uses. Release and rollback controls belong to 1.2.8.
Each resource names the one it depends on, down to the image, the artifacts, and the role.
Invoke the serving resource
An application sends InvokeEndpoint through the SageMaker runtime API. It selects the deployment with EndpointName, supplies input bytes in Body, and describes their MIME type with ContentType. Accept specifies the desired response MIME type. SageMaker AI passes the body to the model, so the container’s schema determines what those bytes mean.
This interface does not become Bedrock Converse merely because the deployed weights implement a language model. A JSON message format supported by one container is not a universal SageMaker AI prompt format. Preserve an adapter that matches the selected container and model; see 2.2.3 for joining hosted and Bedrock paths.
SageMaker AI authenticates InvokeEndpoint with AWS Signature Version 4. Endpoints are scoped to an individual account and are not public application URLs. An application’s user-facing interface must still implement its own user authorization and response contract.
Place JumpStart in the deployment path
JumpStart covers publicly available foundation models and task-specific models; both deploy through the SageMaker AI model and endpoint chain. For a foundation model, the SageMaker Python SDK uses JumpStartConfig(model_id=MODEL_ID), ModelBuilder.from_jumpstart_config(...), build(), and deploy(), where MODEL_ID identifies the selected model; the endpoint then accepts that model’s JSON contract, such as an inputs key for the documented FLAN-T5 example.
JumpStart provides model discovery in Studio and programmatic access through the SageMaker Python SDK. list_jumpstart_models() lists available model IDs. A model’s detail page describes intended capabilities, expected inputs and outputs, and fine-tuning data requirements. Use this information to select an eligible candidate, not as evidence that it satisfies your application quality gates.
Deploying a JumpStart model creates a SageMaker AI hosting endpoint for inference. Deployment configuration includes choices such as the endpoint name, instance type, artifact storage, and security settings. JumpStart reduces the work of assembling a supported deployment; the resulting endpoint still has its own capacity, container contract, and access boundaries. Task-specific model selection belongs to 2.2.8.
Key distinctions and trade-offs
Weights versus model resource: Weights are model data. CreateModel describes an executable deployment package and its access role. Neither alone proves a serving endpoint is ready.
Container versus endpoint: The container implements loading and inference. The endpoint provides the managed deployment callers address. A container defect and a missing endpoint are different failures.
Endpoint configuration versus endpoint: Configuration describes the intended models and resources. The endpoint provisions and serves them. Inspect DescribeEndpoint rather than treating successful configuration creation as readiness.
JumpStart versus inference API: JumpStart helps select and deploy models. The application subsequently uses the deployed endpoint’s runtime interface, with the chosen model’s input and output contract.
Architecture / decision scenario
A team selects a task-specific JumpStart model as a candidate for document classification. The model details define the expected input shape. The team identifies the serving image and artifacts, configures the hosting execution role, and verifies that the deployer can pass that role.
The deployment creates the model resource, endpoint configuration with an appropriate instance-backed production variant, and named endpoint. The team checks DescribeEndpoint for InService and then sends representative InvokeEndpoint requests with matching ContentType, Body, and Accept.
If the endpoint is healthy but rejects the payload, the team checks the container schema rather than replacing the weights. If deployment cannot load the model, it checks the artifact location and execution-role permissions. If accepted responses have poor classification quality, it evaluates the selected model instead of treating an infrastructure health check as quality evidence.
Common exam traps
- Treating
CreateModelas a running inference endpoint. - Supplying
ModelNamewhereInvokeEndpointexpectsEndpointName. - Assuming every Docker image satisfies the SageMaker serving contract.
- Writing application state into the read-only
/opt/ml/modeldirectory. - Treating
InServiceor/pingsuccess as answer-quality validation. - Expecting JumpStart to eliminate endpoint capacity and access decisions.
What to remember
Follow the resource chain: model data and serving image, model resource, endpoint configuration, deployed endpoint, runtime invocation. JumpStart helps assemble that chain. Each stage has a separate name, contract, and readiness question; successful deployment and acceptable model behavior require different evidence.
Knowledge check
CreateModel succeeds, and the application immediately calls InvokeEndpoint with the new ModelName. The call fails. What is missing?
EndpointNameiam:PassRole grant for the application that invokes the modelModelDataUrl locationCreateEndpointConfig and CreateEndpoint , the endpoint must reach InService , and InvokeEndpoint addresses it by EndpointName , not by ModelName .A custom inference image runs correctly on a developer’s laptop, but SageMaker AI hosting never passes its health checks. Which change addresses the hosting contract?
/ping and /invocations on port 8080 when started with serveInitialInstanceCount in the production variant/opt/ml/modelserve argument and expects an HTTP server on port 8080 that answers /ping for health checks and /invocations for inference. Running locally does not prove that contract, and /opt/ml/model is read-only to the container.A SageMaker AI endpoint reports InService and answers /ping. What evidence is still needed before approving it for document classification?
InService confirms the model works/ping check from the application’s networkInvokeEndpoint requests with quality checksDescribeEndpointConfig check of the production variantInService and a passing health check show deployment readiness. Only representative inference shows that the container accepts the intended payload, and only quality checks show that its classifications are acceptable.Endpoint creation fails because the container cannot load the model artifacts from Amazon S3. The application role already has permission to call InvokeEndpoint. Which identity needs access to the artifacts?
ExecutionRoleArniam:PassRole grantExecutionRoleArn to read model artifacts and the image for deployment. The deployer needs iam:PassRole only to hand that role over, and the application’s inference permission is a separate boundary.A team deploys a JumpStart text model and sends InvokeEndpoint requests in the Bedrock Converse message format. The endpoint is healthy but rejects every payload. What should the team change?
Converse with the JumpStart model IDinputs key in the documented FLAN-T5 example. A language model on SageMaker AI does not accept Bedrock’s Converse format by default.