Skip to content

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

Question 1 - Programmatic Deployment with SageMaker SDK vs Boto3

A financial services company is building a fraud detection system that requires deploying multiple XGBoost models to SageMaker AI endpoints in a continuous deployment pipeline. The MLOps team needs to programmatically create models, endpoint configurations, and endpoints from their CI/CD environment.

The team lead wants to minimize boilerplate code and reduce the risk of misconfigured API calls across hundreds of model deployments, while still maintaining the ability to update individual inference component parameters when necessary.

Which approach should the MLOps engineer use for the majority of deployments? (Select ONE)

  • A) Use the low-level Boto3 sagemaker client exclusively for all API calls to maintain maximum control over individual fields.
  • B) Use the SageMaker Python SDK high-level estimators and Model.deploy() method for standard deployments, falling back to Boto3 only for custom edge cases.
  • C) Manually invoke the AWS CLI aws sagemaker create-model command for each deployment to avoid dependency management.
  • D) Use AWS CloudFormation templates exclusively for all model deployments, hardcoding endpoint names as parameters.
Click to reveal Answer & Explanation

Correct Answer: B

Correct Options Analysis

  • B is Correct: The SageMaker Python SDK provides high-level abstractions (Model class, deploy() method) that automatically handle the multi-step process of creating model resources, endpoint configurations, and endpoints with sensible defaults. This significantly reduces boilerplate code and API misconfiguration risk. Falling back to Boto3 for edge cases preserves the flexibility to control individual API fields when needed.

Distractor Analysis

  • A is Incorrect: Using low-level Boto3 exclusively requires manually orchestrating every API call (create_model, create_endpoint_config, create_endpoint, etc.), which dramatically increases code complexity and misconfiguration risk across hundreds of deployments.
  • C is Incorrect: Manual AWS CLI commands are not suitable for automated CI/CD pipelines at scale; they introduce human error, lack idempotency, and eliminate the programmatic error handling capabilities of SDK libraries.
  • D is Incorrect: Hardcoding endpoint names in CloudFormation templates creates naming collisions on subsequent stack deployments and doesn't leverage the provisioning logic built into the SageMaker SDK. Endpoint names must be unique per deployment.

Key Takeaway: The SageMaker Python SDK layers high-level convenience over low-level Boto3 API calls—use the SDK for standard work and Boto3 for surgical control.

Question 2 - SageMaker Endpoint Deployment Update Strategy

A retail company has a product recommendation model hosted on a SageMaker real-time endpoint. The data science team retrains the model weekly and needs to deploy the updated model to production with zero downtime.

The current endpoint is using instance type ml.m5.xlarge with the model variant recommendation-v1. The team must ensure the new model (recommendation-v2) is deployed while the old version continues serving requests until the new one is healthy. The deployment must be fully automated from a Python script.

Which deployment approach should the engineer implement? (Select ONE)

  • A) Delete the existing endpoint and recreate it with the new model using delete_endpoint() followed by deploy(), accepting brief downtime.
  • B) Use update_endpoint() with the SageMaker SDK after creating the new model and endpoint configuration, triggering a rolling update.
  • C) Create a completely separate new endpoint for v2 and manually migrate traffic using a custom DNS switch.
  • D) Use the AWS CLI to stop the endpoint, replace the model artifacts in S3, and restart the endpoint.
Click to reveal Answer & Explanation

Correct Answer: B

Correct Options Analysis

  • B is Correct: The SageMaker SDK's update_endpoint() method allows you to specify a new endpoint configuration with the updated model. SageMaker performs a blue/green deployment, automatically provisioning new instances with the updated model, validating their health, and only then shifting traffic—ensuring zero downtime.

Distractor Analysis

  • A is Incorrect: Deleting and recreating an endpoint causes significant downtime during resource provisioning and is an anti-pattern for production services, especially with strict zero-downtime requirements.
  • C is Incorrect: Creating a separate endpoint and managing custom DNS switching introduces unnecessary operational complexity and fails to leverage SageMaker's built-in blue/green deployment capabilities.
  • D is Incorrect: Stopping and restarting the endpoint still causes downtime, and simply replacing model artifacts in S3 does not update the deployed model—SageMaker loads model artifacts into immutable instance volumes at endpoint creation.

Key Takeaway: update_endpoint() gives you production-grade zero-downtime deployments—SageMaker handles blue/green traffic shifting automatically.

Question 3 - Boto3 API Call Sequence for Endpoint Creation

A startup needs to deploy a custom TensorFlow model to SageMaker using only the low-level Boto3 library. The engineer must ensure the API calls are made in the correct order with all required dependencies satisfied.

The model container image is stored in Amazon ECR as tensorflow-inference:2.14.0. The execution role ARN is arn:aws:iam::123456789012:role/sagemaker-execution-role. The model artifacts are in s3://model-bucket/tensorflow-model/model.tar.gz.

What is the correct sequence of Boto3 API calls to deploy this model? (Select ONE)

  • A) create_endpoint_config() → create_model() → create_endpoint()
  • B) deploy_model() → create_endpoint()
  • C) create_model() → create_endpoint_config() → create_endpoint()
  • D) create_endpoint() → create_endpoint_config() → create_model()
Click to reveal Answer & Explanation

Correct Answer: C

Correct Options Analysis

  • C is Correct: The correct sequence is: (1) create_model() registers the container image and model artifacts with the execution role; (2) create_endpoint_config() specifies the deployment configuration (instance type, model reference, scaling parameters); (3) create_endpoint() provisions the actual endpoint using the configuration.

Distractor Analysis

  • A is Incorrect: create_endpoint_config() requires a model name reference that must exist first—the model must be created before the endpoint configuration can reference it.
  • B is Incorrect: deploy_model() is not a valid Boto3 SageMaker API method; this is a SageMaker SDK convenience method that internally orchestrates all three API calls.
  • D is Incorrect: Creating the endpoint first cannot work because the endpoint requires an endpoint configuration ARN, which in turn requires a model reference—the dependency chain flows in the opposite direction.

Key Takeaway: Model → Endpoint Config → Endpoint is the immutable dependency chain in SageMaker, regardless of whether you use SDK or Boto3.

Question 4 - Multi-Model Endpoint vs Single-Model Endpoint Decision

A SaaS company serving 2,000 customers needs to deploy 500 small customer-specific fraud detection models. Each model receives relatively low traffic individually (~20 requests/hour), but aggregate traffic is steady (~10,000 requests/hour). The company wants to minimize hosting costs while maintaining acceptable inference latency.

Compliance requires that all models must be fully isolated from one another in terms of runtime crashes.

Which hosting strategy should the ML engineer choose? (Select ONE)

  • A) Deploy a dedicated SageMaker endpoint for each of the 500 models to ensure full runtime isolation.
  • B) Deploy all 500 models to a single Multi-Model Endpoint (MME) with a shared instance pool.
  • C) Deploy the models to 10 sharded Multi-Model Endpoints, each hosting 50 models with shared instances.
  • D) Use SageMaker Serverless Inference for all 500 models, each with its own serverless endpoint configuration.
Click to reveal Answer & Explanation

Correct Answer: A

Correct Options Analysis

  • A is Correct: Compliance explicitly requires full runtime isolation. Multi-Model Endpoints share compute instances and memory across multiple models, which means a crash in one model's container can potentially affect co-located models. Dedicated single-model endpoints are the only option that guarantees complete isolation.

Distractor Analysis

  • B is Incorrect: MME shares CPU/memory across models in a single instance pool. While cost-efficient, this violates the strict runtime crash isolation compliance requirement—a misbehaving model could affect others on the same instance.
  • C is Incorrect: Sharded MMEs reduce blast radius but do not provide full isolation; models within the same shard still share compute resources, failing the compliance requirement.
  • D is Incorrect: Serverless inference with individual endpoints provides isolation, but with 500 separate endpoints and cold-start latencies, this becomes operationally impractical and exceeds cost-effectiveness for the workload profile.

Key Takeaway: When compliance mandates strict isolation, cost optimization takes a back seat—dedicated endpoints per model are the only guarantee of runtime separation.

Question 5 - AWS CLI Deployment with Container Registry Authentication

A healthcare data science team needs to deploy a containerized PyTorch model from their on-premises environment to SageMaker using the AWS CLI only. The custom inference container is built locally as a Docker image.

The deployment must verify container integrity, store versioned images, and ensure SageMaker can pull the image with proper authentication. The team wants to minimize manual steps in the deployment process.

Which set of AWS CLI operations should the engineer perform in sequence? (Select ONE)

  • A) Run docker build locally, then use aws sagemaker create-model with a public Docker Hub image URL.
  • B) Build the Docker image, push to Amazon ECR using docker push, and call aws sagemaker create-model referencing the ECR image URI with the execution role attached.
  • C) Build the Docker image, upload the image file to Amazon S3, and call aws sagemaker create-model with the S3 URI.
  • D) Build the Docker image, push to ECR, then call aws sagemaker create-model with a hardcoded ImageUri parameter specifying a public registry.
Click to reveal Answer & Explanation

Correct Answer: B

Correct Options Analysis

  • B is Correct: SageMaker pulls container images from Amazon ECR, not from arbitrary local files or S3. The correct flow is: build empirically, authenticate to ECR using aws ecr get-login-password, push with docker push, and reference the ECR URI in create-model with an execution role that has ecr:BatchGetImage permissions.

Distractor Analysis

  • A is Incorrect: SageMaker cannot pull images directly from public Docker Hub repositories during endpoint creation—it requires images in Amazon ECR (or private registries reachable via VPC endpoints).
  • C is Incorrect: SageMaker does not accept container images as files in S3; only model artifacts (for prebuilt containers) and training data can be stored in S3. Container images must live in a container registry.
  • D is Incorrect: Hardcoding a "public registry" fails the container integrity requirement and does not provide the private, versioned registry that ECR provides. SageMaker execution roles require explicit ecr:BatchGetImage permissions to pull from private ECR repositories.

Key Takeaway: The container image path is always Docker build → ECR push → SageMaker reference with proper IAM pull permissions—S3 is for artifacts, not images.

Question 6 - Programmatic Endpoint with Inference Components

An AI company is deploying a large language model (LLM) that requires GPU acceleration. The model is large (70B parameters) and will serve streaming responses. The team wants to:

  1. Deploy the endpoint using the SageMaker SDK.
  2. Scale model copies independently based on GPU utilization.
  3. Route traffic to specific model checkpoints using Boto3.

The endpoint infrastructure should minimize cold-start latency for burst traffic while controlling GPU costs.

Which configuration should the engineer implement? (Select ONE)

  • A) Use PipelineModel with multiple instances of ml.g5.12xlarge in a single endpoint, manually managing traffic routing.
  • B) Use SageMaker Inference Components attached to a single endpoint, deploying multiple model copies with independent auto-scaling on GPU metrics using Boto3 create_inference_component().
  • C) Deploy each model checkpoint to separate endpoints, each with its own auto-scaling group.
  • D) Use SageMaker Batch Transform jobs invoked on-demand when requests arrive.
Click to reveal Answer & Explanation

Correct Answer: B

Correct Options Analysis

  • B is Correct: SageMaker Inference Components allow multiple models (or model copies) to be deployed to a single SageMaker endpoint with separate compute resource allocations and independent auto-scaling policies based on metrics like GPUUtilization or InvocationsPerCopy. The Boto3 create_inference_component() API provides granular control over each model's placement and scaling.

Distractor Analysis

  • A is Incorrect: PipelineModel is for building preprocessing + model + postprocessing inference pipelines within a single container sequence, not for managing multiple independent model copies with isolated scaling.
  • C is Incorrect: Separate endpoints per checkpoint is operational overhead and fails the GPU cost control requirement—it multiplies infrastructure management without providing the efficiency of shared endpoint infrastructure with isolated scaling.
  • D is Incorrect: Batch Transform is an offline inference method unsuitable for streaming LLM responses; it processes data from S3 to S3 asynchronously without real-time request routing.

Key Takeaway: Inference Components decouple model copies from the endpoint hardware, enabling independent scaling on GPU metrics through both the SageMaker SDK and Boto3 APIs.

Question 7 - SageMaker SDK Model Serve/Debugger Configuration

A machine learning platform team is standardizing model deployment across multiple data science groups. They need to programmatically configure:

  1. A pre-trained XGBoost model for real-time serving.
  2. SageMaker Model Debugger to monitor for training job errors (not inference).
  3. Container health checks that verify the model is loaded before accepting production traffic.

The SDK code must be minimal and follow best practices for reproducibility.

Which SDK implementation should the platform engineer use? (Select ONE)

  • A) Use XGBoostModel with model.deploy(), attach DebuggerHookConfig to the deploy, and use default container health checks.
  • B) Use XGBoostModel with model.deploy(initial_instance_count=1, instance_type='ml.m5.xlarge'), and define a custom container_health_check_config in the SageMaker SDK.
  • C) Use Boto3 create_model() with a hardcoded container URI, then call create_debugger_config() to enable monitoring.
  • D) Use Estimator with DebuggerHookConfig for training, then deploy via deploy() with built-in health checks automatically enabled.
Click to reveal Answer & Explanation

Correct Answer: D

Correct Options Analysis

  • D is Correct: DebuggerHookConfig is a training-time configuration for SageMaker Model Debugger, not a deployment-time setting. The correct SD K flow is: create an Estimator with debugger_hook_config=True for training monitoring, then call deploy() on the trained estimator. SageMaker automatically configures basic health checks for real-time endpoints, requiring no additional deployment code for standard models.

Distractor Analysis

  • A is Incorrect: DebuggerHookConfig cannot be attached to model.deploy()—it is a training configuration for the Estimator or fit() method, not for inference endpoints. Debugger is for monitoring training jobs.
  • B is Incorrect: While container_health_check_config exists in the SageMaker SDK for custom container health checks, this is only necessary for custom inference containers—standard prebuilt XGBoost containers already include built-in health check mechanisms. The key issue is that the question asks about training debugger, not inference debugging.
  • C is Incorrect: create_debugger_config() is not a valid Boto3 API method and Boto3 is overkill for standard estimator training flows that the SDK already supports.

Key Takeaway: SageMaker Debugger is a training-time tool—you configure it in the Estimator, not in the deployment path.

Question 8 - Serialized Model Repacking with SageMaker SDK

A logistics company has trained a Random Forest model using the Python joblib library to create a .joblib file. They need to deploy this model to SageMaker for real-time inference.

The team needs to package the model file so SageMaker's prebuilt Scikit-learn container can serve it. They want to use the SageMaker SDK to minimize manual steps.

Which code snippet correctly packages and deploys the model? (Select ONE)

  • A) Pass the raw .joblib file directly to SKLearnModel and call deploy().
  • B) Use sagemaker.model.Model with entry_point pointing to the .joblib file and call deploy() without any repackaging.
  • C) First repack the .joblib file into a model.tar.gz archive, upload to S3, then pass the S3 path to SKLearnModel and call deploy().
  • D) Use SKLearnModel.model_data with the local .joblib file path directly—the SDK automatically uploads and repackages it.
Click to reveal Answer & Explanation

Correct Answer: C

Correct Options Analysis

  • C is Correct: SageMaker prebuilt containers expect model artifacts to be packaged as a .tar.gz archive containing the model file (and optionally a code/ directory with inference scripts). The flow is: serialize to .joblib → create model.tar.gz (with the .joblib file at root) → upload to S3 → reference the S3 URI in SKLearnModel.model_data → deploy().

Distractor Analysis

  • A is Incorrect: SageMaker prebuilt containers expect model_data to be a gzipped tarball from S3, not a raw .joblib file—passing raw file content fails during container initialization.
  • B is Incorrect: entry_point is for custom inference scripts, not for the model file itself; the model artifact must still be a tar.gz archive in S3.
  • D is Incorrect: The SageMaker SDK does not automatically repackage local model files into the required tar.gz format—it expects model_data to be an S3 URI, not a local file path, and assumes the tar.gz is already properly structured.

Key Takeaway: Always ship model artifacts as model.tar.gz archives in S3—SageMaker prebuilt containers only unpack tar.gz archives, not raw serialized files.

Question 9 - SageMaker Endpoint Encryption Configuration via SDK

A government agency is deploying a text classification model to SageMaker with strict data protection requirements. The compliance framework mandates:

  1. End-to-end encryption for model artifacts.
  2. Traffic encryption between the client and the endpoint (no HTTP).
  3. Model artifacts encrypted at rest using customer-managed KMS keys.

The ML engineer must configure these requirements using the SageMaker SDK.

Which deployment code correctly enforces all three constraints? (Select ONE)

  • A) model.deploy(endpoint_name='gov-classifier', encrypt=True) with a custom VpcConfig and default S3 encryption.
  • B) SKLearnModel(model_data='s3://bucket/model.tar.gz', kms_key='arn:aws:kms:...').deploy(kms_key='arn:aws:kms:...', enable_network_isolation=True).
  • C) XGBoostModel(model_data='s3://bucket/model.tar.gz', kms_key='arn:aws:kms:...', sagemaker_session=sess).deploy(kms_key='arn:aws:kms:...', volume_kms_key='arn:aws:kms:...').
  • D) SKLearnModel(model_data='s3://bucket/model.tar.gz', role=role).deploy(initial_instance_count=1, instance_type='ml.m5.xlarge', enable_network_isolation=True, volume_kms_key='arn:aws:kms:...').
Click to reveal Answer & Explanation

Correct Answer: D

Correct Options Analysis

  • D is Correct: This configuration addresses all three constraints: (1) enable_network_isolation=True prevents traffic from leaving the VPC except through VPC endpoints, ensuring encrypted traffic within VPC; (2) volume_kms_key encrypts the local storage volume where SageMaker copies model artifacts during initialization; (3) the model artifacts in S3 should already be encrypted using KMS (managed separately). SageMaker endpoints always enforce TLS for inference requests via HTTPS.

Distractor Analysis

  • A is Incorrect: encrypt=True is not a valid SageMaker SDK deployment parameter. While VpcConfig enables network isolation, the incorrect parameter and lack of explicit KMS configuration for volumes fails the compliance requirement.
  • B is Incorrect: enable_network_isolation is correct, but kms_key on deploy() is not a valid parameter for endpoint volume encryption. Volume encryption requires volume_kms_key. Additionally, the deploy() method signature does not accept kms_key in the way shown.
  • C is Incorrect: While this correctly specifies kms_key for model artifact decryption (reading from S3) and includes volume_kms_key in deploy, passing kms_key directly to deploy() is redundant—the primary KMS requirement is for volume_kms_key (volume encryption) and the S3-side encryption for artifacts.

Key Takeaway: Remember the SDK's exact parameter names: volume_kms_key encrypts the local endpoint volume, while kms_key in the model constructor is for S3 artifact decryption.

Question 10 - MCU Gemini: Mixed Training and Deployment with Step Functions Orchestration

A large enterprise is orchestrating a complete ML workflow that requires:

  1. Triggering a SageMaker training job programmatically.
  2. Deploying the trained model to a real-time endpoint.
  3. Running a quality validation step that sends inference requests to a shadow endpoint before routing live traffic.
  4. Handling failures with automatic retry and notification to Slack.

The orchestration must be fully automated, serverless where possible, and scalable to monthly retraining schedules. The existing architecture uses AWS Step Functions, Lambda, and SageMaker SDK deployments.

Which Step Functions workflow integration provides the lowest operational overhead for this pipeline? (Select ONE)

  • A) Use a single Lambda function with a long timeout that sequentially invokes training, deployment, validation, and Slack notification APIs using the SageMaker SDK and Boto3.
  • B) Use Step Functions service integrations to call sagemaker:CreateTrainingJob, sagemaker:CreateModel, sagemaker:CreateEndpointConfig, and sagemaker:CreateEndpoint directly from the state machine, with a separate Lambda function for shadow endpoint validation and Slack notification.
  • C) Use AWS Glue jobs triggered by CloudWatch Events to run the training and deployment steps, with a manual approval gate before production traffic routing.
  • D) Use the SageMaker SDK inside an EC2 instance with a cron job that calls training, deployment, and validation APIs sequentially with Python error handling.
Click to reveal Answer & Explanation

Correct Answer: B

Correct Options Analysis

  • B is Correct: Step Functions provides direct service integrations (optimized integrations) with SageMaker APIs, eliminating the need for custom Lambda functions to invoke training and deployment. This reduces operational overhead, provides built-in retry/error handling (via Retry and Catch blocks), and enables visual workflow monitoring. The shadow validation step naturally fits as a Lambda function step with a Retry policy and a SNS/Slack notification step for failures.

Distractor Analysis

  • A is Incorrect: A single monolithic Lambda function with a "long timeout" creates a single point of failure, is difficult to debug step-by-step, and cannot gracefully handle independent step retries. Lambda's maximum timeout (15 minutes) may also be exceeded during long training jobs—though you could invoke asynchronously, the synchronous orchestration approach is architecturally weak.
  • C is Incorrect: AWS Glue jobs are designed for ETL transformations, not ML workflow orchestration. Manual approval gates for every retraining cycle introduce human dependency and violate the fully automated requirement.
  • D is Incorrect: EC2 cron jobs require infrastructure management (patching, scaling, monitoring), fail the serverless requirement, and provide no built-in retry/error handling or workflow visualization compared to Step Functions.

Key Takeaway: Step Functions direct SageMaker integrations eliminate Lambda glue code for ML orchestration—use service integrations with built-in retry policies for production ML pipelines.

Question 11 - SageMaker SDK RegisterModel for Inference Pipeline

A manufacturing company has developed a two-stage inference pipeline:

  1. A preprocessing step (custom Scikit-learn transformer for feature engineering).
  2. A PyTorch model for anomaly detection.

Both components need to be deployed as a seamless pipeline where SageMaker automatically chains the input/output between containers. The team needs to programmatically register this pipeline in SageMaker Model Registry for version tracking and approval workflows.

Which SageMaker SDK API should the engineer use? (Select ONE)

  • A) sagemaker.pipeline.PipelineModel with both containers listed in sequence, then call register() to add it to the Model Registry.
  • B) sagemaker.model.Model with a single combined container that includes both preprocessing code and the PyTorch model, then call register().
  • C) sagemaker.pipeline.InferencePipeline with both models chained, then call create_model() to register in Model Registry.
  • D) Create two separate models and endpoints, connected via a Lambda function that handles data flow between them, then register both in Model Registry.
Click to reveal Answer & Explanation

Correct Answer: A

Correct Options Analysis

  • A is Correct: PipelineModel in the SageMaker SDK is designed for sequential inference pipelines, where multiple containers (preprocessing, inference, postprocessing) are deployed as a single endpoint. The register() method on the pipeline model adds it to SageMaker Model Registry, enabling version tracking and approval workflows.

Distractor Analysis

  • B is Incorrect: Combining preprocessing and inference into a single container is a valid pattern, but it defeats the purpose of modular, reusable pipeline components. The question explicitly specifies a two-stage pipeline, and PipelineModel is the correct abstraction for chaining separate containers.
  • C is Incorrect: InferencePipeline is not the correct class name in the SageMaker SDK. The correct class is PipelineModel. Even if create_model() were called, this option confuses SDK class names.
  • D is Incorrect: Using Lambda functions to orchestrate data flow between separate endpoints introduces network latency, additional operational complexity, and violates the "seamless pipeline" requirement where SageMaker inherently chains containers.

Key Takeaway: Use PipelineModel for multi-container inference chains in a single endpoint; the register() method adds the complete pipeline to Model Registry with one call.

Question 12 - AWS CLI for Model Registry Management and Approval

A fintech company's compliance policy requires a manual approval step before any model moves to production. The MLOps team uses SageMaker Model Registry to track model versions and needs to programmatically:

  1. List all pending (unapproved) model package versions.
  2. Approve a specific model package version for production.
  3. Update the model package's deployment status.

They are constrained to using only the AWS CLI (no Python SDK) in their CI/CD pipeline.

Which set of CLI commands should the engineer use? (Select ONE)

  • A) aws sagemaker list-models --status Pending then aws sagemaker approve-model --model-name <name> then aws sagemaker update-model --status Approved
  • B) aws sagemaker list-model-packages --model-package-group-name <group> then aws sagemaker update-model-package --model-package-arn <arn> --model-approval-status Approved then optionally aws sagemaker update-model-package --model-package-arn <arn> --customer-metadata '{"deploymentStatus":"Production"}'
  • C) aws sagemaker describe-endpoint --endpoint-name <name> then aws sagemaker update-endpoint --endpoint-config-name <config> --approval-status Approved
  • D) aws sagemaker list-pipelines then aws sagemaker approve-pipeline --pipeline-name <name>
Click to reveal Answer & Explanation

Correct Answer: B

Correct Options Analysis

  • B is Correct: The SageMaker Model Registry CLI API uses: (1) list-model-packages to enumerate all package versions under a model package group; (2) update-model-package with --model-approval-status Approved to approve a pending version; (3) update-model-package again with --customer-metadata to add deployment tracking metadata like production status.

Distractor Analysis

  • A is Incorrect: list-models lists models, not model packages from the registry. approve-model is a non-existent API. The approval workflow uses update-model-package with --model-approval-status, not a separate approve command.
  • C is Incorrect: describe-endpoint and update-endpoint operate on real-time endpoints, not Model Registry approval status. Model approval happens at the model package level before endpoint deployment.
  • D is Incorrect: list-pipelines and approve-pipeline relate to SageMaker Pipelines (workflow orchestration), not Model Registry model package approval workflows.

Key Takeaway: In the AWS CLI, model approval uses update-model-package --model-approval-status Approved—there is no separate "approve" verb.

Question 13 - SageMaker SDK Async Inference Deployment

A legal document processing platform needs to deploy a model for scanning lengthy PDF documents. Each inference request can take 5–15 minutes due to OCR and NLP processing. The frontend submits document URLs and expects results asynchronously, with support for querying job status.

The ML engineer must use the SageMaker SDK to deploy an asynchronous endpoint that can handle up to 5,000 concurrent requests in a queue, auto-scaling based on queue depth.

Which deployment code correctly configures this? (Select ONE)

  • A) model.deploy(endpoint_name='legal-async', async_inference=True) with default payload limits.
  • B) AsyncInferenceConfig(output_path='s3://legal-output-bucket/', max_concurrent_invocations_per_instance=10, notification_config=...).attach() to model.deploy().
  • C) model.deploy(real_time=False, batch_size=100) to create a batch transform job.
  • D) model.deploy(endpoint_name='legal-async', initial_instance_count=2, instance_type='ml.m5.4xlarge') with a Lambda function polling the endpoint.
Click to reveal Answer & Explanation

Correct Answer: B

Correct Options Analysis

  • B is Correct: SageMaker Asynchronous Inference is designed for long-running inference requests (up to 15 minutes per request). The AsyncInferenceConfig in the SDK specifies the S3 output location, maximum concurrent invocations per instance (queue depth control), and optional SNS notification configuration. This config is attached to model.deploy() using async_inference_config=.

Distractor Analysis

  • A is Incorrect: async_inference=True is not a valid parameter in the SageMaker SDK. Asynchronous inference requires the explicit AsyncInferenceConfig object.
  • C is Incorrect: This creates a Batch Transform job, which is offline processing—not an asynchronous endpoint that accepts individual requests and provides job status querying.
  • D is Incorrect: This creates a standard real-time endpoint with a Lambda function polling—not the correct architecture for asynchronous inference. Polling a real-time endpoint with a Lambda is an anti-pattern and doesn't provide the built-in queueing, auto-scaling, and output management of SageMaker Async Inference.

Key Takeaway: SageMaker Async Inference is the right tool for requests exceeding 60-second timeouts—configure with AsyncInferenceConfig specifying output S3 location and concurrency limits.

Question 14 - Boto3 vs AWS CLI for Multi-Environment Deployment Strategy

A large enterprise manages SageMaker resources across 5 AWS accounts (dev, test, staging, prod, compliance). The MLOps team needs to deploy the same model endpoint to each environment using environment-specific parameter overrides (instance types, endpoint names, KMS keys).

The deployment pipeline is written in Python and must support:

  • Conditional deploy based on environment (e.g., skip compliance account if model is Python 3.6).
  • Programmatic error handling with try/catch.
  • Clean separation of configuration from code.

Which combination of tools provides the most maintainable approach? (Select ONE)

  • A) Use AWS CLI scripts with environment-specific shell variables, invoking aws sagemaker create-endpoint with different parameter sets per shell script.
  • B) Use Boto3 in Python with environment-specific configuration files (JSON/YAML), calling boto3.client('sagemaker').create_endpoint() with parameters loaded from config.
  • C) Use the SageMaker SDK with hardcoded environment logic in Python, relying on CI/CD environment variables to modify behavior.
  • D) Use AWS CDK with environment-specific stacks in TypeScript, calling CfnEndpoint constructs for each account.
Click to reveal Answer & Explanation

Correct Answer: B

Correct Options Analysis

  • B is Correct: Boto3 in Python provides programmatic control (try/catch for error handling), and loading parameters from JSON/YAML configuration files cleanly separates environment-specific values from the deployment logic. This enables conditional deployment and multi-account management with clear maintainability.

Distractor Analysis

  • A is Incorrect: Shell scripts with environment variables are less maintainable at scale—error handling is limited, configuration is entangled with logic, and conditional deployment logic becomes complex and brittle across 5 environments.
  • C is Incorrect: The SageMaker SDK is convenient, but hardcoding environment logic in Python couples configuration to code—violating the "clean separation" requirement and making it difficult to review environment differences in isolation.
  • D is Incorrect: While CDK is excellent for infrastructure-as-code, the question emphasizes Python-based deployment with programmatic error handling. CDK with CfnEndpoint requires TypeScript (or Python CDK), but the requirement for "Python-based deployment pipeline" and try/catch error handling aligns better with Boto3's programmatic nature.

Key Takeaway: For multi-environment programmatic deployments, pair Boto3's error handling with external configuration files—keep environment parameters out of code.