3.1.2
| Question | Answer & Explanation |
|---|---|
| ### Question 1 - Multi-Model vs Multi-Container Endpoint Selection An ML team needs to deploy 500 custom XGBoost models for different retail stores. The models share the same framework and are infrequently accessed, with only a few receiving constant traffic. The team wants to minimize infrastructure costs and operational overhead. Which deployment strategy satisfies these requirements with the least operational overhead and is the most cost-effective? (Select ONE) - A) Deploy 500 separate SageMaker real-time endpoints. - B) Deploy a SageMaker Multi-Model Endpoint (MME) with a shared serving container. - C) Deploy a SageMaker Multi-Container Endpoint (MCE) with 500 containers. - D) Package all models into a single massive container and deploy to a real-time endpoint. |
Correct Answer: B Correct Answer Analysis: - B is Correct: A Multi-Model Endpoint (MME) hosts multiple models on a single SageMaker endpoint using a shared compute fleet and serving container. SageMaker dynamically manages caching models in memory from Amazon S3, which is ideal for many models sharing the same framework with uneven traffic patterns. This drastically reduces hosting costs and operational overhead. Distractor Analysis: - A is Incorrect: Provisioning 500 separate real-time endpoints would result in extremely high infrastructure costs and massive management overhead. - C is Incorrect: A Multi-Container Endpoint (MCE) supports a maximum of 15 containers per endpoint, so 500 containers cannot be deployed this way. MCE is meant for different frameworks, not variations of the same model. - D is Incorrect: Packaging 500 models into a single container creates a massive, fragile deployment artifact. It makes updating individual models highly inefficient and violates container design best practices. > Exam Tip: Use Multi-Model Endpoints (MME) for hosting many models that share the same framework, relying on SageMaker to dynamically load/unload them from S3 based on traffic. |
| ### Question 2 - Inference Pipelines with Multi-Container Endpoints A healthcare company needs to deploy an ML pipeline that preprocesses medical images, runs inference using a custom PyTorch model, and post-processes the results to format a JSON report. All steps must occur in sequence on the same endpoint to minimize latency between steps. Which deployment strategy provides the lowest latency between sequential steps? (Select ONE) - A) Deploy a SageMaker Inference Pipeline (Multi-Container Endpoint) with containers for preprocessing, inference, and post-processing. - B) Use AWS Step Functions to orchestrate three separate AWS Lambda functions for each step. - C) Deploy an MME with the three models sharing a single container. - D) Use an asynchronous endpoint with custom logic to pass data between S3 buckets for each step. |
Correct Answer: A Correct Answer Analysis: - A is Correct: A SageMaker Multi-Container Endpoint (MCE) configured as an Inference Pipeline allows you to chain up to 15 containers sequentially. The data flows through the containers in-memory on the same instance, ensuring the lowest possible latency between preprocessing, inference, and postprocessing steps. Distractor Analysis: - B is Incorrect: Using Step Functions and Lambda introduces network latency and data serialization overhead between each step, which violates the "lowest latency between steps" constraint. - C is Incorrect: An MME is designed for hosting variations of models behind one endpoint, not for chaining different execution steps in a pipeline sequence. - D is Incorrect: Asynchronous endpoints are for long-running, queued requests, not for optimizing inter-step latency. Passing data via S3 between steps adds massive latency. > Exam Tip: Use SageMaker Inference Pipelines (a type of Multi-Container Endpoint) to sequentially execute preprocessing, inference, and postprocessing containers in-memory for strict latency requirements. |
| ### Question 3 - Selecting Deployment Orchestrators: EKS vs SageMaker An enterprise has an existing CI/CD and deployment infrastructure built entirely on Kubernetes using ArgoCD, Helm charts, and Prometheus for observability. They want to deploy a new containerized NLP model while leveraging their existing control plane and operational tooling. Which deployment orchestrator is the most appropriate for this scenario? (Select ONE) - A) Amazon SageMaker AI real-time endpoint. - B) Amazon Elastic Kubernetes Service (Amazon EKS). - C) Amazon ECS with AWS Fargate. - D) Amazon EC2 with Auto Scaling groups. |
Correct Answer: B Correct Answer Analysis: - B is Correct: Amazon EKS is a managed Kubernetes service that seamlessly integrates with existing Kubernetes-native tooling like ArgoCD, Helm, and Prometheus. It allows the team to deploy the NLP model using the same deployment orchestrators and manifests they already use, satisfying the requirement to leverage existing infrastructure. Distractor Analysis: - A is Incorrect: While SageMaker manages the endpoint, it does not use Kubernetes manifests or integrate natively with ArgoCD/Helm, forcing the team to adopt a separate control plane. - C is Incorrect: Amazon ECS uses its own task definitions and scheduling mechanisms, not Kubernetes controllers or Helm charts. - D is Incorrect: Managing deployments directly on EC2 requires custom scripting and tooling (like custom AMIs and user data), ignoring their Kubernetes infrastructure. > Exam Tip: If a scenario explicitly mentions existing Kubernetes manifests, Helm, or controllers, Amazon EKS is the correct orchestrator to maintain operational consistency. |
| ### Question 4 - Orchestration with AWS Step Functions A data science team needs to orchestrate a complex ML workflow that retrains a model, evaluates its accuracy, and conditionally deploys it to a SageMaker real-time endpoint only if the accuracy exceeds 90%. The workflow must have built-in error handling, retry logic, and state management. Which orchestration approach meets these requirements with the least operational overhead? (Select ONE) - A) Write a custom Python script on an EC2 instance using the SageMaker SDK to manage state and retries. - B) Use AWS Step Functions with native SageMaker service integrations to orchestrate the workflow. - C) Use Amazon EventBridge to trigger an AWS Lambda function that chains the SageMaker jobs sequentially. - D) Use Amazon ECS to run a persistent container that polls for new training jobs and manages the pipeline state. |
Correct Answer: B Correct Answer Analysis: - B is Correct: AWS Step Functions provides native service integrations for SageMaker (e.g., Training, Transform, Endpoint Config, Endpoint). It handles state management, conditional branching (e.g., accuracy > 90%), retries, and error handling natively, requiring zero infrastructure management and minimizing operational overhead. Distractor Analysis: - A is Incorrect: Running a custom script on EC2 requires managing the EC2 instance, writing custom retry logic, and handling state manually, which introduces high operational overhead. - C is Incorrect: Lambda functions have a 15-minute execution timeout, making them unsuitable for orchestrating long-running SageMaker training jobs. Chaining them manually is also brittle. - D is Incorrect: An ECS container requires managing the container, cluster, and custom state logic, adding unnecessary operational complexity compared to a managed state machine. > Exam Tip: For complex ML pipelines involving retries, conditional deployments, and state management across AWS services, AWS Step Functions is the go-to orchestrator for least operational overhead. |
| ### Question 5 - Granular Scaling with SageMaker Inference Components A company hosts 20 different NLP models on a single SageMaker Multi-Model Endpoint. They notice that one specific model receives 80% of the traffic and is experiencing high latency due to resource contention. They need to allocate specific compute resources to the high-traffic model while keeping it on the shared endpoint infrastructure. Which strategy addresses this with the least code changes and granular resource allocation? (Select ONE) - A) Move the high-traffic model to its own dedicated real-time endpoint. - B) Configure SageMaker Inference Components to allocate specific accelerators, CPU, and memory to the high-traffic model. - C) Convert the Multi-Model Endpoint to a Multi-Container Endpoint. - D) Scale out the Multi-Model Endpoint instance count by 10x. |
Correct Answer: B Correct Answer Analysis: - B is Correct: SageMaker Inference Components allow you to package models and deploy them independently to a shared endpoint. You can specify exact compute resources (e.g., a number of accelerators, CPU/RAM) per Inference Component, directly solving resource contention for the high-traffic model without moving it to a new endpoint. Distractor Analysis: - A is Incorrect: While moving it to a dedicated endpoint would solve contention, it violates the constraint of keeping it on the shared endpoint and requires more infrastructure management. - C is Incorrect: Converting to a Multi-Container Endpoint does not inherently provide granular resource allocation per model for dynamic contention issues in the way Inference Components do. - D is Incorrect: Scaling the entire endpoint instance count by 10x is highly cost-prohibitive and does not intelligently isolate resources for just the high-traffic model. > Exam Tip: Use SageMaker Inference Components when you need granular control over compute resources (CPU/GPU/RAM) for specific models deployed to a shared endpoint. |
| ### Question 6 - Multi-Container Endpoint: Direct vs Sequential Invocation An ML engineer needs to deploy three different models: a Scikit-Learn preprocessing model, a PyTorch prediction model, and a TensorFlow post-processing model. The application needs to invoke the Scikit-Learn and PyTorch models sequentially, but invoke the TensorFlow model independently by specifying its name. Which deployment strategy is supported and meets these requirements? (Select ONE) - A) Use a Multi-Model Endpoint (MME) for all three models. - B) Use a Multi-Container Endpoint (MCE) with Direct invocation for the TensorFlow model and Pipeline invocation for the Scikit-Learn and PyTorch models. - C) Deploy three separate SageMaker Serverless endpoints. - D) Package all three models into a single Docker container. |
Correct Answer: B Correct Answer Analysis: - B is Correct: A Multi-Container Endpoint (MCE) supports two invocation patterns: "Direct" (invoking a specific container by name) and "Pipeline" (invoking containers sequentially). You can configure the MCE to allow direct invocation of the TensorFlow model, while routing Scikit-Learn and PyTorch as a sequential pipeline. Distractor Analysis: - A is Incorrect: A Multi-Model Endpoint (MME) requires all models to share the same serving container and framework, which is not possible across Scikit-Learn, PyTorch, and TensorFlow. - C is Incorrect: Deploying three separate Serverless endpoints does not meet the requirement of invoking the Scikit-Learn and PyTorch models sequentially in one request. - D is Incorrect: Packaging multiple frameworks into a single container is an anti-pattern, making it difficult to manage dependencies, scale, and update individual models. > Exam Tip: Multi-Container Endpoints allow mixing different frameworks on one endpoint, supporting both Direct (by container name) and Pipeline (sequential) invocations simultaneously. |
| ### Question 7 - Compute Environment for Custom CUDA Kernels A deep learning research team has developed a custom CUDA kernel that must run on bare-metal GPU instances. They need full control over the operating system, kernel parameters, and direct access to the GPU hardware for their model deployment. They are willing to manage the underlying infrastructure. Which AWS deployment target provides the full control required? (Select ONE) - A) Amazon SageMaker AI with a custom inference container. - B) Amazon Bedrock Custom Model Import. - C) Amazon EC2 with GPU instances (e.g., P5). - D) Amazon SageMaker Serverless Inference. |
Correct Answer: C Correct Answer Analysis: - C is Correct: Amazon EC2 provides the maximum level of control. The team has root access to the operating system, can install custom kernel parameters, configure direct GPU hardware access, and run custom CUDA binaries without any managed abstraction layers getting in the way. Distractor Analysis: - A is Incorrect: Amazon SageMaker AI manages the underlying instances and operating system. While you can bring a custom container, you do not have root OS access or the ability to modify kernel parameters on the host machine. - B is Incorrect: Amazon Bedrock is a fully managed serverless API. It abstracts away all infrastructure, making it impossible to run custom CUDA kernels. - D is Incorrect: SageMaker Serverless Inference does not even support GPU instances, let alone custom host-level configurations. > Exam Tip: If a requirement demands control down to the OS level, kernel modifications, or direct hardware access, choose Amazon EC2 over managed services like SageMaker or Bedrock. |
| ### Question 8 - Orchestrating Agents with Bedrock AgentCore An AI company is building a multi-agent system where an orchestrator agent needs to route requests to specialized sub-agents, maintain stateful memory across turns, and securely connect to an external PostgreSQL database via an API gateway. They want to use AWS native AI orchestration to minimize operational overhead. Which capability is the most appropriate for this scenario? (Select ONE) - A) Amazon SageMaker Asynchronous Inference. - B) Amazon Bedrock AgentCore. - C) Amazon ECS with a custom LangChain application. - D) Amazon EventBridge with AWS Lambda functions. |
Correct Answer: B Correct Answer Analysis: - B is Correct: Amazon Bedrock AgentCore is a set of modular services explicitly designed for running agents in production. It includes a serverless runtime, memory management, and a gateway that exposes existing APIs/functions as tools, directly supporting the multi-agent, memory, and API gateway requirements natively. Distractor Analysis: - A is Incorrect: SageMaker Asynchronous Inference is an endpoint configuration for long-running, queued predictions, not an agent orchestration framework with memory and API gateway capabilities. - C is Incorrect: Using Amazon ECS with a custom LangChain application would require the team to manually build and operate memory, API gateways, and the agent runtime, violating the "minimize operational overhead" constraint. - D is Incorrect: EventBridge and Lambda lack built-in stateful memory across conversation turns and native agent orchestration protocols. > Exam Tip: For stateful, multi-agent production deployments that need to expose APIs as tools, look to Amazon Bedrock AgentCore for native, low-overhead orchestration. |
| ### Question 9 - High-Throughput Model Isolation A financial services firm runs a fraud detection model that receives 10,000 requests per second and requires sub-10ms latency. They have another model that processes 1 request per minute. They are currently sharing a Multi-Model Endpoint, but the fraud detection model's latency is degrading when the other model is loaded into memory. What is the most effective architecture to resolve this performance issue? (Select ONE) - A) Keep both models on the Multi-Model Endpoint and increase the instance size. - B) Deploy the fraud detection model to a dedicated SageMaker Real-Time Endpoint with high-performance instances and Auto Scaling. - C) Deploy the fraud detection model to a SageMaker Serverless Endpoint. - D) Deploy both models to a SageMaker Batch Transform job. |
Correct Answer: B Correct Answer Analysis: - B is Correct: A model with extremely high throughput (10,000 TPS) and strict latency requirements (sub-10ms) should be isolated on its own dedicated Real-Time Endpoint. This prevents resource contention from memory loading/processing of other models and allows Auto Scaling to be tuned precisely for its specific traffic profile. Distractor Analysis: - A is Incorrect: Increasing the instance size is inefficient and does not guarantee the elimination of contention caused by dynamically loading the other model into memory on a shared fleet. - C is Incorrect: SageMaker Serverless is for intermittent traffic and cannot guarantee sub-10ms latency due to potential cold starts, nor does it currently support the high-throughput, accelerated compute needed for this scale. - D is Incorrect: Batch Transform is for offline, bulk processing, not interactive, high-throughput real-time fraud detection. > Exam Tip: High-throughput, strict-latency models should be deployed on dedicated SageMaker Real-Time endpoints to avoid resource contention with less frequently invoked models. |
| ### Question 10 - Custom Container Orchestration for SQS Workers A video streaming service needs to run a continuous background process that extracts metadata from uploaded videos using a custom ML model packaged in a Docker container. The process must pull messages directly from an Amazon SQS queue, process them one by one, and scale horizontally based on the queue depth. Which deployment strategy is the most appropriate with the least operational overhead for containers? (Select ONE) - A) Deploy the model as a long-running service on Amazon ECS with AWS Fargate, scaling based on SQS queue depth. - B) Use a SageMaker Asynchronous Inference endpoint to process the SQS queue. - C) Deploy the model to a SageMaker Real-Time endpoint and trigger it via EventBridge. - D) Run a custom Python worker on an EC2 instance managed by an Auto Scaling group. |
Correct Answer: A Correct Answer Analysis: - A is Correct: Amazon ECS with AWS Fargate is ideal for running custom containers as long-running workers. You can configure the ECS service to scale based on the ApproximateNumberOfMessagesVisible CloudWatch metric from SQS, directly satisfying the requirement to scale based on queue depth without managing EC2 instances (least operational overhead).Distractor Analysis: - B is Incorrect: SageMaker Asynchronous Inference uses an internal managed queue, not Amazon SQS directly. To use SQS, you would need an intermediary (like Lambda), adding overhead. Also, it is designed for API invocations, not as a continuous SQS polling worker. - C is Incorrect: A SageMaker Real-Time endpoint cannot natively poll from an SQS queue. EventBridge does not trigger endpoints directly based on SQS message arrival in a way that supports 1-by-1 long-running processing. - D is Incorrect: Managing custom Python workers and Auto Scaling groups on EC2 introduces OS patching and instance management, which is higher operational overhead compared to Fargate. > Exam Tip: When you need a custom container to act as a worker polling from an external queue (like SQS) and scaling based on that queue's depth, Amazon ECS with Fargate is the best choice for low overhead. |