Skill 3.1.7: Configure FM deployment, model hosting, and resource allocation

Question 1 - Foundation Model Deployment Strategy

A financial services company has fine-tuned a Llama 3 model on proprietary trading data in their on-premises data center. They want to serve this customized model through a managed API without provisioning or maintaining any GPU instances. The model must support concurrent invocations from multiple internal applications, and the team needs to track token-level usage metrics per application.

Which deployment approach should the ML engineer use to meet these requirements with the least operational overhead?

A) Deploy the fine-tuned model to an Amazon SageMaker real-time endpoint with GPU instances and configure a custom inference container.

B) Import the fine-tuned model into Amazon Bedrock using Custom Model Import and invoke it through the Bedrock API.

C) Package the model in a Docker container and deploy it to Amazon ECS with EC2 GPU instances behind an Application Load Balancer.

D) Upload the model to Amazon SageMaker JumpStart and use the one-click deployment option to create a managed endpoint.

Click to reveal Answer & Explanation

Correct Answer: B

Correct Option Analysis

B is Correct: Amazon Bedrock Custom Model Import supports importing fine-tuned open-weight models (Llama, Mistral, etc.) from Amazon S3 into Bedrock's serverless infrastructure. The model is then served through the standard Bedrock InvokeModel/Converse API without managing endpoints or GPU instances. Bedrock automatically handles scaling, availability, and provides token-level usage metrics through CloudWatch and the Bedrock console.

Distractor Analysis

A is Incorrect: SageMaker real-time endpoints require provisioning and managing GPU instances, configuring scaling policies, and maintaining the endpoint—violating the "no GPU instances" constraint and introducing operational overhead.
C is Incorrect: ECS with EC2 GPU instances requires full container orchestration, cluster management, and load balancer configuration—maximum operational overhead, directly contradicting the requirement.
D is Incorrect: SageMaker JumpStart provides pre-trained models for quick deployment, but it does not accept fine-tuned models from external environments like on-premises data centers. Copying a custom fine-tuned model into JumpStart is not a supported migration path.

Key Takeaway: Amazon Bedrock Custom Model Import is the native path for serving externally fine-tuned open-weight foundation models without managing any endpoint infrastructure.

Question 2 - Provisioned Throughput vs On-Demand

A healthcare analytics team has fine-tuned an Amazon Bedrock foundation model for medical entity extraction. The model will be called by a clinical workflow application requiring guaranteed low-latency responses (under 500ms) during business hours. The application processes approximately 50,000 requests per day, with predictable peak volumes between 9 AM and 5 PM. The compliance team requires consistent performance without throttling during patient-facing operations.

Which capacity configuration should the team select for the fine-tuned model?

A) On-demand inference, as Bedrock automatically scales to handle any request volume.

B) Provisioned Throughput with a specified number of model units covering the expected peak input/output token volume.

C) On-demand inference during off-hours and Provisioned Throughput during business hours using an automated schedule.

D) On-demand inference with a custom throttling policy configured through AWS WAF to cap request rates.

Click to reveal Answer & Explanation

Correct Answer: B

Correct Option Analysis

B is Correct: Fine-tuned (customized) models in Amazon Bedrock require Provisioned Throughput—they cannot be invoked on-demand. Provisioned Throughput guarantees dedicated capacity with predictable latency and no throttling for the committed token throughput. The team should provision enough model units to cover peak hourly input and output token demands during business hours.

Distractor Analysis

A is Incorrect: Bedrock fine-tuned models do not support on-demand inference. Only base foundation models can be invoked on-demand. Attempting to use on-demand for a customized model would result in deployment failure.
C is Incorrect: While conceptually clever, Bedrock does not support programmatic switching between on-demand and Provisioned Throughput for customized models. Customized models are exclusively served through Provisioned Throughput. Bedrock does not offer built-in scheduling of capacity modes.
D is Incorrect: AWS WAF controls HTTP/S traffic entering AWS services but does not apply to the Bedrock API control plane. Moreover, throttling is not a compliance-friendly way to guarantee low-latency clinical workflows—rejected requests would fail the application requirement.

Key Takeaway: A customized Bedrock model (fine-tuned in Bedrock) must be served through Provisioned Throughput, while imported models (Custom Model Import) are invoked on-demand.

Question 3 - Multi-Model Endpoint Design

A retail analytics team is deploying 50 lightweight product categorization models. All models are built using the same XGBoost framework and container. Traffic patterns show that only 8-10 models are queried heavily each day (depending on product updates), while others remain idle for days. The team wants to minimize infrastructure costs while serving all 50 models simultaneously, and they can tolerate a 2-3 second delay for rarely invoked models.

Which deployment architecture BEST satisfies these requirements? (Select ONE)

A) Deploy each model to its own SageMaker serverless endpoint, achieving zero cost for idle models.

B) Deploy all 50 models to a single SageMaker Multi-Model Endpoint using a shared serving container that loads models from S3 on demand.

C) Deploy all models into a SageMaker multi-container endpoint with one container per model.

D) Deploy each model as a separate AWS Lambda function with the model artifacts stored in EFS.

Click to reveal Answer & Explanation

Correct Answer: B

Correct Option Analysis

B is Correct: SageMaker Multi-Model Endpoints (MMEs) support hosting hundreds of models on a single endpoint using one shared serving container. Models are dynamically loaded from Amazon S3 into memory when invoked, while frequently used models remain cached in memory. This minimizes idle infrastructure costs while supporting all 50 models behind one endpoint. The 2-3 second load penalty aligns perfectly with the stated tolerance for rarely invoked models.

Distractor Analysis

A is Incorrect: While serverless endpoints scale to zero, creating 50 separate endpoints introduces significant operational overhead in endpoint management, monitoring, and API gateway routing. Serverless endpoints also may experience cold starts each time an idle model is invoked, but the multi-endpoint architecture is unnecessarily complex when MME provides a simpler solution.
C is Incorrect: Multi-container endpoints support up to 15 containers per endpoint and are designed for different framework requirements or sequential inference pipelines—not for packing many small models with the same framework. The team would still need at least 4 endpoints and would lose the dynamic loading benefit of MMEs.
D is Incorrect: Lambda functions with EFS introduce significant architectural complexity, concurrency limits (default 1000 concurrent invocations), and latency issues with model loading. This pattern is not designed for serving ML models at scale.

Key Takeaway: Multi-Model Endpoints are ideal when many models share the same framework/container and traffic is uneven—you trade occasional load latency for drastically reduced infrastructure costs.

Question 4 - Multi-Container Endpoint for Inference Pipeline

A fraud detection team needs to deploy a two-stage inference workflow. First, a feature engineering container transforms raw transaction data. Second, a model inference container (using PyTorch) generates a fraud probability score. The transformation container must always run before the model container, and results must be returned within 50 milliseconds. The team wants both containers on a single endpoint to minimize network overhead.

Which SageMaker hosting option supports this requirement? (Select ONE)

A) A SageMaker real-time endpoint with an inference pipeline using a multi-container endpoint configuration

B) Two separate SageMaker endpoints connected through a Lambda function for orchestration

C) A SageMaker asynchronous endpoint with both containers in a multi-container configuration

D) A SageMaker serverless endpoint with multi-model configuration

Click to reveal Answer & Explanation

Correct Answer: A

Correct Option Analysis

A is Correct: SageMaker multi-container endpoints (Inference Pipelines) support running up to 15 containers sequentially on a single endpoint. Container A (feature engineering) processes the input and passes results to Container B (model inference), with all data staying within the endpoint environment—eliminating network latency between services and meeting the 50ms latency requirement.

Distractor Analysis

B is Incorrect: Two separate endpoints introduce external network hops between the transformation and inference stages, significantly increasing latency and likely exceeding the 50ms budget. The Lambda orchestration also adds additional invocation overhead and operational complexity.
C is Incorrect: Asynchronous inference is designed for long-running requests (>60 seconds) and queued workloads. It cannot meet a 50 millisecond synchronous response requirement, and queuing introduces unpredictable delays.
D is Incorrect: Serverless endpoints do not support multi-container configurations or inference pipelines. They are restricted to single-model serving, and the cold-start risk would make a 50ms guarantee unreliable.

Key Takeaway: Multi-container endpoints (Inference Pipelines) keep sequential ML processing steps within a single endpoint environment, crucial when low-latency budgets prohibit inter-service network hops.

Question 5 - Foundation Model Self-Hosting vs Bedrock

A startup is building a real-time coding assistant that must generate completions in under 200 milliseconds. Their model is a large open-weight model (70B parameters) that has been fine-tuned on proprietary code. The team evaluated Amazon Bedrock Custom Model Import but discovered the required model architecture isn't currently supported. They need full control over the serving stack (custom tokenizer, custom inference optimization), and their budget allows for dedicated infrastructure.

Which deployment approach is most appropriate?

A) Package the model into a custom SageMaker inference container with GPU-accelerated instances, deployed as a real-time endpoint with auto scaling.

B) Wait until Bedrock adds support for the model architecture and use Custom Model Import.

C) Deploy the model on AWS Lambda using a custom container image with the model cached in the Lambda layer.

D) Use Amazon SageMaker JumpStart to deploy the model directly, as it supports all custom model architectures.

Click to reveal Answer & Explanation

Correct Answer: A

Correct Option Analysis

A is Correct: When a model cannot be imported into Bedrock (unsupported architecture) and requires custom serving stack control (custom tokenizer, custom inference optimizations), self-hosting on SageMaker is the correct path. A real-time endpoint with GPU instances supports the 200ms latency requirement and enables full control over container configuration, model optimization, and scaling.

Distractor Analysis

B is Incorrect: Waiting for Bedrock support is not a viable engineering decision for an active product roadmap. Bedrock custom model import has a defined list of supported architectures, and betting on uncertain future support would stall development and violate the team's timeline requirements.
C is Incorrect: AWS Lambda has a maximum deployment package size of 10GB (container image) and 6 vCPUs. A 70B parameter model requires hundreds of GB of GPU memory, making Lambda fundamentally unsuitable for this workload. Lambda also lacks GPU acceleration.
D is Incorrect: SageMaker JumpStart provides access to a curated catalog of pre-trained models, not a mechanism for serving arbitrary fine-tuned models with custom tokenizers and serving configurations. Assuming JumpStart can deploy "all custom model architectures" is factually incorrect.

Key Takeaway: When Bedrock Custom Model Import doesn't support your architecture, self-hosting on SageMaker with custom inference containers is the correct fallback for low-latency, high-control deployment requirements.

Question 6 - Retrieval Configuration for RAG

An enterprise legal research platform uses Amazon Bedrock Knowledge Bases with OpenSearch Serverless as its vector store. Users report that searches frequently return outdated contracts from completed negotiations. The vector similarity search retrieves relevant legal concepts correctly, but the results include documents from closed matters that should not be referenced. The team wants to ensure the retrieved results exclude documents with status "Closed" or "Expired" before semantic search is performed.

Which retrieval configuration change should the ML engineer implement?

A) Add a metadata filter to exclude documents where status equals "Closed" or "Expired" before vector similarity search runs.

B) Increase the number of retrieved passages (top-K) to push closed documents further down the result list.

C) Implement hybrid search with keyword matching to better identify closed documents.

D) Add a reranking model to deprioritize closed documents during the scoring phase.

Click to reveal Answer & Explanation

Correct Answer: A

Correct Option Analysis

A is Correct: Metadata filtering in Bedrock Knowledge Bases (and OpenSearch Serverless) filters out documents based on metadata attributes (e.g., status != "Closed") before the vector similarity search executes. This ensures the candidate set completely excludes stale or out-of-scope documents, addressing the root cause of the complaint.

Distractor Analysis

B is Incorrect: Increasing top-K widens the retrieval set, which would introduce more outdated documents into the prompt rather than eliminating them. The complaint is about relevance of the candidate set, not about too few results being returned.
C is Incorrect: Hybrid search combines vector similarity with keyword matching (e.g., BM25). This improves exact-term matching but does not solve the problem of closed documents appearing in results. Closed documents would still match if they contain the same legal terms.
D is Incorrect: Reranking reorders already-retrieved candidates based on semantic relevance scores. It cannot remove documents from the candidate set that the initial vector search already retrieved. More importantly, a closed document might still be semantically relevant and would not be deprioritized by a reranker.

Key Takeaway: Metadata filtering is the correct tool when specific document attributes (status, date, department) must exclude documents before semantic similarity is computed.

Question 7 - SageMaker Inference Component and Scale-to-Zero

A development team runs a SageMaker real-time endpoint for a QA testing environment. The endpoint serves a text classification model that is only used during weekday testing. The team wants to minimize costs by allowing the endpoint to scale down to zero instances when no requests have arrived for 30 minutes, then automatically scale back up when a new request arrives. They accept that the first request after scaling will experience a cold start delay.

Which configuration achieves this scale-to-zero behavior for a real-time endpoint? (Select ONE)

A) Configure Application Auto Scaling with a custom CloudWatch alarm that triggers scale-in to zero, and scale-out when the SageMaker NoCapacityInvocation metric is emitted.

B) Deploy the model to a SageMaker serverless endpoint, which natively scales to zero without any additional configuration.

C) Set the initial instance count to zero in the endpoint configuration and enable auto scaling with the SageMaker Invocations metric.

D) Scale-to-zero is not possible for SageMaker real-time endpoints; use asynchronous inference instead.

Click to reveal Answer & Explanation

Correct Answer: B

Correct Option Analysis

B is Correct: SageMaker Serverless Inference natively scales to zero and provisions capacity on-demand when the first request arrives. This is the simplest solution for intermittent traffic with idle periods, eliminating endpoint management entirely and providing built-in cost optimization without extra auto scaling configuration.

Distractor Analysis

A is Incorrect: While real-time endpoints can technically scale to zero using inference components and a custom scaling policy triggered by the NoCapacityInvocation metric, this solution is overly complex compared to serverless inference. The question doesn't require real-time endpoint features (VPC, accelerators, multi-model), so serverless is the simpler and more operationally efficient choice.
C is Incorrect: SageMaker real-time endpoints do not allow InitialInstanceCount to be set to zero. The minimum is one instance, and standard auto scaling configuration cannot scale down to zero using the standard Invocations metric alone.
D is Incorrect: Asynchronous inference is designed for long-running requests (payloads up to 1GB, processing up to 60 minutes), not for synchronous text classification tasks. Scale-to-zero is supported for real-time endpoints with inference components (though complex), and it's native for serverless endpoints.

Key Takeaway: Serverless inference is the default scale-to-zero solution for intermittent, synchronous workloads—real-time scale-to-zero requires inference components and custom scaling policies that introduce operational complexity.

Question 8 - Agent Deployment with MCP Gateway

A customer service organization wants to deploy an Amazon Bedrock agent that helps users check order status, initiate returns, and update payment methods. These operations are exposed through the company's existing REST APIs (OrderService, ReturnService, PaymentService) running on Amazon EKS. The architecture team wants the agent to discover and call these APIs without recreating them as Lambda functions or Bedrock-specific tool definitions. They also want to use an open standard so future non-AWS systems can integrate with the same agent.

Which Bedrock capability should the team use for this integration?

A) Amazon Bedrock AgentCore with the Model Context Protocol (MCP) gateway to expose existing APIs as tools through an open standard.

B) Amazon Bedrock Guardrails to filter unsafe API calls before they reach the company's EKS services.

C) Amazon Bedrock Knowledge Bases to create a searchable index of the REST API documentation.

D) Amazon Bedrock Provisioned Throughput to reserve capacity for the agent's API calls.

Click to reveal Answer & Explanation

Correct Answer: A

Correct Option Analysis

A is Correct: Amazon Bedrock AgentCore includes a gateway (Bedrock AgentCore Gateway) that can expose existing APIs and functions as tools using the Model Context Protocol (MCP). MCP is an open standard that allows AI agents to discover and interact with tools, APIs, and services without custom integration code. This directly enables the agent to call the existing OrderService, ReturnService, and PaymentService APIs without rewriting them.

Distractor Analysis

B is Incorrect: Guardrails provide content filtering, PII redaction, safety checks, and topic restrictions for foundation model inputs/outputs. They do not provide tool/API integration capabilities or enable agents to call external services.
C is Incorrect: Knowledge Bases provide retrieval-augmented generation for document querying. They can retrieve API documentation as text but cannot execute live API calls against the EKS services or maintain stateful business operations (returns, payments).
D is Incorrect: Provisioned Throughput reserves capacity for model inference. It has nothing to do with tool/API integration or enabling agents to call external services.

Key Takeaway: Bedrock AgentCore Gateway with MCP enables agents to call existing APIs using an open standard—this is the preferred integration pattern when building agentic workflows over existing microservices.

Question 9 - Batch Transform for Foundation Model Fine-Tuning Inference

A genomics research institute has fine-tuned a foundation model for protein structure prediction. Every Friday night, their pipeline processes 100,000 protein sequences stored in Amazon S3. The processing generates predictions that are uploaded back to S3, and the researchers review them the following Monday. The model requires GPU acceleration, and the institute wants to minimize costs by avoiding idle inference capacity during the week.

Which inference strategy should the ML engineer implement?

A) Deploy the model to a SageMaker real-time endpoint with auto scaling to handle the Friday workload surge.

B) Run a SageMaker Batch Transform job on Friday nights using GPU-optimized instances that start, process the S3 data, and shut down.

C) Deploy the model to a SageMaker asynchronous endpoint with scale-to-zero configuration for weekday idle periods.

D) Import the model into Amazon Bedrock Custom Model Import and invoke it on-demand from the pipeline.

Click to reveal Answer & Explanation

Correct Answer: B

Correct Option Analysis

B is Correct: SageMaker Batch Transform processes large, pre-assembled datasets in bulk with no live caller waiting. The job provisions GPU instances on-demand, processes all 100,000 sequences from S3, writes predictions back to S3, and immediately releases all compute resources. This perfectly matches the weekly schedule pattern and ensures zero idle costs between jobs.

Distractor Analysis

A is Incorrect: Real-time endpoints are designed for synchronous, interactive traffic with users/processes waiting for responses. An endpoint running 24/7 (even with auto scaling to minimum instance count) incurs idle infrastructure costs throughout the week, violating the cost-minimization requirement.
C is Incorrect: Asynchronous inference handles individual large-payload requests queued throughout the day. The genomics workload arrives in bulk on a schedule, making batch processing more appropriate. Additionally, asynchronous endpoints are optimized for long-running per-request processing (up to 60 minutes), not bulk dataset processing.
D is Incorrect: Bedrock Custom Model Import supports only specific open-weight architectures and serves through the Bedrock API. A proprietary protein-structure-prediction model built in a research environment is unlikely to match supported architectures, and Bedrock invocation doesn't support batch-style bulk processing of 100K inputs as a single job.

Key Takeaway: When data arrives in bulk on a schedule and no one waits for individual responses, Batch Transform is the optimal choice—it provisions compute only during the job and releases it immediately after.

Question 10 - Resource Allocation for Foundation Model Workloads

A production team is configuring Amazon Bedrock Provisioned Throughput for a fine-tuned summarization model. They measured their average workload as 2,000 input tokens and 500 output tokens per request, with 100 requests per minute during business hours. They want to right-size their committed capacity to handle peak volumes without over-provisioning. However, they notice the Bedrock console requires them to specify capacity in "model units" rather than instances or vCPUs.

What does a model unit represent in Amazon Bedrock Provisioned Throughput?

A) One dedicated GPU instance serving the model, similar to a SageMaker ml.g5 instance.

B) A unit of throughput capacity measured in tokens per minute (input and output counts specified separately).

C) One concurrent invocation slot that processes a single request at a time.

D) One vCPU and 4GB of memory allocated to the model serving infrastructure.

Click to reveal Answer & Explanation

Correct Answer: B

Correct Option Analysis

B is Correct: Amazon Bedrock uses model units to measure Provisioned Throughput capacity. Each model unit represents a specified amount of tokens per minute—both input tokens and output tokens are accounted for separately. For example, one model unit for a particular model might provide 20,000 input tokens per minute and 8,000 output tokens per minute. Buyers commit to a number of model units based on their expected peak token throughput.

Distractor Analysis

A is Incorrect: Model units are not directly tied to specific instance types or GPU counts. Bedrock abstracts the underlying infrastructure, allowing you to think in terms of throughput rather than hardware provisioning. This is a key benefit of using a managed foundation model service.
C is Incorrect: While concurrency affects throughput, a model unit is not defined as a single request slot. Multiple concurrent requests can be served by a single model unit as long as the aggregate token throughput stays within the unit's capacity.
D is Incorrect: Bedrock does not expose CPU/memory ratios to customers. The abstraction level is tokens per minute, not raw compute resources. This distractor confuses Bedrock's model units with EC2/vCPU concepts that apply to self-hosted infrastructure.

Key Takeaway: Provisioned Throughput in Bedrock is sized by model units—capacity measures in tokens per minute (input and output separately)—not by instances, vCPUs, or concurrent request slots.

Question 11 - Reranking Configuration for Retrieval Quality

An AI engineering team uses Amazon Bedrock Knowledge Bases with vector search for a customer support chatbot. Currently, retrieval returns 20 passages, and users report that while relevant answers appear in the retrieved set, the top-ranked passages frequently miss the specific details needed. The correct passage often appears around position 8-10. The team wants to improve the ordering of retrieved results without reducing recall or re-embedding the entire knowledge base.

Which configuration change should the team implement?

A) Enable a reranking model in the Bedrock Knowledge Base configuration to reorder the top-K candidates by semantic relevance.

B) Reduce the number of returned passages from 20 to 5 so the correct passage appears closer to the top.

C) Switch from vector search to hybrid search to improve keyword matching precision.

D) Increase the embedding dimensionality of the vector index to capture more semantic detail.

Click to reveal Answer & Explanation

Correct Answer: A

Correct Option Analysis

A is Correct: Reranking applies a cross-encoder model to re-evaluate query-document pairs from the initial vector search results. The reranker computes a deeper semantic relevance score for each candidate and reorders the list, moving the most contextually relevant passages to the top. This directly addresses the ordering problem without altering recall (all 20 passages remain available) and without re-embedding the corpus.

Distractor Analysis

B is Incorrect: If the correct passage currently ranks at position 8-10, reducing top-K to 5 would completely remove it from the retrieved set, eliminating any chance of the LLM using that information. This reduces recall and worsens answer quality.
C is Incorrect: Hybrid search adds keyword matching (BM25) alongside vector similarity. While this can improve exact-term retrieval, the problem is not about missing exact keywords—the correct passage is already retrieved but misordered. Switching search modes doesn't solve ranking order directly.
D is Incorrect: Higher-dimensional embeddings may slightly improve semantic expressiveness but require re-embedding all documents and re-indexing the vector store—a costly operation. Moreover, bi-encoder embeddings still suffer from ranking limitations compared to cross-encoder rerankers, so the ordering issue would persist.

Key Takeaway: Reranking is a second-pass relevance scoring mechanism that reorders already-retrieved candidates—it improves ranking quality without changing recall, re-embedding documents, or switching search strategies.

Question 12 - Custom Model Import Architecture Validation

A machine learning team has fine-tuned a Llama 3.1 8B model using Hugging Face Transformers on Amazon EC2. They want to serve this model through Amazon Bedrock Custom Model Import to avoid managing endpoints. Before initiating the import process, they need to prepare the model artifacts in the format Bedrock expects.

Which artifact format and storage location is required for Bedrock Custom Model Import?

A) The model weights in Hugging Face safetensors format uploaded to an Amazon S3 bucket, with the model architecture included in Bedrock's supported architectures list.

B) The model exported as a TorchScript artifact and uploaded to Amazon ECR as a container image.

C) The model compressed as a ZIP file containing the Python environment and uploaded to Amazon S3.

D) The model converted to ONNX format and deployed through AWS Lambda layers.

Click to reveal Answer & Explanation

Correct Answer: A

Correct Option Analysis

A is Correct: Amazon Bedrock Custom Model Import accepts fine-tuned weights for supported open-weight architectures (Llama, Mistral, Mixtral, etc.) in Hugging Face safetensors format. The artifacts are uploaded to Amazon S3, and Bedrock imports them into its serverless serving infrastructure. The architecture must be on the supported list before import can succeed.

Distractor Analysis

B is Incorrect: Bedrock Custom Model Import does not use ECR container images. This distractor confuses Bedrock import with SageMaker container-based deployment or AWS Lambda container patterns. Bedrock abstracts the serving container entirely.
C is Incorrect: While S3 is correct, the format is not a generic ZIP with a Python environment. Bedrock requires model weights in specific formats (safetensors for Hugging Face models) with a specific file layout, not an arbitrary compressed environment.
D is Incorrect: Bedrock Custom Model Import does not use ONNX format or Lambda for deployment. Lambda cannot host 8B parameter models (memory/GPU limitations), and ONNX conversion is not part of the Bedrock import pipeline.

Key Takeaway: Bedrock Custom Model Import accepts Hugging Face safetensors weights in S3 for supported open-weight architectures—no container, ONNX, or TorchScript packaging required.

Question 13 - Hybrid Search Configuration

An e-commerce search team uses Amazon Bedrock Knowledge Bases with OpenSearch Serverless. Customers often search for exact product identifiers (SKUs) like "AC-2345-BLU" that appear verbatim in product manuals. However, vector similarity search often retrieves semantically related but incorrect products because embeddings capture general concepts rather than exact alphanumeric sequences. The team wants to enable hybrid search to improve exact-match retrieval.

Which configuration must be in place before hybrid search can be enabled in Bedrock Knowledge Bases?

A) The OpenSearch Serverless vector collection must include a filterable text field containing the document content or SKU values that can be matched by keyword search.

B) A separate Amazon Kendra index must be created and connected to the Bedrock Knowledge Base for keyword matching.

C) A custom Lambda function must intercept the query and rewrite it using a BM25 algorithm before sending to the vector store.

D) The vector store must be migrated to Amazon RDS PostgreSQL with pgvector to support combined keyword and vector search.

Click to reveal Answer & Explanation

Correct Answer: A

Correct Option Analysis

A is Correct: Hybrid search in Bedrock Knowledge Bases combines vector similarity with keyword matching (BM25). For keyword search to work, the underlying vector store must contain a filterable text field (stored in the index as a searchable text field). In OpenSearch Serverless, documents must have a text field configured in the index mapping that the BM25 algorithm can query against. Without this text field, hybrid search cannot execute keyword matching.

Distractor Analysis

B is Incorrect: Kendra is a separate intelligent search service and is not used as a keyword-matching backend for Bedrock Knowledge Bases hybrid search. Bedrock integrates with vector stores like OpenSearch, Pinecone, Aurora PostgreSQL, Redis, etc., not Kendra.
C is Incorrect: Bedrock Knowledge Bases natively support hybrid search without requiring custom Lambda functions. Adding a Lambda-based BM25 rewrite introduces unnecessary complexity and bypasses Bedrock's built-in retrieval orchestration.
D is Incorrect: While Aurora PostgreSQL with pgvector is a supported vector store for Bedrock Knowledge Bases, OpenSearch Serverless also supports hybrid search with proper field configuration. Migration is unnecessary when OpenSearch already supports the required functionality.

Key Takeaway: Hybrid search capability depends on the vector store having a filterable text field configured—without it, keyword matching cannot be performed alongside vector similarity.

Question 14 - Multi-Container Endpoint vs Multi-Model Endpoint Decision

A healthcare ML team plans to deploy:

Model A: Radiology image classifier (PyTorch, 2GB model)
Model B: Medical text summarizer (Hugging Face Transformers, 500MB model)
Model C: Patient risk scorer (XGBoost, 50MB model)

All three models have high and consistent traffic throughout the day, requiring standalone scaling policies. The team wants to minimize endpoint management complexity.

Which SageMaker endpoint strategy is MOST appropriate?

A) Deploy all three models on one multi-model endpoint, with a single serving container supporting all three frameworks.

B) Deploy each model to its own dedicated single-model real-time endpoint with independent auto scaling policies.

C) Deploy Models A and B in a multi-container inference pipeline (sequential processing), and Model C on a separate endpoint.

D) Deploy all three models on a multi-container endpoint invoked by direct container name.

Click to reveal Answer & Explanation

Correct Answer: B

Correct Option Analysis

B is Correct: The three models use different frameworks (PyTorch, Hugging Face Transformers, XGBoost), have high and consistent traffic, and require independent scaling policies. Dedicated single-model endpoints are appropriate because each model can scale independently based on its own traffic patterns and latency requirements. This approach also avoids resource contention between high-traffic models sharing a fleet.

Distractor Analysis

A is Incorrect: Multi-model endpoints require models to share the same serving container (same framework/stack). PyTorch, Hugging Face Transformers, and XGBoost require different containers, making this configuration technically infeasible. Additionally, high-traffic models would contend for resources on the shared fleet.
C is Incorrect: An inference pipeline implies sequential processing where output from one container feeds into another. The models in this scenario are independent (image classification and text summarization don't feed into each other), making a pipeline semantically incorrect.
D is Incorrect: While multi-container endpoints support up to 15 containers with direct invocation by name, they do not provide independent scaling per container. All containers share the endpoint's compute resources, and high-traffic models would compete for capacity. Dedicated endpoints are better for high, consistent workloads.

Key Takeaway: Dedicated single-model endpoints are the right choice when models have high consistent traffic, different frameworks, and require independent scaling—sharing a fleet means sharing its limits.

Question 15 - Foundation Model Deployment: Bedrock vs SageMaker

A startup has built a proprietary customer churn prediction model using a gradient-boosting algorithm (XGBoost) that they want to deploy for real-time inference. The model has no foundation model architecture and is purely a classical ML model. The team is evaluating whether to use Amazon Bedrock or Amazon SageMaker.

Which statement correctly identifies the appropriate deployment service?

A) Amazon Bedrock supports all ML models including XGBoost through Custom Model Import, so the team should import their model into Bedrock.

B) Amazon SageMaker is required because Bedrock only serves foundation models—XGBoost is a classical ML model that Bedrock cannot host.

C) Either service works; the team should choose based on whether they want managed hosting (Bedrock) or self-managed hosting (SageMaker).

D) Amazon Bedrock supports XGBoost through the Bedrock Marketplace, where classical models can be listed and served.

Click to reveal Answer & Explanation

Correct Answer: B

Correct Option Analysis

B is Correct: Amazon Bedrock is exclusively a foundation model service. It serves pre-trained FMs (like Claude, Llama, Titan) through APIs and supports importing custom fine-tuned weights for supported open-weight architectures. Classical ML models (XGBoost, Random Forest, logistic regression, etc.) are not FMs and cannot be hosted in Bedrock. SageMaker is the appropriate service for classical ML model deployment with real-time endpoints, serverless inference, async, or batch options.

Distractor Analysis

A is Incorrect: Custom Model Import is specifically designed for open-weight foundation model architectures (Llama, Mistral, Mixtral, etc.), not classical ML models like XGBoost. The import process expects FM weight formats and architectures, not gradient-boosting tree parameters.
C is Incorrect: This statement creates a false equivalence. Bedrock and SageMaker are not alternative hosting options for the same model. Bedrock serves only foundation models; SageMaker serves all ML models (classical and FM). For XGBoost, Bedrock is not an option at all.
D is Incorrect: Amazon Bedrock Marketplace is not a real AWS feature for serving classical ML models. Bedrock's model catalog consists of foundation models from various providers (Anthropic, Meta, Cohere, etc.), not classical ML algorithms.

Key Takeaway: Bedrock is exclusively for foundation models—classical ML models (XGBoost, etc.) must be deployed on SageMaker or other compute services, never on Bedrock.

Question 16 - SageMaker Serverless Endpoint Limitations

An ML team is designing a deployment for a fraud detection model. Critical requirements include:

Model must be accessible only from within the company's private VPC
GPU acceleration is required for low-latency inference
Multiple model versions must be hosted on a single endpoint for A/B testing

Which SageMaker inference option satisfies ALL requirements?

A) A SageMaker real-time endpoint with GPU instances, VPC configuration, and multi-model endpoint for hosting multiple versions.

B) A SageMaker serverless endpoint with VPC configuration, GPU acceleration, and production variant with multiple model versions.

C) A SageMaker asynchronous endpoint with GPU instances and VPC configuration.

D) A SageMaker real-time endpoint with GPU instances and VPC configuration, using inference components to host multiple model copies.

Click to reveal Answer & Explanation

Correct Answer: D

Correct Option Analysis

D is Correct: Real-time endpoints support GPU instances, VPC configuration, and (via inference components) multiple models on a single endpoint. Inference components allow you to deploy multiple model versions or configurations on the same endpoint, sharing the GPU infrastructure while maintaining independent scaling properties. This satisfies all three constraints.

Distractor Analysis

A is Incorrect: While real-time endpoints with multi-model hosting (MME) support GPU and VPC configuration, multi-model endpoints assume all models share the same serving container and are designed for many small models with uneven traffic. For A/B testing with just 2 versions, multi-model endpoints introduce unnecessary complexity and cold-start penalties. Inference components (Option D) are a better match for versioned model deployment on shared infrastructure.
B is Incorrect: Serverless endpoints do not support VPC configuration, do not support GPU/accelerated instances, and do not support multi-model hosting. They are restricted to CPU-only, single-model serving outside private VPCs. This option violates all three requirements.
C is Incorrect: Asynchronous inference is designed for long-running or large-payload requests where callers do not wait for responses. Fraud detection requires synchronous, real-time responses (usually under 100ms). The asynchronous model is architecturally incorrect for this use case.

Key Takeaway: Serverless endpoints are ruled out by requirements for VPC, GPU acceleration, or multi-model hosting—real-time endpoints with inference components support all these features.

Question 17 - Query Decomposition in RAG

A financial research assistant built on Amazon Bedrock Knowledge Bases struggles with complex queries like "Compare our Q3 revenue growth with our competitor's Q3 revenue growth and summarize the impact of currency fluctuations on both companies." When the RAG system retrieves passages using this compound question, it often gets results about currency fluctuations but misses passages about revenue growth or competitor data.

Which retrieval configuration technique should the ML engineer apply to improve retrieval quality for this query type?

A) Enable query decomposition so the system breaks the compound question into sub-queries (revenue growth, competitor revenue, currency impact) that retrieve independently against the knowledge base.

B) Increase the number of retrieved passages (top-K) to a higher value like 50 to capture all relevant topics in one retrieval pass.

C) Apply a stricter metadata filter to exclude documents that don't contain both "revenue" and "currency" in their metadata.

D) Use a larger embedding model with higher dimensionality to better capture the compound query semantics.

Click to reveal Answer & Explanation

Correct Answer: A

Correct Option Analysis

A is Correct: Query decomposition breaks a compound or multi-part question into multiple sub-queries, each targeting a specific topic (e.g., "Q3 revenue growth", "competitor Q3 revenue", "currency fluctuation impact"). Each sub-query retrieves independently, ensuring coverage of all topics in the final retrieval set. This technique directly addresses the issue of a compound query overwhelming vector similarity search and retrieving only the dominant topic.

Distractor Analysis

B is Incorrect: Increasing top-K (e.g., to 50) might incidentally include more relevant passages, but it also introduces significant noise—unrelated passages dilute the context window and can confuse the LLM. Moreover, the dominant topic (currency) would still dominate the similarity scores, pushing revenue growth passages further down.
C is Incorrect: Metadata filtering narrows the candidate set before search. Applying a filter requiring both "revenue" and "currency" in metadata would eliminate passages that discuss revenue growth without currency mentions, reducing recall and potentially removing critical information the model needs.
D is Incorrect: Larger embedding models improve semantic representation but do not solve the compound query problem. A single compound query embedding will still be dominated by the most prominent topic and struggle to capture multiple distinct concepts with equal weight. Re-embedding documents also requires re-indexing the entire corpus.

Key Takeaway: Query decomposition is the correct technique for compound questions—it retrieves each sub-topic independently and merges results, ensuring coverage across all dimensions of the query.

Question 18 - Agent Communication Protocol for Cross-Service Integration

A logistics company is building an AI agent using Amazon Bedrock that needs to:

Check inventory levels from an SAP system
Query shipment tracking from a legacy mainframe
Update delivery ETA in a microservice

The SAP system and mainframe are not cloud-native and cannot be re-architected. The microservice team wants to expose their service using an open standard protocol that supports future AI agent interactions. The agent itself will be hosted on Amazon Bedrock but must communicate with these external systems.

Which approach enables the Bedrock agent to communicate with all three systems using an open standard?

A) Create Lambda functions for each system integration and register them as Bedrock agent action groups (function calling).

B) Use the Model Context Protocol (MCP) gateway in Bedrock AgentCore to expose all three systems as MCP-compliant tools that the agent can discover and call.

C) Migrate all three systems into AWS services (SAP to ECS, mainframe to Lambda, microservice to API Gateway) before enabling agent communication.

D) Use Amazon Bedrock Knowledge Bases to create document indices for each system, and have the agent query the indices rather than calling the systems directly.

Click to reveal Answer & Explanation

Correct Answer: B

Correct Option Analysis

B is Correct: The Model Context Protocol (MCP) is an open standard for AI agents to communicate with tools, APIs, and data sources. Bedrock AgentCore Gateway supports MCP, allowing the agent to discover and invoke tools that wrap the SAP system, mainframe, and microservice—without requiring cloud migration or re-architecting. The open standard ensures future non-AWS AI systems can also integrate.

Distractor Analysis

A is Incorrect: Lambda-based action groups (function calling) are a Bedrock-specific integration pattern. While functional, it requires creating and maintaining Lambda adapters for each system and is not based on an open standard like MCP. The requirement explicitly asks for an open standard to support future interoperability with non-AWS agents.
C is Incorrect: Re-architecting SAP and mainframe systems into AWS services is a massive undertaking that contradicts the constraint that these systems "cannot be re-architected." The requirement is to communicate with existing systems, not replace them.
D is Incorrect: Knowledge Bases retrieve document content for RAG applications. They cannot execute operations (update ETA, query live inventory) against external systems. This approach fundamentally misunderstands the difference between information retrieval and tool execution.

Key Takeaway: MCP gateway in Bedrock AgentCore is the modern approach for connecting agents to existing enterprise systems using an open standard—enabling discovery, tool calling, and future interoperability without re-architecting the systems.

Question 19 - SageMaker Asynchronous Inference Payload Handling

A manufacturing quality control team runs a computer vision model that analyzes high-resolution defect images. Each image is 50-100 MB in size, and processing takes 3-5 minutes per image. Multiple factory-floor cameras send images throughout the day, and nobody is waiting for immediate results. Results need to be stored in S3 with SNS notifications when processing completes.

Which SageMaker inference option should the team use?

A) A real-time endpoint with GPU instances, accepting base64-encoded images.

B) A SageMaker asynchronous inference endpoint that accepts large payloads (up to 1 GB) and queues requests automatically.

C) A SageMaker serverless endpoint with increased timeout configuration.

D) A Lambda function that processes images and writes results to S3.

Click to reveal Answer & Explanation

Correct Answer: B

Correct Option Analysis

B is Correct: SageMaker Asynchronous Inference is specifically designed for large payloads (up to 1 GB per request) and long processing times (up to 15 minutes default, extendable to 60 minutes). Requests are queued automatically, processed without a blocked caller, and results are written to S3 with optional SNS notifications. The endpoint can scale down to zero when the queue is empty, matching the intermittent arrival pattern.

Distractor Analysis

A is Incorrect: Real-time endpoints have a 60-second timeout and a 6 MB payload limit. The 50-100 MB images exceed the payload cap by an order of magnitude. Processing times of 3-5 minutes would also timeout. Real-time is unsuitable for this workload.
C is Incorrect: Serverless endpoints also enforce a 60-second timeout and 4 MB payload limit. They cannot be configured for extended timeout periods. The image sizes and processing durations far exceed serverless capabilities.
D is Incorrect: Lambda has a 10 GB ephemeral storage limit (better for payload), but processing is limited to 15 minutes (with timeout configuration) and memory/CPU limits. More importantly, Lambda lacks GPU acceleration needed for computer vision inference. This option is not designed for model serving workloads.

Key Takeaway: Asynchronous inference handles large payloads (up to 1 GB) and long processing (up to 60 minutes) with automatic queuing and scale-to-zero—perfect for intermittent, non-blocking inference patterns.

Question 20 - Bedrock Custom Model Import vs Fine-Tuning Decision

A startup has trained a custom Llama 3.1 model using Low-Rank Adaptation (LoRA). They used AWS Trainium instances on SageMaker and now want to serve the model. They are considering:

Importing the LoRA-merged model into Amazon Bedrock via Custom Model Import
Fine-tuning the model directly in Amazon Bedrock

The team is currently using their custom model with 500,000 requests per month, and they expect to scale to 5 million requests per month. They want to minimize per-request costs while maintaining the flexibility to update model weights frequently (weekly retraining).

Which approach is more cost-effective for this long-term, high-volume workload?

A) Import the fine-tuned model into Bedrock via Custom Model Import, which allows on-demand pricing suitable for high volumes.

B) Fine-tune the base model directly in Bedrock and serve it through Provisioned Throughput to achieve predictable costs at scale.

C) Use SageMaker real-time endpoints with auto scaling to handle the growing volume.

D) Use a multi-model endpoint in SageMaker to host multiple versions of the model simultaneously.

Click to reveal Answer & Explanation

Correct Answer: A

Correct Option Analysis

A is Correct: Bedrock Custom Model Import allows serving custom models through the Bedrock API on-demand without committing to reserved capacity. For a startup expecting rapid growth (500K to 5M requests/month), on-demand pricing provides flexibility and scales automatically. The team can update model weights weekly by re-importing new merged weights into Bedrock. This eliminates endpoint management overhead and committed capacity costs that may become suboptimal as traffic patterns evolve.

Distractor Analysis

B is Incorrect: Bedrock fine-tuning (customizing the base model in Bedrock) creates a model that must be served through Provisioned Throughput. This requires committing to a fixed number of model units for a term, which may not be cost-effective for rapidly growing or changing workloads. Weekly retraining would require re-provisioning through fine-tuning jobs, adding overhead compared to direct weight import.
C is Incorrect: SageMaker real-time endpoints require managing GPU instances, configuring scaling policies, and paying for infrastructure even when idle. While suitable for some workloads, this violates the "minimize per-request costs" and "managed API" preferences stated in the scenario.
D is Incorrect: Multi-model endpoints are designed for many small models with uneven traffic sharing a framework. This scenario involves one large foundation model with consistent high-volume traffic—a poor fit for MME's dynamic loading pattern and cold-start penalties.

Key Takeaway: For custom foundation models with high or growing volume, Bedrock Custom Model Import provides on-demand pricing and eliminates capacity commitment, while Bedrock fine-tuned models require Provisioned Throughput, which adds cost commitment.