Skill 3.2.5: Deploy and host models programmatically (for example, by using the SageMaker AI SDK for Python, AWS CLI, Boto3)

Question	Answer & Explanation
### Question 1 - SageMaker Python SDK vs. Boto3 for Model Deployment An enterprise is deploying a custom XGBoost model for a real-time inference use case. The data science team wants to deploy this model to an Amazon SageMaker AI endpoint using a Python script with the least operational overhead and minimal boilerplate code. Which programmatic method best satisfies these constraints? - A) Use the AWS CLI `aws sagemaker create-model` and `create-endpoint` commands wrapped in a Python `subprocess.call` script. - B) Use the `boto3.client('sagemaker').create_model()`, `create_endpoint_config()`, and `create_endpoint()` methods sequentially. - C) Use the SageMaker Python SDK `sagemaker.model.Model.deploy()` method. - D) Use AWS Step Functions to orchestrate multiple AWS Lambda functions invoking the SageMaker Boto3 API.	Correct Answer: C Correct Option Analysis: - C is Correct: The SageMaker Python SDK (`sagemaker.model.Model.deploy()`) is a high-level abstraction that automatically handles the creation of the model artifact, endpoint configuration, and endpoint deployment in a single call, drastically reducing boilerplate code and operational overhead. Distractor Analysis: - A is Incorrect: Wrapping AWS CLI commands in Python `subprocess` calls is an anti-pattern. It introduces shell dependency overhead, complex error handling, and lacks native Python object integration. - B is Incorrect: While Boto3 is the correct lower-level tool, manually chaining `create_model`, `create_endpoint_config`, and `create_endpoint` requires extensive boilerplate code to manage state and configurations, violating the minimal boilerplate constraint. - D is Incorrect: Using Step Functions and Lambda introduces unnecessary architectural complexity and operational overhead for a straightforward programmatic deployment. > Key Takeaway: Use the SageMaker Python SDK for high-level, low-overhead deployments; use Boto3 when you need explicit, low-level API control.
### Question 2 - Updating Endpoints Programmatically via AWS CLI A data scientist has trained a new version of a fraud detection model and needs to update an existing Amazon SageMaker AI real-time endpoint. The deployment must be performed programmatically using the AWS CLI, and the business mandates zero downtime during the update process. Which CLI command sequence satisfies these requirements? - A) `aws sagemaker update-endpoint --endpoint-name prod-endpoint --model-name new-model-v2` - B) `aws sagemaker create-endpoint-config --endpoint-config-name prod-config-v2 ...` followed by `aws sagemaker update-endpoint --endpoint-name prod-endpoint --endpoint-config-name prod-config-v2` - C) `aws sagemaker delete-endpoint --endpoint-name prod-endpoint` then `aws sagemaker create-endpoint --endpoint-name prod-endpoint --endpoint-config-name prod-config-v2` - D) `aws sagemaker update-endpoint-weights-and-capacities --endpoint-name prod-endpoint --variant-configs ...`	Correct Answer: B Correct Option Analysis: - B is Correct: To update an endpoint with zero downtime via CLI, you must first create a new endpoint configuration (`create-endpoint-config`), then call `update-endpoint` passing the new configuration name. SageMaker automatically provisions the new instances, shifts traffic, and decommissions the old instances. Distractor Analysis: - A is Incorrect: The `update-endpoint` command requires an `--endpoint-config-name`, not a direct `--model-name` parameter. - C is Incorrect: Deleting and recreating the endpoint causes complete downtime and loses the endpoint's operational state. - D is Incorrect: `update-endpoint-weights-and-capacities` is used to adjust traffic distribution or instance counts for existing variants, not to deploy a new model version. > Key Takeaway: Programmatic zero-downtime endpoint updates require creating a new endpoint config and calling `update-endpoint`.
### Question 3 - Configuring VPC Settings via SageMaker SDK An ML engineer is deploying a model using the SageMaker Python SDK. The compliance team requires the endpoint to run in private subnets with specific security groups to ensure no traffic traverses the public internet. How should the engineer implement this constraint directly in the Python deployment script? - A) Pass `vpc_config={'Subnets': ['subnet-1234'], 'SecurityGroupIds': ['sg-1234']}` to the `sagemaker.model.Model` constructor or `deploy()` method. - B) Use `boto3.client('ec2').modify_network_interface_attribute` after the endpoint is created to move it to the private subnet. - C) Set the environment variable `SAGEMAKER_VPC_CONFIG` in the custom inference container's Dockerfile. - D) Attach the `AmazonSageMakerFullAccess` policy to the SageMaker execution role, which automatically deploys endpoints in the default VPC.	Correct Answer: A Correct Option Analysis: - A is Correct: The SageMaker Python SDK natively supports VPC configuration by passing the `vpc_config` dictionary (containing `Subnets` and `SecurityGroupIds`) to the `Model` object or the `deploy()` method. This translates to the underlying `VpcConfig` required by the SageMaker API. Distractor Analysis: - B is Incorrect: Attempting to modify the network interface after the endpoint is created is disruptive, not supported for running SageMaker endpoints, and breaks automation. - C is Incorrect: SageMaker does not look for environment variables in the container to configure the host's VPC networking; VPC settings are infrastructure configurations applied before the container starts. - D is Incorrect: `AmazonSageMakerFullAccess` grants permissions to create network interfaces but does not automatically deploy endpoints into private subnets; explicit VPC configuration is still required. > Key Takeaway: In the SageMaker SDK, VPC isolation is configured programmatically via the `vpc_config` parameter.
### Question 4 - Boto3 for Inference Components An organization needs to programmatically deploy multiple distinct models onto a single SageMaker real-time endpoint to optimize compute costs. They want to use the low-level Boto3 client to achieve explicit control over the API calls. Which Boto3 API sequence satisfies this requirement? - A) Use `boto3.client('sagemaker').create_endpoint()` and provide a list of model names in the `ProductionVariants` parameter. - B) Use `boto3.client('sagemaker').create_inference_component()` for each model, specifying the target `EndpointName` and `RuntimeConfig`. - C) Use `sagemaker.model.Model.deploy()` with multiple `Model` objects passed as a list to a single endpoint. - D) Deploy a single large container via `boto3.client('sagemaker').create_model()` that loads all models internally, ignoring SageMaker's native multi-model endpoints.	Correct Answer: B Correct Option Analysis: - B is Correct: SageMaker Inference Components allow you to deploy multiple models to a shared endpoint. Using Boto3, you first create the endpoint, then call `create_inference_component()` for each model, attaching it to the endpoint and specifying the `RuntimeConfig` (number of copies). Distractor Analysis: - A is Incorrect: The `create_endpoint` API does not accept a list of models directly. You must create an endpoint configuration with variants first, and for Inference Components, the endpoint is created empty before components are attached. - C is Incorrect: This describes a hypothetical behavior of the SDK; deploying multiple models on one endpoint via the SDK requires specific Inference Component configurations, not just passing a list to `deploy()`. - D is Incorrect: Building a monolithic container defeats the purpose of SageMaker's native multi-model hosting and introduces heavy operational overhead for model updates. > Key Takeaway: Inference Components are created programmatically via Boto3 and attached to an existing endpoint to host multiple models on shared compute.
### Question 5 - Asynchronous Inference Configuration via SDK An engineer needs to deploy a SageMaker Asynchronous Inference endpoint programmatically. They are using the SageMaker Python SDK and must configure the output S3 location and error handling directly in the deployment code. Which SDK configuration satisfies this requirement? - A) Pass an instance of `sagemaker.async_inference.AsyncInferenceConfig` to the `Model.deploy()` method. - B) Use `boto3.client('sagemaker').create_endpoint_config()` and manually construct the `AsyncInferenceConfig` JSON payload. - C) Attach an AWS Lambda function to the S3 bucket that handles the async outputs after the endpoint is deployed. - D) Use the `sagemaker.predictor.Predictor` class and set the `async=True` parameter during invocation.	Correct Answer: A Correct Option Analysis: - A is Correct: The SageMaker Python SDK provides the `AsyncInferenceConfig` class. You instantiate it with the desired S3 output and failure paths, and pass it to the `deploy()` method of your Model to configure the endpoint for asynchronous operations. Distractor Analysis: - B is Incorrect: While Boto3 can technically do this, the scenario explicitly requires using the SageMaker Python SDK to configure it directly in the deployment code, making the high-level SDK object the correct answer. - C is Incorrect: Attaching a Lambda function is an architectural pattern for post-processing, but it does not satisfy the requirement of configuring the SageMaker endpoint's native async output locations programmatically. - D is Incorrect: You cannot convert a standard synchronous endpoint to an async endpoint simply by changing a parameter on the Predictor class at invocation time; the endpoint itself must be deployed with Async configurations. > Key Takeaway: Use `sagemaker.async_inference.AsyncInferenceConfig` in the SageMaker Python SDK to natively deploy async endpoints.
### Question 6 - Low-Level Control with Boto3 A team needs to deploy a custom inference container to SageMaker. They want to use the low-level Boto3 client because they need to set a specific, newly released API parameter that is not yet exposed by the high-level SageMaker Python SDK. Constraint: Must use Python. Which programmatic approach correctly deploys the model? - A) Use `boto3.client('sagemaker').create_model()`, `create_endpoint_config()`, and `create_endpoint()` sequentially. - B) Subclass `sagemaker.model.Model` and override the internal `create_endpoint` method to inject the new parameter. - C) Use `sagemaker.Session().create_model()` which dynamically maps all unknown kwargs to the Boto3 API. - D) Use the AWS CLI `aws sagemaker create-model` via the Python `os.system()` function to execute the deployment.	Correct Answer: A Correct Option Analysis: - A is Correct: When you need access to API parameters not yet supported by high-level SDKs, using the low-level Boto3 client (`create_model`, `create_endpoint_config`, `create_endpoint`) is the correct AWS best practice, giving you direct control over the raw API payload. Distractor Analysis: - B is Incorrect: Subclassing and overriding internal SDK methods is brittle, hard to maintain, and likely to break on SDK updates. - C is Incorrect: `sagemaker.Session()` does not automatically pass unknown kwargs to the underlying Boto3 API; it will raise Python argument errors. - D is Incorrect: Using `os.system()` to call the CLI from a Python script is a poor practice, prone to injection and parsing errors, and does not yield native Python objects. > Key Takeaway: Use Boto3 for low-level control and immediate access to new API parameters without waiting for SDK updates.
### Question 7 - Programmatic Auto-Scaling Registration via Boto3 An ML engineer has successfully deployed a SageMaker real-time endpoint. They now need to programmatically register the endpoint variant as a scalable target using Boto3. Constraint: Target tracking on the average invocations per instance. Which Boto3 API call correctly registers the scalable target? - A) `application_autoscaling_client.register_scalable_target(ServiceNamespace='sagemaker', ResourceId='endpoint/endpoint-name/variant/variant-name', ScalableDimension='sagemaker:variant:DesiredInstanceCount')` - B) `sagemaker_client.put_scaling_policy(PolicyName='mypolicy', EndpointName='endpoint-name', TargetValue=100)` - C) `application_autoscaling_client.register_scalable_target(ServiceNamespace='sagemaker', ResourceId='endpoint/endpoint-name', ScalableDimension='sagemaker:variant:InvocationsPerInstance')` - D) `cloudwatch_client.put_metric_alarm(AlarmName='HighInvocations', ...)` to trigger an AWS Lambda function that scales the endpoint.	Correct Answer: A Correct Option Analysis: - A is Correct: To scale a SageMaker endpoint, you use the Application Auto Scaling Boto3 client. The `ResourceId` must be formatted as `endpoint/<endpoint-name>/variant/<variant-name>`, and the `ScalableDimension` must be `sagemaker:variant:DesiredInstanceCount` to scale the underlying instances. Distractor Analysis: - B is Incorrect: Scaling policies are not applied directly via the SageMaker Boto3 client; they are applied via the Application Auto Scaling client. - C is Incorrect: The `ScalableDimension` controls what is being scaled (instance count). `InvocationsPerInstance` is a metric used inside the scaling policy, not the scalable dimension. - D is Incorrect: Building custom CloudWatch alarms to trigger Lambda for scaling is unnecessary operational overhead; SageMaker natively supports Application Auto Scaling. > Key Takeaway: SageMaker endpoints are scaled using the Application Auto Scaling Boto3 client with `ScalableDimension='sagemaker:variant:DesiredInstanceCount'`.
### Question 8 - CloudFormation Cross-Stack References for Endpoints An enterprise has a networking stack defined in AWS CloudFormation that exports the VPC subnet IDs and security group IDs. An ML engineer is writing a separate CloudFormation template to deploy a SageMaker endpoint. Constraint: Maintain loose coupling between the networking and ML stacks with no hardcoded values. How should the ML engineer reference the networking configuration in the SageMaker endpoint definition? - A) Use `Fn::ImportValue` to dynamically reference the exported subnet and security group IDs from the networking stack in the `VpcConfig` property. - B) Use `Ref` to directly reference the subnet resources from the networking stack. - C) Manually copy the subnet IDs into the `Parameters` section of the ML stack and use `Ref` to map them to `VpcConfig`. - D) Use `Fn::GetAtt` to retrieve the subnet IDs from the networking stack.	Correct Answer: A Correct Option Analysis: - A is Correct: `Fn::ImportValue` is the CloudFormation intrinsic function used for cross-stack references. It allows the ML stack to dynamically import values exported by the networking stack, maintaining loose coupling without hardcoding IDs. Distractor Analysis: - B is Incorrect: `Ref` can only be used for resources or parameters within the same template; it cannot reach across separate stacks. - C is Incorrect: Manually copying IDs into parameters defeats the automation requirement and creates configuration drift. - D is Incorrect: `Fn::GetAtt` is used to retrieve attributes of resources declared in the same template, not exported from another stack. > Key Takeaway: Use `Fn::ImportValue` in CloudFormation to securely import networking configurations into your SageMaker deployment stack.
### Question 9 - Deploying Custom Containers via AWS CLI A developer is deploying a custom inference container to SageMaker AI. The container image is stored in Amazon ECR. The deployment must be done programmatically using the AWS CLI. Constraint: Must specify the custom ECR image path in the model creation step. Which CLI command correctly creates the model? - A) `aws sagemaker create-model --model-name my-model --primary-container Image=123456789012.dkr.ecr.us-east-1.amazonaws.com/my-custom-image:latest` - B) `aws sagemaker create-model --model-name my-model --execution-role-arn arn:aws:iam::123456789012:role/SageMakerRole --container-image 123456789012.dkr.ecr.us-east-1.amazonaws.com/my-custom-image:latest` - C) `aws ecr deploy-image --repository-name my-custom-image --endpoint-name my-endpoint` - D) `aws sagemaker create-endpoint --endpoint-name my-endpoint --image-uri 123456789012.dkr.ecr.us-east-1.amazonaws.com/my-custom-image:latest`	Correct Answer: A Correct Option Analysis: - A is Correct: The `create-model` command accepts a `--primary-container` argument where you define the `Image` URI from ECR. (Note: Execution role is also required but omitted for brevity in the option, the container specification is correct here). Distractor Analysis: - B is Incorrect: The `create-model` command does not have a `--container-image` parameter; it uses `--primary-container` with a structured format. - C is Incorrect: `aws ecr` does not have a `deploy-image` command used for SageMaker; ECR is just the registry. - D is Incorrect: The `create-endpoint` command takes an `--endpoint-config-name`, not an image URI. The image URI must be specified when creating the model or endpoint config. > Key Takeaway: Custom ECR images are passed to SageMaker via the `--primary-container Image=<ecr-uri>` parameter in the `create-model` CLI command.
### Question 10 - Scaling Inference Components for Concurrency An ML team needs to configure high-resolution concurrency metrics for their streaming generative AI model to scale out quickly. They want to apply this via Application Auto Scaling using the AWS CLI. Constraint: React in seconds, not minutes, based on concurrent requests. Which configuration satisfies this requirement? - A) `aws application-autoscaling put-scaling-policy` targeting a high-resolution concurrency metric for `sagemaker:inference-component:DesiredCopyCount`. - B) `aws application-autoscaling put-scaling-policy` targeting `SageMakerVariantInvocationsPerInstance` for `sagemaker:variant:DesiredInstanceCount`. - C) `aws sagemaker update-endpoint-weights-and-capacities` to manually adjust instance count based on a cron job. - D) `aws cloudwatch put-metric-alarm` on `CPUUtilization` to trigger an AWS Lambda scale-out function.	Correct Answer: A Correct Option Analysis: - A is Correct: For Inference Components, scaling on a high-resolution concurrency metric (like `ConcurrentRequestsPerCopy`) with `sagemaker:inference-component:DesiredCopyCount` allows the system to react in seconds to streaming traffic surges. Distractor Analysis: - B is Incorrect: `SageMakerVariantInvocationsPerInstance` is a 1-minute resolution metric. It reacts too slowly for long-running streaming responses that require sub-minute scaling. - C is Incorrect: Manual adjustments via cron jobs do not provide the rapid, automated response required by the constraints. - D is Incorrect: Custom CloudWatch alarms and Lambda functions introduce unnecessary operational overhead and latency compared to native Application Auto Scaling target tracking. > Key Takeaway: For fast-scaling generative AI workloads on Inference Components, use Application Auto Scaling with high-resolution concurrency metrics on `DesiredCopyCount`.