Skill 3.1.5: Deploy models that were built outside of AWS into AWS environments (for example, Amazon SageMaker AI, Amazon Bedrock Custom Model Import)
| Question | Answer & Explanation |
|---|---|
| ### Question 1 - Bedrock Custom Model Import for On-Premises Fine-Tuned LLMs An AI team has fine-tuned a Llama 3 8B model using their own GPUs in an on-premises data center. The resulting model weights and artifacts are stored in an Amazon S3 bucket. The team wants to serve this custom model for real-time text generation without provisioning or managing any underlying compute instances or endpoints. Compliance policies require that the model is accessed through a standardized, serverless API provided by AWS. Which approach should the team take? (Select ONE) - A) Use Amazon Bedrock Custom Model Import to import the model artifacts from S3 and serve it using the Bedrock InvokeModel API.- B) Package the model artifacts into a Docker container and deploy a SageMaker Real-Time Endpoint with auto-scaling. - C) Deploy the model to a SageMaker Serverless Endpoint using a custom inference container. - D) Use SageMaker JumpStart to deploy the fine-tuned model artifacts. |
Correct Answer: A Correct Option Analysis: - A is Correct: Amazon Bedrock Custom Model Import allows you to import supported open-weight foundation models (like Llama 3) that were customized externally. Once imported, Bedrock hosts the model on serverless infrastructure, exposing it through the standard InvokeModel or Converse APIs without requiring the team to manage endpoints or instances.Distractor Analysis: - B is Incorrect: Deploying a SageMaker Real-Time Endpoint requires the team to provision and manage compute instances, violating the constraint of not managing underlying compute. - C is Incorrect: While SageMaker Serverless manages the compute, it requires packaging a custom inference container, which introduces unnecessary operational overhead compared to Bedrock's managed import for supported foundation models. - D is Incorrect: SageMaker JumpStart is a catalog of pre-trained models, not a mechanism to deploy externally fine-tuned custom weights. > Exam Tip: Use Amazon Bedrock Custom Model Import when you have an externally fine-tuned open-weight foundation model (like Llama or Mistral) and want to serve it via the serverless Bedrock API without managing endpoints. |
| ### Question 2 - Using Prebuilt SageMaker Containers for External PyTorch Models A machine learning engineering team built a custom PyTorch recommendation model outside of AWS. The model artifacts are currently stored in an Amazon S3 bucket. The team needs to deploy this model to an Amazon SageMaker AI Real-Time Endpoint with the least operational overhead. They do not want to write a custom Docker container from scratch. Which approach should they take? (Select ONE) - A) Use the prebuilt SageMaker PyTorch Deep Learning Container (DLC) and configure the entry_point with an inference script.- B) Use Amazon Bedrock Custom Model Import to serve the custom recommendation model. - C) Build a custom Docker container using the sagemaker-inference toolkit and deploy it to SageMaker.- D) Deploy the model using SageMaker Batch Transform with a custom container. |
Correct Answer: A Correct Option Analysis: - A is Correct: For custom ML models (like PyTorch) trained outside of AWS, SageMaker AI provides prebuilt Deep Learning Containers (DLCs) that already include the framework and necessary serving stacks. The team only needs to provide the model artifacts and an inference.py script as the entry_point, satisfying the "least operational overhead" constraint.Distractor Analysis: - B is Incorrect: Bedrock Custom Model Import is strictly for supported open-weight foundation model architectures, not custom recommendation models built from scratch in PyTorch. - C is Incorrect: Building a custom Docker container introduces unnecessary operational overhead since AWS already provides a maintained PyTorch DLC. - D is Incorrect: Batch Transform is for offline processing of static datasets, not real-time inference via an endpoint. > Exam Tip: When deploying externally trained traditional ML or deep learning models to SageMaker, always check if a prebuilt Deep Learning Container (DLC) exists for your framework to avoid writing custom Docker code. |
| ### Question 3 - Deploying On-Premises XGBoost Models with Minimal Code A company has an XGBoost model that was trained entirely on their on-premises infrastructure. The model artifact is a model.tar.gz file containing the serialized model. They want to deploy this model on Amazon SageMaker AI using the least amount of custom code, leveraging managed infrastructure.Which approach should they take? (Select ONE) - A) Use Amazon Bedrock Custom Model Import to import the XGBoost model. - B) Write a custom Docker container with a Flask web server to handle inference requests. - C) Use the prebuilt SageMaker XGBoost container and point it to the model artifacts in Amazon S3. - D) Host the model on an Amazon EC2 instance with a custom API gateway. |
Correct Answer: C Correct Option Analysis: - C is Correct: SageMaker AI provides a prebuilt XGBoost container. For standard serialized XGBoost models, you can simply point the prebuilt container to your model.tar.gz in S3 without writing any custom serving code, minimizing operational overhead.Distractor Analysis: - A is Incorrect: Bedrock Custom Model Import does not support traditional ML algorithms like XGBoost; it is limited to specific foundation model architectures. - B is Incorrect: Writing a custom Flask server and Docker container is unnecessary because SageMaker's prebuilt XGBoost container already handles the serving logic. - D is Incorrect: Hosting on EC2 requires the team to manage the underlying OS, instance scaling, and API infrastructure, resulting in the highest operational overhead. > Exam Tip: For algorithms like XGBoost, scikit-learn, or built-in SageMaker algorithms, use the prebuilt containers and simply provide the model.tar.gz file from S3. |
| ### Question 4 - Validating Architectures for Bedrock Custom Model Import An enterprise has customized an open-weight Mistral 7B model using Amazon EC2 P5 instances. The model weights are saved in the .safetensors format in an Amazon S3 bucket. The team wants to deploy this model into Amazon Bedrock. However, they need to ensure that the imported model meets the service's requirements for supported architectures and formats before attempting the import.Which AWS service or feature should they use to validate and import this model? (Select ONE) - A) SageMaker JumpStart - B) Amazon Bedrock Custom Model Import - C) Amazon Bedrock Provisioned Throughput - D) Amazon SageMaker Inference Recommender |
Correct Answer: B Correct Option Analysis: - B is Correct: Amazon Bedrock Custom Model Import is the specific feature designed to bring externally customized open-weight models (such as Mistral 7B) into Bedrock. The service validates that the model architecture and file format (like .safetensors) are supported during the import process from S3.Distractor Analysis: - A is Incorrect: SageMaker JumpStart is a hub for deploying pre-existing models to SageMaker endpoints, not for importing custom weights into Bedrock. - C is Incorrect: Provisioned Throughput is a billing/capacity mechanism for Bedrock models, not a feature for importing external model weights. - D is Incorrect: SageMaker Inference Recommender helps find the optimal instance types and configurations for SageMaker endpoints, not for Bedrock imports. > Exam Tip: Bedrock Custom Model Import validates supported architectures (e.g., Llama, Mistral) and requires uncompressed raw weights in S3, differing from SageMaker's model.tar.gz requirement. |
| ### Question 5 - Handling Custom System Dependencies for Externally Trained Models A machine learning engineer is deploying a custom TensorFlow model that was trained outside of AWS. The model requires specific system-level dependencies (like a custom C++ library) that are not available in the prebuilt SageMaker TensorFlow containers. The model will be served via a SageMaker Real-Time Endpoint. Which approach satisfies these requirements with the most appropriate level of customization? (Select ONE) - A) Extend the prebuilt SageMaker TensorFlow Deep Learning Container (DLC) to install the custom C++ library and push the image to Amazon ECR. - B) Use Amazon Bedrock Custom Model Import to package and serve the model with the custom library. - C) Use SageMaker Inference Recommender to automatically generate a container with the custom library. - D) Deploy the model to a SageMaker Serverless Endpoint, which automatically handles custom system-level dependencies. |
Correct Answer: A Correct Option Analysis: - A is Correct: When an externally trained model requires custom system-level dependencies not found in the prebuilt containers, the best practice is to extend the prebuilt SageMaker DLC by adding a Dockerfile layer that installs the required libraries, then push it to Amazon ECR for SageMaker to use. Distractor Analysis: - B is Incorrect: Bedrock Custom Model Import does not support custom system-level libraries or arbitrary execution environments; it only imports standard foundation model weights. - C is Incorrect: Inference Recommender evaluates instance performance; it does not automatically generate custom Docker containers with system libraries. - D is Incorrect: SageMaker Serverless Endpoints do not allow custom system-level Docker configurations; they only support standard prebuilt containers. > Exam Tip: If your model needs custom OS-level dependencies, extend a prebuilt SageMaker DLC and host it in ECR. Do not try to use Serverless or Bedrock for custom environment requirements. |
| ### Question 6 - Serverless Deployment for Infrequent Scikit-Learn Requests An organization has trained a custom regression model using scikit-learn on their local machines. The model is saved as a model.pkl file. They want to deploy this model to AWS with minimal infrastructure management, without writing a custom serving container. The model will receive infrequent requests with long idle periods, and cost optimization is a primary constraint.Which deployment option meets these requirements? (Select ONE) - A) Use Amazon Bedrock Custom Model Import to host the scikit-learn model via the Bedrock API. - B) Package the model artifacts into a tarball and deploy it to a SageMaker Serverless Endpoint using the prebuilt SageMaker Scikit-Learn container. - C) Deploy the model to a SageMaker Real-Time Endpoint with a high instance count to handle bursts. - D) Use SageMaker Batch Transform to process the infrequent requests as they arrive. |
Correct Answer: B Correct Option Analysis: - B is Correct: SageMaker Serverless Inference is ideal for infrequent, bursty traffic with long idle periods (scaling to zero to save costs). By using the prebuilt SageMaker Scikit-Learn container, the team avoids writing custom Docker code while meeting the cost and operational constraints. Distractor Analysis: - A is Incorrect: Bedrock Custom Model Import is strictly for foundation models, not scikit-learn algorithms. - C is Incorrect: A Real-Time Endpoint keeps instances continuously running, which violates the cost optimization constraint for long idle periods. - D is Incorrect: Batch Transform requires pre-assembled static datasets in S3, not individual dynamic requests arriving infrequently. > Exam Tip: For intermittent traffic with long idle periods, use SageMaker Serverless Inference with a prebuilt container to minimize costs and operational overhead. |
| ### Question 7 - Deploying Hugging Face BERT with Managed Containers A data scientist has fine-tuned a Hugging Face BERT model outside of AWS and saved the weights in Amazon S3. The team needs to deploy this model to Amazon SageMaker AI for real-time inference. To optimize performance and reduce operational overhead, they want to use an AWS-provided container that already supports the Hugging Face Transformers library. Which container should they use? (Select ONE) - A) The SageMaker Hugging Face Deep Learning Container (DLC). - B) The SageMaker TensorFlow Deep Learning Container (DLC). - C) A generic Python Docker container built from scratch. - D) Amazon Bedrock Custom Model Import. |
Correct Answer: A Correct Option Analysis: - A is Correct: SageMaker provides specialized Deep Learning Containers (DLCs) specifically built for Hugging Face Transformers. This container natively supports loading and serving models from the Hugging Face library, minimizing operational overhead. Distractor Analysis: - B is Incorrect: While BERT uses TensorFlow or PyTorch under the hood, the generic TensorFlow DLC lacks the pre-installed Hugging Face transformers library and serving logic natively optimized for BERT.- C is Incorrect: Building a container from scratch contradicts the requirement to reduce operational overhead by using an AWS-provided container. - D is Incorrect: Bedrock Custom Model Import is for large generative foundation models, not for importing standard encoder models like BERT. > Exam Tip: SageMaker offers dedicated Hugging Face DLCs (for both PyTorch and TensorFlow backends) to easily deploy externally trained Transformer models without writing custom environment setups. |
| ### Question 8 - Asynchronous Inference for Large Payloads and Long Processing An AI company has an externally trained custom deep learning model that takes input payloads of approximately 2 GB and requires up to 5 minutes to process a single request. The model must be deployed to Amazon SageMaker AI. The callers of this model do not need to be blocked waiting for a synchronous response, and the solution must minimize costs during idle periods. Which deployment strategy should the ML engineer use? (Select ONE) - A) Deploy the model to a SageMaker Real-Time Endpoint and configure the timeout to 5 minutes. - B) Deploy the model to a SageMaker Asynchronous Endpoint and configure it to scale to zero instances when idle. - C) Deploy the model to a SageMaker Serverless Endpoint. - D) Use Amazon Bedrock Custom Model Import to serve the large payloads asynchronously. |
Correct Answer: B Correct Option Analysis: - B is Correct: SageMaker Asynchronous Inference handles large payloads (up to 1GB for standard, but handles queueing for long processing times) and processes requests without blocking the caller. Crucially, it supports scaling the instance count to zero during idle periods, meeting the cost minimization constraint. Distractor Analysis: - A is Incorrect: Real-Time Endpoints enforce a strict 60-second timeout and cannot scale to zero natively without advanced Inference Component configurations, making them unsuitable for 5-minute processing and cost minimization. - C is Incorrect: SageMaker Serverless Endpoints have a strict 60-second execution timeout and a payload limit of 6 MB, failing both the payload and processing time constraints. - D is Incorrect: Bedrock Custom Model Import does not support custom externally trained deep learning models outside its specific architecture list, nor does it handle 2 GB custom payloads in this manner. > Exam Tip: For large payloads and long processing times (up to 15 minutes) where callers are unblocked, use SageMaker Asynchronous Endpoints to leverage queueing and scale-to-zero capabilities. |
| ### Question 9 - Model Artifact Formatting for Bedrock Custom Model Import A company wants to import a custom foundation model into Amazon Bedrock. The model was fine-tuned externally and consists of multiple files, including model weights and a tokenizer configuration. The ML engineer must package these artifacts and upload them to Amazon S3 to prepare for the Bedrock Custom Model Import process. What is the required format and structure for the model artifacts in Amazon S3 for a successful Bedrock Custom Model Import? (Select ONE) - A) A single zipped Docker image containing the model weights and a Flask inference script. - B) A model.tar.gz archive containing a code/ directory with an inference.py script.- C) An uncompressed directory structure containing the raw model weights (e.g., .safetensors or .bin) and associated tokenizer files in the root.- D) A .zip file containing the model weights in Hugging Face format and a requirements.txt file for dependency management. |
Correct Answer: C Correct Option Analysis: - C is Correct: Unlike SageMaker which typically uses model.tar.gz archives, Amazon Bedrock Custom Model Import requires you to upload the uncompressed model artifacts directly to an S3 bucket. This includes the raw weight files (like .safetensors) and tokenizer configurations in the standard Hugging Face layout.Distractor Analysis: - A is Incorrect: Bedrock Custom Model Import does not use Docker images; it relies on native support for specific open-weight architectures. - B is Incorrect: model.tar.gz with inference.py is the format required for SageMaker AI custom models, not Bedrock Custom Model Import.- D is Incorrect: You do not need to zip the files or provide a requirements.txt for Bedrock Custom Model Import; the service expects uncompressed weights and handles the serving environment natively.> Exam Tip: Remember the packaging difference: SageMaker expects a model.tar.gz file, while Bedrock Custom Model Import expects uncompressed raw model weights and tokenizers directly in S3. |
| ### Question 10 - Maximum Control for Proprietary ML Frameworks A global retail company has developed a custom forecasting model using a proprietary framework that is not natively supported by Amazon SageMaker prebuilt containers. The model was trained on an on-premises cluster. They want to deploy this model on AWS for production traffic and require full control over the underlying operating system and model serving environment to install specific custom drivers. Which AWS deployment option provides the MOST control over the environment while still allowing the model to be served? (Select ONE) - A) Use Amazon Bedrock Custom Model Import to leverage the serverless Bedrock infrastructure. - B) Deploy the model using a custom Docker container on Amazon SageMaker AI Real-Time Endpoints. - C) Use Amazon SageMaker JumpStart to find a similar prebuilt model and fine-tune it. - D) Package the model as an AWS Lambda function triggered by Amazon API Gateway. |
Correct Answer: B Correct Option Analysis: - B is Correct: When an externally trained model relies on a proprietary framework requiring custom OS-level drivers, the best approach on AWS is to build a completely custom Docker container. Hosting this custom container on a SageMaker Real-Time Endpoint provides managed scaling and serving infrastructure while granting full control over the OS and environment inside the container. Distractor Analysis: - A is Incorrect: Bedrock Custom Model Import only supports specific open-weight foundation model architectures and provides zero control over the underlying OS or drivers. - C is Incorrect: SageMaker JumpStart only offers pre-existing models, not deployment paths for proprietary custom frameworks. - D is Incorrect: AWS Lambda has strict size limits (10 GB unzipped container image) and execution timeouts (15 minutes), making it unsuitable for full control over OS drivers and production ML serving environments. > Exam Tip: If a model requires proprietary drivers or a completely custom environment not found in AWS prebuilt containers, build a custom Docker container and host it on SageMaker AI. |