Skill 4.2.4: Optimize capacity for cost, performance, and reliability

Question	Answer & Explanation
### Question 1 - SageMaker Endpoint Scaling for Diurnal Traffic A media company runs a recommendation model on an Amazon SageMaker AI real-time endpoint. Traffic is heavy and steady during business hours but drops to almost nothing overnight. The instances are correctly sized for the daytime peak. The team needs to minimize overnight hosting costs without changing the real-time nature of the application or introducing complex architectural changes. Which approach meets these requirements with the least operational overhead? (Select ONE) - A) Convert the real-time endpoint to an Asynchronous Inference endpoint to queue overnight traffic. - B) Configure SageMaker Automatic Scaling with a target tracking policy based on `InvocationsPerInstance`. - C) Move the endpoint to a smaller instance family overnight using a Lambda function. - D) Host the model on a Serverless Inference endpoint to scale to zero overnight.	Correct Answer: B Correct Answer Analysis: - B is Correct: SageMaker Automatic Scaling allows the endpoint to dynamically adjust the instance count based on traffic. A target tracking policy based on `InvocationsPerInstance` will automatically scale down the instance count to a minimum (e.g., 1) overnight, releasing idle compute and reducing costs, while maintaining the real-time endpoint architecture. Distractor Analysis: - A is Incorrect: Converting to Asynchronous Inference changes the client request/response paradigm. Asynchronous endpoints are for large payloads or long processing times, not for handling standard real-time traffic that happens to drop at night. - C is Incorrect: Dynamically changing instance families on a running endpoint is not natively supported without deleting and recreating the endpoint configuration, introducing unnecessary operational complexity and downtime risk. - D is Incorrect: Serverless Inference is designed for intermittent, small payloads with cold start tolerances. Moving a high-traffic daytime workload to Serverless could introduce latency issues during peak hours. > Exam Tip: When an endpoint is busy during the day and idle at night, but correctly sized for the peak, use auto-scaling to follow demand rather than changing instance sizes or inference types.
### Question 2 - Commitment Options for SageMaker Compute A financial services firm runs a steady, year-round fraud detection inference baseline on Amazon SageMaker AI real-time endpoints. The workload uses `ml.inf1` and `ml.m5` instances. The team wants to reduce the hourly rate charged for this predictable baseline usage over the next 3 years. Which purchasing option provides this discount while maintaining flexibility across SageMaker instance families? (Select ONE) - A) Compute Savings Plans - B) EC2 Instance Savings Plans - C) SageMaker AI Savings Plans - D) Purchase Reserved Instances for the specific `ml.inf1` instances	Correct Answer: C Correct Answer Analysis: - C is Correct: SageMaker AI Savings Plans offer a flexible commitment-based pricing model specifically for SageMaker ML instance usage. By committing to a consistent dollar-per-hour spend over a 1-year or 3-year term, the firm receives a discount (up to 64%) that applies automatically across SageMaker instance families and regions. 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 standard Amazon EC2 instances within a specific instance family and region, providing no discounts for SageMaker resources. - D is Incorrect: While Reserved Instances can offer discounts, SageMaker AI Savings Plans provide greater flexibility across instance families compared to rigid Reserved Instances. > Exam Tip: SageMaker AI Savings Plans are the commitment vehicle for SageMaker compute, analogous to Compute Savings Plans for EC2/Lambda.
### Question 3 - Optimizing Bedrock Token Costs A software company is running a generative AI customer service assistant on Amazon Bedrock using Anthropic Claude. The monthly bill has spiked significantly. Investigation reveals that the prompts are extremely long because they include a massive, static block of company policy instructions that is sent with every single user request. The team must implement the most cost-effective solution to reduce token costs without degrading the quality of the responses. Which action should the team take? (Select ONE) - A) Enable Prompt Caching for the static block of policy instructions. - B) Convert the real-time invocation to an Amazon Bedrock Batch Inference job. - C) Decrease the maximum response length parameter to 1 token. - D) Switch to a smaller, less expensive foundation model.	Correct Answer: A Correct Answer Analysis: - A is Correct: Prompt caching allows the model to reuse pre-computed Key-Value (KV) attention states for a repeating static prompt prefix. Since the policy instructions are static and repeated on every request, caching them will significantly reduce the processing cost of the input tokens, as cached tokens are billed at a heavily reduced rate. Distractor Analysis: - B is Incorrect: Bedrock Batch Inference is for asynchronous processing of large datasets, not for interactive, real-time customer service assistants. - C is Incorrect: Decreasing maximum response length to 1 token would completely break the assistant's ability to generate useful answers. - D is Incorrect: While switching to a smaller model can reduce cost, it might degrade response quality. Prompt caching directly targets the cost of the static, repetitive tokens without altering the model's capabilities. > Exam Tip: In Generative AI, prompt caching is the equivalent of "right-sizing" repetitive compute. Place static content at the beginning of the prompt and dynamic content at the end to maximize cache hits.
### Question 4 - Identifying Agent Resource Consumption An AI engineering team has deployed an Amazon Bedrock Agent that performs multi-step research. A single user invocation triggers a planning call, three separate tool invocations (Lambda functions querying databases), and a final synthesis call to the foundation model. The team has noticed an unpredictable spike in AWS costs per invocation and needs to pinpoint exactly which step within the agent's workflow is consuming the most tokens and time. Which AWS service is purpose-built to provide this level of per-invocation visibility for Bedrock Agents? (Select ONE) - A) AWS X-Ray - B) AWS Compute Optimizer - C) Amazon Bedrock AgentCore Observability - D) AWS Trusted Advisor	Correct Answer: C Correct Answer Analysis: - C is Correct: Amazon Bedrock AgentCore Observability is specifically designed to capture the internal mechanics of an agent invocation. It traces the inference calls, tool invocations, and memory operations, making the agent's exact resource consumption and token usage visible per invocation. Distractor Analysis: - A is Incorrect: AWS X-Ray is excellent for distributed tracing across microservices (like Lambda and API Gateway), but it is not natively tailored to break down the specific internal LLM token usage and tool-calling mechanics of a Bedrock Agent like AgentCore is. - B is Incorrect: AWS Compute Optimizer analyzes utilization history for EC2/Lambda resources and recommends right-sizing, but it does not provide per-invocation tracing for AI agents. - D is Incorrect: AWS Trusted Advisor checks accounts against best practices for cost and security, but it does not provide granular application-level observability for agent workflows. > Exam Tip: When dealing with unpredictable Agent costs, use Amazon Bedrock AgentCore Observability to break down the cost of planning, tool calls, and synthesis per user request.
### Question 5 - Consolidating Multiple Small Models A healthcare startup has trained 50 distinct, small ML models (each under 500 MB) to predict patient readmission risks for different departments. Currently, each model is hosted on its own Amazon SageMaker AI real-time endpoint. Traffic to each model is highly intermittent, but the serving framework is identical across all 50 models. The team must optimize capacity and reduce infrastructure costs while maintaining the ability to invoke any model dynamically. Which SageMaker feature meets these requirements with the lowest cost? (Select ONE) - A) SageMaker Serverless Inference - B) SageMaker Asynchronous Inference - C) SageMaker Multi-Model Endpoints (MMEs) - D) SageMaker Edge	Correct Answer: C Correct Answer Analysis: - C is Correct: Multi-Model Endpoints (MMEs) allow dozens or hundreds of models that share the same serving framework to be hosted on a single set of compute instances. The models are loaded on demand from S3, drastically reducing infrastructure costs compared to running 50 dedicated endpoints for intermittent traffic. Distractor Analysis: - A is Incorrect: While Serverless Inference scales to zero, you cannot host 50 different models on a single Serverless endpoint simultaneously in the same dynamic, shared-instance way MMEs do. Serverless is better for a single model with spiky traffic. - B is Incorrect: Asynchronous Inference is designed for large payloads (up to 1GB) and long processing times, not specifically for consolidating many small models onto shared compute. - D is Incorrect: SageMaker Edge is used for deploying models to edge devices (IoT, cameras), not for consolidating cloud-hosted endpoints. > Exam Tip: Use Multi-Model Endpoints to consolidate many models that share a framework and have intermittent traffic, accepting a slight cold-start latency for massive cost savings.
### Question 6 - Right-Sizing Underutilized Instances An e-commerce company runs a real-time inference endpoint for product recommendations on a single `ml.m5.24xlarge` instance. CloudWatch metrics show that CPU utilization is consistently below 5% and memory usage is below 15%, even during peak daytime traffic. Latency remains well within the strict SLA. The engineering team wants to optimize capacity for cost without changing the auto-scaling configuration. What is the most cost-effective solution? (Select ONE) - A) Decrease the minimum scaling capacity from 1 to 0. - B) Right-size the endpoint by switching to a smaller instance type, such as `ml.m5.large`. - C) Enable Spot Instances for the endpoint. - D) Move the endpoint to AWS Lambda with Provisioned Concurrency.	Correct Answer: B Correct Answer Analysis: - B is Correct: The instance is drastically underutilized (under 5% CPU). The correct optimization lever for underutilized provisioned compute is right-sizing. Moving to an `ml.m5.large` (or similar smaller instance) will dramatically cut the hourly billing rate while still comfortably handling the traffic within SLA. Distractor Analysis: - A is Incorrect: Decreasing the minimum capacity to 0 would require Serverless or Asynchronous inference, which changes the endpoint architecture. Even if scaled to 0, the single instance running during the day is still a 24xlarge, so daytime costs are not optimized. - C is Incorrect: Spot Instances are for interruptible workloads (like training or batch transform). A real-time inference endpoint requires guaranteed availability, and Spot reclamation would break the endpoint. - D is Incorrect: Moving a SageMaker endpoint to Lambda requires rewriting the serving logic and may not support complex ML frameworks or large model sizes easily. > Exam Tip: Read utilization over a representative window before changing anything. If a single instance is underutilized even at peak, right-size the instance type. If it's busy during the day and idle at night, use auto-scaling.
### Question 7 - Bedrock Capacity for Predictable Traffic A social media platform uses Amazon Bedrock to generate daily automated summaries of trending topics. The workload runs continuously, processing a highly predictable, high volume of text every hour. The team is currently using On-Demand token pricing, but the CFO has requested a commitment to reduce the inference costs for this specific workload over the next year. Which purchasing option is designed for this use case? (Select ONE) - A) AWS Compute Savings Plans - B) Bedrock Provisioned Throughput - C) SageMaker AI Savings Plans - D) Bedrock Guardrails	Correct Answer: B Correct Answer Analysis: - B is Correct: Bedrock Provisioned Throughput allows you to reserve dedicated model units at a fixed hourly rate. For a steady, high-volume, and highly predictable workload, this provides a discounted rate compared to On-Demand token pricing and guarantees capacity. Distractor Analysis: - A is Incorrect: Compute Savings Plans do not apply to Foundation Model token inference; they apply to EC2, Lambda, and Fargate. - C is Incorrect: SageMaker AI Savings Plans apply to SageMaker instance hours, not Amazon Bedrock token usage. - D is Incorrect: Bedrock Guardrails are a safety feature for filtering harmful content and PII, not a cost management or purchasing tool. > Exam Tip: In the traditional ML world, steady baselines use Savings Plans. In the Bedrock world, predictable high-volume inference uses Provisioned Throughput.
### Question 8 - Proactive Cost Alerting An enterprise data science team is rapidly prototyping multiple Generative AI applications using Amazon Bedrock and SageMaker. The team wants to ensure they are alerted via email before their monthly AWS spend on Bedrock tokens surpasses $10,000, allowing them to throttle application usage proactively. Which AWS service provides this specific alerting capability based on forecasted spend? (Select ONE) - A) AWS Cost Explorer - B) AWS Budgets - C) AWS Trusted Advisor - D) Amazon CloudWatch Alarms	Correct Answer: B Correct Answer Analysis: - B is Correct: AWS Budgets allows teams to set custom cost or usage thresholds. It supports forecasted cost alerts, meaning it evaluates current spend trends and alerts the team if spending is on track to exceed the $10,000 monthly threshold before the overage actually occurs. Distractor Analysis: - A is Incorrect: AWS Cost Explorer is a visualization and reporting tool for historical and forecasted spend, but it does not natively generate automated threshold-driven email alerts like Budgets. - C is Incorrect: AWS Trusted Advisor identifies idle resources and best practices but does not monitor custom financial caps or forecasted token spend. - D is Incorrect: While CloudWatch can trigger alarms on billing metrics, AWS Budgets is the purpose-built tool for managing financial thresholds and forecasted spend notifications across accounts. > Exam Tip: Use AWS Budgets for proactive, forecast-based cost alerts to catch runaway token spend before it happens.
### Question 9 - Architecture for Large Payloads and Long Processing A manufacturing company runs an ML model that analyzes high-resolution 3D CAD files (averaging 800 MB per file) to detect structural weaknesses. The inference process takes roughly 4 minutes per file. Traffic arrives sporadically, but when it does, files must be queued and processed without overloading the endpoint. The team needs the most cost-effective and reliable architecture. Which SageMaker inference option should they use? (Select ONE) - A) Real-Time Inference with high-memory `ml.r5` instances - B) Asynchronous Inference - C) Serverless Inference - D) Multi-Model Endpoint	Correct Answer: B Correct Answer Analysis: - B is Correct: Asynchronous Inference is specifically designed for payloads up to 1 GB and processing times up to 15 minutes. It provides a built-in queue to handle incoming requests, can scale down to zero when idle (saving costs for sporadic traffic), and handles long processing times gracefully. Distractor Analysis: - A is Incorrect: Real-Time Inference has a strict 60-second timeout limit and a payload limit of 60 MB. It cannot handle 800 MB files or 4-minute processing times. - C is Incorrect: Serverless Inference has a strict 60-second timeout limit and a smaller payload limit (10 MB), making it entirely unsuitable for this workload. - D is Incorrect: Multi-Model Endpoints are built for consolidating many models, not for solving large payload and long execution time constraints. > Exam Tip: For payloads > 60 MB or execution times > 60 seconds, Asynchronous Inference is the required option. It also scales to zero, which is perfect for sporadic traffic.
### Question 10 - Distributed Tracing for Microservices A retail company has an ML pipeline orchestrated by AWS Step Functions. The workflow invokes an AWS Lambda function to preprocess data, calls an Amazon SageMaker AI real-time endpoint for inference, and then queries an Amazon OpenSearch Service cluster to fetch historical context. Aggregate CloudWatch metrics show the end-to-end latency has increased to 8 seconds, but they cannot determine which specific component is causing the delay. Which AWS service should the engineering team use to identify the exact component causing the latency? (Select ONE) - A) AWS Compute Optimizer - B) Amazon CloudWatch Logs Insights - C) AWS X-Ray - D) AWS Trusted Advisor	Correct Answer: C Correct Answer Analysis: - C is Correct: AWS X-Ray is a distributed tracing service that tracks a request as it travels across different microservices and components (Step Functions, Lambda, SageMaker, OpenSearch). It provides a visual service map and detailed latency breakdowns per component, allowing the team to isolate the bottleneck. Distractor Analysis: - A is Incorrect: AWS Compute Optimizer looks at resource utilization metrics to recommend instance right-sizing, it does not trace requests across microservices. - B is Incorrect: CloudWatch Logs Insights is used to search and analyze log data. While logs can contain timestamps, it does not provide automated distributed tracing and visual dependency maps across services like X-Ray. - D is Incorrect: Trusted Advisor checks for AWS best practices (like exposed keys or idle load balancers) but does not perform application-level request tracing. > Exam Tip: When aggregate metrics show latency but don't pinpoint the cause, use AWS X-Ray for distributed tracing to visualize the request path and identify the slow component.