3.1.7

Question	Answer & Explanation
### Question 1 - Bedrock Custom Model Import vs. SageMaker Hosting An AI research team has fine-tuned an open-weight foundation model (Llama 3) in their own on-premises training environment. They want to deploy this customized model into AWS so that internal applications can invoke it via a managed API. The deployment must have the lowest operational overhead and eliminate the need to manage any underlying inference instances or container deployments. Which AWS service should the team use to fulfill these requirements? (Select ONE) - A) Package the model artifacts into a SageMaker-compatible container and deploy it to an Amazon SageMaker AI real-time endpoint. - B) Use Amazon Bedrock Custom Model Import to import the customized model artifacts from Amazon S3 into Amazon Bedrock. - C) Deploy the model on an Amazon EC2 instance equipped with GPUs and expose a custom API endpoint via Amazon API Gateway. - D) Use Amazon SageMaker JumpStart to deploy a pretrained Llama 3 model and apply the fine-tuning weights at runtime.	Correct Answer: B Correct Option Analysis: - B is Correct: Amazon Bedrock Custom Model Import allows customers to import supported open-weight foundation models that were customized externally (e.g., on-premises or on EC2) into Amazon Bedrock. Once imported, the model is hosted serverlessly by Bedrock and accessed via the standard InvokeModel API, completely eliminating the need to manage endpoints or instances. Distractor Analysis: - A is Incorrect: Deploying to a SageMaker AI real-time endpoint requires the team to select instance types, configure auto-scaling, and manage the endpoint infrastructure, which violates the lowest operational overhead constraint. - C is Incorrect: Deploying on Amazon EC2 requires the highest level of operational overhead, including OS patching, GPU driver installation, and capacity management. - D is Incorrect: SageMaker JumpStart deploys base pretrained models. It does not natively support applying externally fine-tuned weights at runtime without packaging them into a custom container. > Exam Tip: Bedrock Custom Model Import is the go-to solution for serving externally customized open-weight models via a fully managed API without endpoint management.
### Question 2 - Serverless vs. Real-Time Inference An enterprise HR department is launching an internal ML-powered chatbot that answers employee policy questions. Traffic is highly unpredictable, consisting of short bursts of activity during onboarding days followed by weeks of complete inactivity. The latency tolerance for responses is lenient (a few seconds delay is acceptable). The company mandates a most cost-effective solution with zero operational overhead for managing instances. Which inference option is the MOST appropriate for this workload? (Select ONE) - A) Deploy the model on a SageMaker AI real-time endpoint with Auto Scaling configured to scale to zero instances. - B) Deploy the model on a SageMaker AI serverless endpoint. - C) Deploy the model on an Asynchronous SageMaker AI endpoint. - D) Run a daily Batch Transform job that pre-computes answers for all possible policy questions.	Correct Answer: B Correct Option Analysis: - B is Correct: SageMaker AI Serverless Inference is explicitly designed for intermittent, bursty traffic with extended idle periods. It automatically provisions compute on demand, scales to zero when not in use (so you don't pay for idle time), and requires no instance management. The lenient latency requirement accommodates potential cold starts. Distractor Analysis: - A is Incorrect: Real-time endpoints cannot truly scale to zero instances while remaining available; scaling an endpoint to zero instances will cause invocation requests to fail until a new instance is provisioned. They are also meant for steady, low-latency traffic. - C is Incorrect: Asynchronous inference is designed for large payloads (up to 1GB) or long processing times (up to 15-60 minutes), not for lightweight, interactive chatbot responses. - D is Incorrect: Batch transform is for offline processing of pre-assembled datasets, not for interactive, dynamic user queries. > Exam Tip: Use SageMaker Serverless Inference for workloads with long idle periods where cold starts are acceptable, to minimize cost and operational overhead.
### Question 3 - Asynchronous Inference Use Cases A media processing company is building an ML pipeline to analyze large video files for restricted content. The files arrive individually throughout the day from an S3 bucket, each ranging from 500 MB to 1 GB. Each video takes approximately 5 to 10 minutes to process. No user is blocked waiting for the response, and the system must be able to scale down to zero during periods with no uploads to optimize costs. Which SageMaker AI inference strategy should the company use? (Select ONE) - A) Real-Time Endpoint with a high memory instance type. - B) Serverless Endpoint with provisioned concurrency. - C) Asynchronous Inference Endpoint. - D) Batch Transform Job triggered by S3 Event Notifications.	Correct Answer: C Correct Option Analysis: - C is Correct: SageMaker Asynchronous Inference supports large payloads (up to 1 GB) and long processing times (up to 15-60 minutes). It queues incoming requests, immediately returns a 202 Accepted response, processes the video asynchronously, and scales the instance count down to zero when the queue is empty. Distractor Analysis: - A is Incorrect: Real-time endpoints enforce a 60-second timeout limit and have a payload limit of 6 MB. They also cannot scale to zero without causing invocation failures. - B is Incorrect: Serverless endpoints are capped at a 60-second execution time and a 100 MB payload size, making them unsuitable for 5-10 minute processing of 1 GB files. - D is Incorrect: While S3 triggers could start a Batch Transform job, Batch Transform is optimized for processing large, pre-assembled datasets in bulk rather than processing individual files dynamically as they arrive one by one. > Exam Tip: Asynchronous Inference is the only SageMaker option that supports payloads >6MB, processing times >60 seconds, AND scales to zero.
### Question 4 - Bedrock Provisioned Throughput A financial services firm is running a high-frequency trading analysis application using a custom model fine-tuned inside Amazon Bedrock. During market hours, the application sends thousands of concurrent requests per second and has a strict Service Level Agreement (SLA) demanding sub-second latencies. The team cannot afford any request throttling or performance degradation due to capacity limits. How should the team configure the model invocation to guarantee performance and comply with the SLA? (Select ONE) - A) Invoke the model using standard On-Demand capacity. - B) Purchase Provisioned Throughput for the customized Bedrock model. - C) Export the Bedrock model and deploy it on a SageMaker Real-Time Endpoint. - D) Use Bedrock Custom Model Import to re-import the model for on-demand invocation.	Correct Answer: B Correct Option Analysis: - B is Correct: Amazon Bedrock Provisioned Throughput reserves dedicated model processing capacity (measured in model units) for a specific base or custom model. This guarantees that the application has the required throughput to handle high concurrency without facing throttling or latency degradation during peak hours. Distractor Analysis: - A is Incorrect: On-Demand capacity is shared across all AWS accounts and is subject to rate limits (throttling) during periods of high demand, which violates the strict SLA. - C is Incorrect: Exporting a Bedrock-customized model to SageMaker is not a natively supported workflow for bypassing throughput limits, and it introduces significant operational overhead to manage the endpoint. - D is Incorrect: Custom Model Import is used to bring externally trained models into Bedrock. A model customized inside Bedrock must be served through Provisioned Throughput, not re-imported. > Exam Tip: For strict SLAs and guaranteed capacity on Bedrock, use Provisioned Throughput. On-Demand is for flexible, fault-tolerant workloads.
### Question 5 - Multi-Model vs. Multi-Container Endpoints An e-commerce platform hosts 500 different product recommendation models. All models use the exact same XGBoost framework and have similar memory footprints. 10 models receive constant, high-traffic invocations, while the remaining 490 models are accessed infrequently (a few times a month). The company wants to minimize infrastructure costs and consolidate endpoints. Which deployment strategy is the MOST cost-effective? (Select ONE) - A) Deploy 500 separate SageMaker Real-Time Endpoints. - B) Deploy a single SageMaker Multi-Model Endpoint (MME). - C) Deploy a SageMaker Multi-Container Endpoint with 15 containers. - D) Deploy a single SageMaker Serverless Endpoint.	Correct Answer: B Correct Option Analysis: - B is Correct: A Multi-Model Endpoint (MME) hosts multiple models on a single compute fleet using a shared serving container. It dynamically loads models from S3 into memory as they are requested. Frequently used models stay in memory, while rarely used models incur a cold-start load penalty on invocation. This drastically reduces idle infrastructure costs for 500 models. Distractor Analysis: - A is Incorrect: Deploying 500 separate real-time endpoints would mean paying for 500 instances continuously, resulting in massive idle costs for the 490 infrequently used models. - C is Incorrect: Multi-Container Endpoints (MCE) are designed for deploying up to 15 different containers (e.g., different frameworks or an inference pipeline) on one endpoint, not for scaling hundreds of models of the same framework. - D is Incorrect: SageMaker Serverless Endpoints do not support multi-model hosting. > Exam Tip: Use Multi-Model Endpoints (MME) when hosting many models that share the same framework to save costs, accepting load penalties for infrequently used models.
### Question 6 - Real-Time Endpoint Scale-to-Zero Behavior A startup is deploying a lightweight sentiment analysis model on a SageMaker AI Real-Time Endpoint using Inference Components to optimize costs. To save money during off-hours, they configure an Auto Scaling policy that scales the instance count down to zero when CPU utilization is low. The next morning, a user attempts an inference request before the Auto Scaling policy has a chance to provision a new instance. What will be the immediate behavior of the application when this request is submitted? (Select ONE) - A) The request is automatically placed in an internal queue and processed once the instance provisions. - B) The request fails and returns an error (e.g., 503 Service Unavailable) until a new instance is in service. - C) The request triggers an S3 Event Notification that starts a Batch Transform job. - D) The request succeeds immediately but with significantly higher latency due to cold start.	Correct Answer: B Correct Option Analysis: - B is Correct: If a SageMaker Real-Time Endpoint scales its instance count to zero, it cannot serve any inference requests. Any invocation attempt made while capacity is zero will fail and return an error (like a 503) until Auto Scaling provisions at least one instance. Distractor Analysis: - A is Incorrect: Real-time endpoints do not have a built-in queue to hold requests when capacity is zero. (Asynchronous endpoints do have a managed queue). - C is Incorrect: S3 Event Notifications and Batch Transform are separate architectural patterns; a real-time endpoint failure does not automatically trigger them. - D is Incorrect: A real-time endpoint cannot process a request with cold start latency if there are zero instances; there is no compute to execute the code. The request simply fails. > Exam Tip: Real-Time Endpoints scaling to zero will drop requests. Use Asynchronous Inference if you need queueing and scale-to-zero capabilities.
### Question 7 - Batch Transform for Bulk Processing A logistics company receives a consolidated file every night at 2:00 AM containing millions of shipping records that need route optimization predictions. The ML model must process all records and write the predictions back to an S3 bucket so a downstream dashboard can consume them by 6:00 AM. The company wants to pay only for the compute time used and avoid maintaining standing endpoints. Which deployment strategy is the MOST appropriate? (Select ONE) - A) Deploy a SageMaker Asynchronous Inference Endpoint. - B) Deploy a SageMaker Serverless Endpoint. - C) Configure a SageMaker Batch Transform Job. - D) Deploy a SageMaker Real-Time Endpoint with a scheduled auto-scaling policy.	Correct Answer: C Correct Option Analysis: - C is Correct: SageMaker Batch Transform is designed exactly for this scenario: processing large, pre-assembled static datasets in bulk. It provisions the compute, reads input directly from S3, writes predictions back to S3, and shuts down automatically, ensuring you only pay for the duration of the job. Distractor Analysis: - A is Incorrect: Asynchronous inference is for individual requests arriving dynamically over time, not for processing a single massive, pre-assembled bulk file. - B is Incorrect: Serverless endpoints are for interactive, real-time requests, not bulk dataset processing, and they have strict execution time and payload limits. - D is Incorrect: A real-time endpoint would require an instance to be running to accept requests, violating the requirement to avoid standing endpoints and pay only for compute time used. > Exam Tip: Use Batch Transform when an entire dataset arrives together and no caller is actively waiting for a synchronous response.
### Question 8 - Bedrock AgentCore & Open Protocols An enterprise is deploying a generative AI agent that needs to securely interact with existing internal REST APIs (e.g., HR systems, inventory databases) to take actions on behalf of users. The company wants to expose these existing APIs as tools to the agent with the least operational overhead and using an open standard protocol for agent communication. Which AWS service or feature should they use to integrate these APIs as agent tools? (Select ONE) - A) Deploy custom AWS Lambda functions for each API to translate requests manually. - B) Use the Amazon Bedrock AgentCore Gateway to expose the APIs as tools. - C) Re-architect all internal APIs as GraphQL endpoints. - D) Train a custom router model on Amazon SageMaker to route API calls.	Correct Answer: B Correct Option Analysis: - B is Correct: Amazon Bedrock AgentCore provides a gateway that can expose existing APIs and functions as tools to agents using open agent protocols (such as the Model Context Protocol). This minimizes operational overhead by avoiding the need to write custom integration glue code for each API. Distractor Analysis: - A is Incorrect: Writing custom Lambda functions for every API increases operational overhead and maintenance complexity, violating the constraint. - C is Incorrect: Re-architecting internal APIs to GraphQL is a massive engineering effort and completely unnecessary for exposing tools to an agent. - D is Incorrect: Training a custom router model is an anti-pattern for tool integration; modern agents use native tool-calling capabilities and protocol gateways. > Exam Tip: Bedrock AgentCore provides a serverless runtime and a gateway that exposes existing APIs as tools using open protocols like MCP, minimizing integration overhead.
### Question 9 - RAG Retrieval Configurations A legal tech startup has deployed a RAG application using Amazon Bedrock Knowledge Bases. Users complain that while the system often retrieves the correct legal statute, it appears far down the list (e.g., rank 8 out of 10), and less relevant passages are shown first to the LLM, resulting in incorrect answers. The startup needs to fix this ordering issue without missing the correct passage. Which configuration change will MOST directly address this ordering problem? (Select ONE) - A) Increase the number of returned passages (top-k) from 10 to 20. - B) Decrease the number of returned passages (top-k) from 10 to 3. - C) Add a reranking model to reorder the retrieved candidates. - D) Enable hybrid search on the vector store.	Correct Answer: C Correct Option Analysis: - C is Correct: A reranking model acts as a second stage in retrieval. It takes the top-k candidates retrieved by the initial vector search (Stage 1) and re-scores them using a more compute-intensive cross-encoder model (Stage 2), pushing the most contextually relevant passages to the top of the list before they are passed to the LLM. Distractor Analysis: - A is Incorrect: Increasing top-k increases recall (getting more passages) but makes the ordering problem worse, as there will be even more irrelevant passages for the LLM to sift through. - B is Incorrect: Decreasing top-k would completely drop the correct passage (currently at rank 8) from the context window, leading to hallucinations or "I don't know" responses. - D is Incorrect: Hybrid search helps recover exact keyword matches that vector embeddings might blur, but it does not specifically fix the semantic reordering of already retrieved candidates like a dedicated reranker does. > Exam Tip: Use a reranker to improve the order and precision of retrieved passages without altering the recall of the initial vector search.
### Question 10 - Selecting Compute Environments A machine learning team has developed a proprietary computer vision model that requires highly customized C++ inference logic, specific Linux kernel-level GPU driver configurations, and direct access to hardware accelerators. These requirements are not supported by standard Amazon SageMaker managed containers. The team wants to deploy this model with high availability and orchestration while retaining full control over the underlying operating system and compute environment. Which AWS deployment target is the MOST appropriate? (Select ONE) - A) Amazon Bedrock Custom Model Import. - B) Amazon SageMaker AI Serverless Endpoint. - C) Amazon Elastic Kubernetes Service (Amazon EKS). - D) AWS Lambda packaged as a container image.	Correct Answer: C Correct Option Analysis: - C is Correct: Amazon EKS provides managed Kubernetes, which gives the team full control over the underlying compute environment, container OS, and driver configurations. It allows for custom container orchestration to meet highly specific hardware and kernel-level requirements that managed ML services do not expose. Distractor Analysis: - A is Incorrect: Bedrock Custom Model Import only supports specific open-weight foundation model architectures and does not allow custom C++ inference logic or OS-level configurations. - B is Incorrect: SageMaker Serverless Endpoints abstract away the infrastructure, meaning you cannot control the OS, kernel drivers, or deploy custom unmanaged C++ logic that requires hardware access. - D is Incorrect: AWS Lambda has strict execution time limits and abstracts the OS/hardware layer, making it unsuitable for kernel-level driver configurations and long-running custom GPU inference. > Exam Tip: When a workload requires OS-level control, custom kernel drivers, or inference logic unsupported by managed ML containers, use Amazon EKS or Amazon EC2.