4.2.1

Question	Answer & Explanation
### Question 1 - Right-Sizing Underutilized SageMaker Endpoints A retail company runs a real-time recommendation engine on an Amazon SageMaker AI endpoint using ml.m5.24xlarge instances. CloudWatch metrics reveal that CPU utilization remains below 20% and memory usage is under 30% during peak traffic, but the endpoint is provisioned for high availability. The ML engineering team is tasked with reducing infrastructure costs without compromising the current response latency or availability constraints. Which approach provides the MOST cost-effective solution while maintaining performance? - A) Enable target tracking auto scaling based on CPU utilization to add instances dynamically during peak hours. - B) Convert the endpoint to an Asynchronous Inference endpoint to queue requests and scale down to zero overnight. - C) Right-size the endpoint by changing the instance type to a smaller family (e.g., ml.m5.large) and validate latency against CloudWatch metrics. - D) Implement Multi-Model Endpoints (MME) to host the recommendation engine alongside unrelated models on the same ml.m5.24xlarge instances.	Correct Answer: C Correct Answer Analysis: - C is Correct: Right-sizing directly addresses the core issue: the current instances are vastly over-provisioned for the workload's actual compute and memory requirements. Moving to a smaller instance family reduces the baseline cost while maintaining the necessary capacity, as long as utilization is monitored to ensure latency constraints are still met. Distractor Analysis: - A is Incorrect: Auto scaling manages the number of instances based on traffic, but it does not fix the issue that each individual provisioned instance is oversized and underutilized. - B is Incorrect: Asynchronous inference introduces queueing latency and is designed for large payloads or long processing times, which violates the real-time, low-latency constraint of a recommendation engine. - D is Incorrect: While MMEs consolidate compute, it does not resolve the underlying inefficiency of paying for massive ml.m5.24xlarge instances when the workload only needs a fraction of those resources. > Key Takeaway: If CloudWatch shows consistently low CPU/GPU and memory utilization on a real-time endpoint, the primary optimization lever is right-sizing the instance family, not merely adjusting auto-scaling policies.
### Question 2 - Consolidating Intermittent Models with Multi-Model Endpoints A healthcare startup hosts 50 distinct medical diagnosis models on 50 separate SageMaker real-time endpoints using ml.c5.xlarge instances. Each model receives requests infrequently, but the startup is facing high infrastructure costs because 50 endpoints are running continuously. The architecture must be optimized for the lowest cost while retaining the same serving framework and avoiding the cold-start latency issues associated with scaling to zero. Which SageMaker feature provides the MOST cost-effective solution? - A) Deploy a SageMaker Serverless Inference endpoint for each model to scale to zero when not in use. - B) Consolidate the 50 models onto a single SageMaker Multi-Model Endpoint (MME) using shared compute instances. - C) Purchase SageMaker AI Savings Plans for all 50 endpoints to reduce the On-Demand hourly rate. - D) Convert all 50 endpoints to a single Asynchronous Inference endpoint with a high instance count.	Correct Answer: B Correct Answer Analysis: - B is Correct: SageMaker Multi-Model Endpoints (MMEs) allow you to deploy multiple models onto a single endpoint backed by shared compute instances. The models are loaded from Amazon S3 on demand, which drastically reduces infrastructure costs for intermittent workloads while maintaining a warm endpoint to avoid the severe cold starts of scaling to zero. Distractor Analysis: - A is Incorrect: While Serverless Inference scales to zero, it introduces cold-start latency. The scenario explicitly requires avoiding cold-start latency issues, and 50 separate serverless endpoints might still hit concurrency limits if traffic spikes simultaneously. - C is Incorrect: Savings Plans reduce the rate of existing usage but do not address the architectural inefficiency of paying for 50 continuously running instances for infrequently accessed models. - D is Incorrect: Asynchronous inference is designed for large payloads or long processing times, not for consolidating many small, fast models. > Key Takeaway: For many small, infrequently invoked models that share the same framework, Multi-Model Endpoints (MMEs) offer the largest cost savings by sharing a single pool of compute instances.
### Question 3 - Translating Optimization Levers to Amazon Bedrock An AI engineering team recently migrated their text summarization application from self-hosted open-source LLMs on Amazon SageMaker AI to Amazon Bedrock using the Anthropic Claude 3 Opus model. On SageMaker, the team optimized costs by right-sizing GPU instances and configuring auto-scaling policies. On Bedrock, the bill is unexpectedly high and the team attempts to apply instance right-sizing, but it has no effect. The solution must be optimized for cost reduction without sacrificing output quality. Which action will effectively reduce the Bedrock inference costs? - A) Right-size the underlying compute instances allocated to the Bedrock foundation model. - B) Switch to a smaller, domain-appropriate foundation model (e.g., Claude 3 Haiku) that meets the quality requirements at a lower cost-per-token. - C) Configure target-tracking auto scaling on the Bedrock API to reduce token throughput during quiet hours. - D) Purchase Compute Savings Plans to cover the Amazon Bedrock token usage.	Correct Answer: B Correct Answer Analysis: - B is Correct: Amazon Bedrock charges based on token throughput (input and output tokens), not compute hours. The equivalent of "right-sizing an instance" in Bedrock is "right-sizing the model." Switching from a large, expensive model (Opus) to a smaller, cheaper model (Haiku) that still meets the task's quality requirements lowers the cost of every request. Distractor Analysis: - A is Incorrect: Bedrock is a serverless managed service; users do not provision or right-size underlying compute instances. - C is Incorrect: Auto scaling manages instance counts, not token throughput. Bedrock scales automatically, and you cannot "auto scale" to reduce token processing without stopping application requests. - D is Incorrect: Compute Savings Plans apply to EC2, Fargate, and Lambda, not to Amazon Bedrock token usage. > Key Takeaway: For Generative AI workloads on Amazon Bedrock, the billing driver is tokens, not compute hours. The primary cost optimization lever (analogous to instance right-sizing) is model selection.
### Question 4 - Handling Large Payloads and Long Processing Times A media processing company runs a computer vision model on SageMaker that analyzes high-resolution video files. Each request payload is approximately 800 MB, and the inference process takes up to 12 minutes to complete. The workload arrives in unpredictable bursts, and the company wants to avoid paying for idle compute capacity between bursts. The solution must be the most cost-effective while supporting the payload size and execution time. Which SageMaker inference option should the company use? - A) Real-Time Inference with a high instance count and auto scaling. - B) Serverless Inference with concurrency limits. - C) Asynchronous Inference with auto scaling to zero instances. - D) Multi-Model Endpoints (MME) backed by ml.g4dn instances.	Correct Answer: C Correct Answer Analysis: - C is Correct: Asynchronous Inference is specifically designed for workloads with large payload sizes (up to 1 GB) and long execution times (up to 15 minutes). Crucially, it supports auto scaling down to zero instances, which perfectly addresses the unpredictable bursts and the requirement to avoid paying for idle compute between bursts. Distractor Analysis: - A is Incorrect: Real-Time Inference has a 6 MB payload limit for synchronous requests and does not support scaling to zero instances, resulting in high idle compute costs between bursts. - B is Incorrect: Serverless Inference has strict limits: payload size is capped at 10 MB and execution time is capped at 60 seconds, which violates the 800 MB and 12-minute constraints. - D is Incorrect: MMEs are for consolidating multiple models onto shared instances, not for handling large payloads or scaling to zero for single-model asynchronous workloads. > Key Takeaway: Asynchronous Inference is the correct choice for payloads up to 1 GB and processing times up to 15 minutes, offering the unique cost benefit of scaling the instance count down to zero.
### Question 5 - Committing to a Steady ML Baseline A financial institution runs a fraud detection model on an Amazon SageMaker AI real-time endpoint. The traffic is steady and predictable, running 24/7 year-round. The instances are correctly sized for the steady baseline load, and auto-scaling is not required. The company wants to optimize the cost of this steady-state compute usage over the next 12 months with the lowest operational overhead. Which purchasing option should the ML engineer choose? - A) Compute Savings Plans - B) EC2 Instance Savings Plans - C) SageMaker AI Savings Plans - D) Spot Instance reservations for the endpoint	Correct Answer: C Correct Answer Analysis: - C is Correct: SageMaker AI Savings Plans offer a flexible, commitment-based pricing model specifically for Amazon SageMaker ML instance usage. By committing to a consistent hourly spend over a 1-year term, the company receives a significant discount (up to 64%) compared to On-Demand pricing for their steady, predictable endpoint usage. Distractor Analysis: - A is Incorrect: Compute Savings Plans apply automatically to Amazon EC2, AWS Fargate, and AWS Lambda usage, but they do not cover SageMaker ML instance types. - B is Incorrect: EC2 Instance Savings Plans apply exclusively to Amazon EC2 instances and cannot be applied to SageMaker endpoints (which use ml.* instance types). - D is Incorrect: Spot capacity can be reclaimed by AWS with a two-minute warning, which violates the high-availability and steady-state requirements of a 24/7 fraud detection endpoint. > Key Takeaway: For steady, year-round SageMaker AI endpoints, use SageMaker AI Savings Plans to commit to a specific dollar-per-hour spend in exchange for discounted rates.
### Question 6 - Choosing Compute for Accelerated Inference An e-commerce company is deploying a new visual search feature that uses a deep learning model to process and classify images in real time. The model is highly optimized for GPU acceleration. The team needs to deploy this on Amazon SageMaker AI and must ensure the lowest latency possible for the end-user experience. Which instance family should the team select for the SageMaker real-time endpoint? - A) ml.m5.xlarge (General Purpose) - B) ml.c5.xlarge (Compute Optimized) - C) ml.g4dn.xlarge (Accelerated Computing) - D) ml.r5.xlarge (Memory Optimized)	Correct Answer: C Correct Answer Analysis: - C is Correct: The ml.g4dn instance family belongs to the Accelerated Computing category and features NVIDIA GPUs. For deep learning models optimized for GPU acceleration, selecting an accelerated computing instance is required to achieve the lowest possible inference latency. Distractor Analysis: - A is Incorrect: ml.m5 instances are general-purpose and do not provide GPU acceleration, resulting in significantly higher latency for GPU-optimized models. - B is Incorrect: ml.c5 instances are compute-optimized with high CPU performance but lack GPUs, making them unsuitable for GPU-accelerated workloads. - D is Incorrect: ml.r5 instances are optimized for memory-intensive applications and do not contain GPUs. > Key Takeaway: For real-time inference workloads requiring GPU acceleration (like deep learning-based image processing), select instances from the Accelerated Computing family (ml.g4dn or ml.inf).
### Question 7 - Automated Instance Selection without Historical Data A machine learning team has just finished training a new Natural Language Processing (NLP) model and needs to deploy it to a SageMaker real-time endpoint. They have no historical CloudWatch utilization data for this model and are unsure which instance type will provide the best balance of cost and latency. They need to find the optimal instance configuration with the least operational overhead. Which AWS tool or feature can automatically send load tests to the endpoint and recommend the optimal instance type? - A) AWS Compute Optimizer - B) Amazon CloudWatch Metric Math - C) SageMaker Inference Recommender - D) AWS Trusted Advisor	Correct Answer: C Correct Answer Analysis: - C is Correct: SageMaker Inference Recommender automatically runs load tests on a deployed model (or a model container) and evaluates different instance types to recommend the optimal configuration for performance and cost, which is ideal when no historical utilization data exists. Distractor Analysis: - A is Incorrect: AWS Compute Optimizer requires existing utilization history (usually 30 days of CloudWatch metrics) to make recommendations, which the team does not have for this new model. - B is Incorrect: CloudWatch Metric Math is used to perform mathematical operations on existing metrics, not to run load tests or recommend instance types. - D is Incorrect: AWS Trusted Advisor checks for best practices (like idle resources) but does not run load tests to recommend instance configurations for new deployments. > Key Takeaway: When deploying a new model without historical metrics, use SageMaker Inference Recommender to automate load testing and find the best cost-performance instance type.
### Question 8 - Optimizing Predictable High-Volume FM Inference A gaming company uses Amazon Bedrock to generate dynamic NPC dialogue in real time. The application uses a single foundation model, and traffic is steady, high-volume, and predictable 24/7. The company is currently using On-Demand token pricing, but the monthly bill has become unsustainable. They need to optimize costs while maintaining the same model and latency. Which Bedrock feature provides the most cost-effective solution for this workload? - A) Switch to a smaller foundation model in the Bedrock model catalog. - B) Use Amazon Bedrock Batch Inference to queue all dialogue generation requests. - C) Purchase Provisioned Throughput for the foundation model. - D) Implement prompt caching to reduce the token count.	Correct Answer: C Correct Answer Analysis: - C is Correct: For predictable, high-volume, and steady-state workloads on Amazon Bedrock, Provisioned Throughput allows you to reserve dedicated model units at a fixed hourly rate. This is analogous to SageMaker Savings Plans and provides a significant discount compared to On-Demand token pricing for high, consistent usage. Distractor Analysis: - A is Incorrect: The scenario requires maintaining the same model and quality; switching to a smaller model might degrade the dialogue quality. - B is Incorrect: Batch inference is asynchronous and introduces latency, which violates the real-time requirement for dynamic NPC dialogue. - D is Incorrect: While prompt caching reduces the cost of static prefixes, it does not provide the foundational rate reduction that Provisioned Throughput offers for high, steady 24/7 volume. > Key Takeaway: For predictable, high-volume foundation model inference on Amazon Bedrock, Provisioned Throughput reserves model units at a fixed rate, replacing On-Demand token pricing for better cost efficiency.
### Question 9 - Fixing Prompt Caching Inefficiencies An enterprise has enabled prompt caching for its Amazon Bedrock-powered legal assistant. The system prompt contains static instructions, but the team placed a dynamic timestamp at the very beginning of the prompt to track request timing. CloudWatch shows that the cache is constantly missing, and token costs are not decreasing. The team must optimize the caching mechanism to achieve cost savings. What must the team change to make prompt caching effective? - A) Increase the maximum response length to ensure the cache is utilized. - B) Move the dynamic timestamp to the end of the prompt, after the static system instructions. - C) Convert the request to Bedrock Batch Inference to force caching. - D) Increase the instance count provisioned for the Bedrock endpoint.	Correct Answer: B Correct Answer Analysis: - B is Correct: Prompt caching relies on an exact token sequence match from the beginning of the prompt. By placing a dynamic timestamp at the very beginning, the sequence changes on every request, invalidating the cache. Moving the dynamic content to the end allows the static prefix to be cached and reused successfully. Distractor Analysis: - A is Incorrect: Response length does not affect the caching of the input prompt prefix. - C is Incorrect: Batch Inference is a separate execution mode for asynchronous processing and does not "force" real-time prompt caching to work. - D is Incorrect: Bedrock is a serverless service; users cannot adjust the instance count for an endpoint to fix caching logic issues. > Key Takeaway: Prompt caching requires a stable, static prefix at the beginning of the prompt. Any dynamic content placed before or within the static prefix will invalidate the cache on every request.
### Question 10 - Attributing Costs and Analyzing Drivers A global enterprise runs multiple SageMaker AI endpoints across different departments. The ML engineering team has noticed a sudden spike in the overall AWS bill over the last 30 days. They need to identify exactly which department and which specific endpoint is driving the cost increase, and they want to view this spend alongside the endpoint's CloudWatch utilization metrics. The solution must use the appropriate AWS native tools with the least operational overhead. Which combination of AWS services should the team use to identify the cost driver and analyze the spend? (Select TWO) - A) Use AWS Budgets to set a hard cap on monthly SageMaker spend. - B) Use AWS Cost Explorer, filtered by cost allocation tags, to identify the specific endpoint driving the cost increase. - C) Use AWS Compute Optimizer to identify underutilized SageMaker instances. - D) Use AWS X-Ray to trace the billing execution path across the endpoints. - E) Use Cost Allocation Tags applied to SageMaker endpoints to attribute costs to specific departments.	Correct Answers: B and E Correct Answer Analysis: - B is Correct: AWS Cost Explorer visualizes historical and forecasted spend and can be filtered by tag, service, or usage type, allowing the team to pinpoint the specific department/endpoint causing the spike. - E is Correct: Cost Allocation Tags are the prerequisite for Cost Explorer grouping. By tagging endpoints with department names, the team can accurately attribute costs. Distractor Analysis: - A is Incorrect: AWS Budgets is used to send alerts when thresholds are passed, not to perform deep-dive analysis to identify the specific driver behind a cost increase. - C is Incorrect: AWS Compute Optimizer analyzes utilization to recommend instance sizes, but it does not track dollar spend or attribute costs to departments. - D is Incorrect: AWS X-Ray traces application requests across components to troubleshoot performance/latency issues; it does not trace billing data or cost increases. > Key Takeaway: Cost Allocation Tags and AWS Cost Explorer are the primary AWS native tools used to attribute spend to specific resources/teams and identify the drivers behind a rising AWS bill.