Skip to content

Skill 3.1.1: Select appropriate compute environments and deployment targets

Question 1 - Inference Strategy Selection for Payment Fraud Detection

A financial services company has deployed a fraud detection model that scores every credit card transaction in real time. The model must return a fraud probability score within 150 milliseconds because customers are actively waiting at the point-of-sale terminal. Traffic patterns show consistent volume throughout the day with sharp 3-4x spikes during holiday shopping events. The ML engineering team wants to minimize operational overhead while ensuring high availability during these predictable traffic surges.

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

  • A) Deploy the model to an Amazon SageMaker Serverless Inference endpoint with provisioned concurrency set to the peak traffic level.
  • B) Deploy the model to an Amazon SageMaker real-time endpoint with Application Auto Scaling configured on the SageMakerVariantInvocationsPerInstance metric.
  • C) Deploy the model to Amazon SageMaker Asynchronous Inference with an SQS queue to buffer requests during traffic spikes.
  • D) Package the model as an AWS Lambda function with provisioned concurrency configured for peak shopping periods.
  • E) Deploy the model to an Amazon ECS cluster with a target tracking scaling policy based on CPU utilization.
Click to reveal Answer & Explanation

Correct Answer: B

Correct Answer Analysis

  • B is Correct: A real-time endpoint with Auto Scaling is the standard SageMaker pattern for synchronous, latency-critical inference with variable but continuous traffic. The endpoint maintains warm instances to eliminate cold-start latency, while Auto Scaling on invocation metrics dynamically adjusts capacity during shopping events without manual intervention.

Distractor Analysis

  • A is Incorrect: Serverless inference is designed for intermittent traffic with genuine idle gaps. While provisioned concurrency can mitigate cold starts, paying for peak-level provisioned concurrency on a serverless endpoint eliminates the cost advantage of serverless while still lacking the fine-grained scaling control of real-time endpoints.
  • C is Incorrect: Asynchronous Inference queues requests and processes them in the background, which is fundamentally incompatible with a 150-millisecond synchronous latency requirement. The customer at the point-of-sale cannot wait for queued processing.
  • D is Incorrect: While Lambda can serve light inference workloads, a fraud model typically requires GPU acceleration and has memory/compute requirements that exceed Lambda's constraints (10 GB memory, 6 vCPUs, no GPU). Additionally, 150ms cold starts on Lambda would violate the latency budget.
  • E is Incorrect: ECS provides container orchestration but requires the team to manage the entire serving infrastructure (load balancers, scaling policies, health checks, container images), violating the constraint to minimize operational overhead. SageMaker real-time endpoints provide managed hosting with built-in Auto Scaling.

Key Takeaway: Steady or spiky-but-continuous traffic with strict latency requirements belongs on a SageMaker real-time endpoint with Auto Scaling; reserve serverless for truly intermittent traffic with idle gaps.

Question 2 - Foundation Model Deployment Strategy

A healthcare technology company has fine-tuned a Meta Llama 3.1 8B model on proprietary medical coding data using their on-premises GPU cluster. The model artifacts are saved in Hugging Face format and uploaded to an Amazon S3 bucket. The company wants to serve this custom model through the Amazon Bedrock API without provisioning or managing any endpoints or instances. Their compliance team requires that model invocations use AWS IAM authentication.

Which capability should the ML engineer use to meet these requirements? (Select ONE)

  • A) Deploy the model to an Amazon SageMaker JumpStart endpoint with the custom model artifacts.
  • B) Import the model using Amazon Bedrock Custom Model Import and invoke it through the InvokeModel API.
  • C) Create a Provisioned Throughput request for the Llama 3.1 8B base model in Amazon Bedrock and attach the fine-tuned weights.
  • D) Package the model in a Docker container and deploy it to Amazon ECS with IAM roles for service authentication.
  • E) Deploy the model to an Amazon SageMaker Multi-Model Endpoint with IAM authentication enabled.
Click to reveal Answer & Explanation

Correct Answer: B

Correct Answer Analysis

  • B is Correct: Amazon Bedrock Custom Model Import is purpose-built for this exact scenario. It supports importing fine-tuned open-weight models (Llama, Mistral, etc.) from S3 into Bedrock's serverless infrastructure, then serving them through the standard Bedrock InvokeModel or Converse APIs with IAM authentication. No endpoint management is required.

Distractor Analysis

  • A is Incorrect: SageMaker JumpStart provides pre-trained models and fine-tuning capabilities, but deploying a custom model through JumpStart still requires creating and managing a SageMaker endpoint. This violates the requirement of "without provisioning or managing any endpoints."
  • C is Incorrect: Provisioned Throughput in Bedrock reserves capacity for base models or models fine-tuned within Bedrock. It cannot attach externally fine-tuned weights to a base model. The import path is the correct mechanism for bringing external customizations.
  • D is Incorrect: While ECS can host the model with IAM authentication, it requires the team to manage containers, scaling, load balancing, and infrastructure—exactly the operational overhead the requirement prohibits.
  • E is Incorrect: Multi-Model Endpoints (MMEs) still require provisioning and managing a SageMaker endpoint fleet. While MMEs are more cost-effective than single-model endpoints, they don't satisfy the "serverless API" requirement.

Key Takeaway: Custom Model Import is the bridge between models fine-tuned outside AWS and Bedrock's managed, serverless inference API—crucially, imported models are invoked on-demand, not through Provisioned Throughput.

Question 3 - RAG Retrieval Configuration

A legal technology company has built a RAG application using Amazon Bedrock Knowledge Bases to answer questions from a corpus of 50,000 legal documents. Users report that the system sometimes returns answers based on outdated case law, and precise legal terms (like "force majeure" or "habeas corpus") are occasionally missed by the semantic search. The ML team needs to improve retrieval quality without increasing the operational overhead of the knowledge base.

Which TWO configurations should the team implement to address these specific issues? (Select TWO)

  • A) Enable hybrid search in the Bedrock Knowledge Base to combine semantic vector search with keyword matching.
  • B) Reduce the number of returned passages from 10 to 3 to minimize noise in the prompt.
  • C) Add metadata filters to exclude documents outside the relevant date range before similarity ranking.
  • D) Increase the embedding dimension from 1024 to 1536 by re-embedding all documents.
  • E) Add a reranking model to reorder the retrieved passages by semantic relevance.
Click to reveal Answer & Explanation

Correct Answers: A and C

Correct Options Analysis

  • A is Correct: Hybrid search combines vector similarity with lexical/keyword search (typically using BM25). This addresses the issue of exact legal terms being missed by embeddings, because keyword matching catches precise terminology that semantic search might blur.
  • C is Correct: The complaint about outdated case law is a filter problem. Metadata filters in Bedrock Knowledge Bases narrow the candidate set to documents within a specific date range before similarity scoring, eliminating stale results at the source.

Distractor Analysis

  • B is Incorrect: Reducing the number of returned passages would decrease recall and potentially drop the correct passage entirely. This addresses prompt noise, not the issues of missed terms or outdated documents described in the scenario.
  • D is Incorrect: Increasing embedding dimensions requires re-embedding the entire corpus and does not fundamentally solve the problem of semantic search missing exact terms. Higher dimensions improve expressiveness but don't provide keyword-level precision. This also introduces significant re-indexing cost and operational overhead.
  • E is Incorrect: Reranking improves the ordering of already-retrieved passages but cannot fix recall problems. If the correct passage was never retrieved by the vector search, reranking cannot rescue it. The scenario describes both recall problems (missed terms) and stale document issues—neither is directly fixed by reranking alone.

Key Takeaway: Hybrid search fixes keyword-precision gaps, metadata filters cut stale/out-of-scope documents before ranking, and reranking only reorders what was already retrieved—each lever addresses a different retrieval failure mode.

Question 4 - Endpoint Type Selection for Model Fleet

A retail analytics company has developed 200 small product recommendation models, one for each product category. All models use the same XGBoost framework and are packaged with the same inference code. Traffic analysis shows that 20 "hero" categories receive 80% of total inference requests, while the remaining 180 categories are invoked sporadically—some only a few times per week. The company wants to minimize infrastructure costs while maintaining acceptable latency for all categories.

Which endpoint strategy should the ML engineer recommend? (Select ONE)

  • A) Deploy all 200 models to a single Amazon SageMaker Multi-Model Endpoint, accepting load delays for infrequently used models.
  • B) Deploy the 20 high-traffic models to individual single-model endpoints, and the remaining 180 to a Multi-Model Endpoint.
  • C) Deploy all 200 models to a single Multi-Container Endpoint with one container per model.
  • D) Deploy each model to its own single-model endpoint with Auto Scaling configured per category.
  • E) Use Amazon Bedrock Custom Model Import to serve all 200 models through the Bedrock API.
Click to reveal Answer & Explanation

Correct Answer: B

Correct Answer Analysis

  • B is Correct: This hybrid strategy best balances cost and performance. High-traffic models benefit from dedicated capacity on their own endpoints for consistent low-latency performance. Low-traffic models share a Multi-Model Endpoint (MME), which dynamically loads models from S3 when invoked—the infrequent load penalty is acceptable given their sporadic usage patterns.

Distractor Analysis

  • A is Incorrect: Placing all 200 models on a single MME means the 20 hero models share compute resources with 180 rarely-used models. While MMEs are cost-efficient, high-traffic models can experience contention and performance degradation when sharing a fleet with many other models. Dedicated capacity is warranted for the high-traffic tier.
  • C is Incorrect: Multi-Container Endpoints (MCEs) support up to 15 containers and are designed for inference pipelines (sequential processing) or direct invocation of different container types. They cannot host 200 containers, and requiring one container per model defeats the cost-sharing purpose. MMEs are designed for many-model scenarios within one framework.
  • D is Incorrect: Creating 200 separate endpoints is prohibitively expensive. Each endpoint requires minimum instance capacity, resulting in massive idle infrastructure costs for the 180 low-traffic models. This approach maximizes cost rather than minimizing it.
  • E is Incorrect: Bedrock Custom Model Import is specifically for foundation model architectures (Llama, Mistral, etc.), not traditional ML models like XGBoost. XGBoost models are not supported by the import capability.

Key Takeaway: Multi-Model Endpoints shine for many small, same-framework models with uneven traffic, but high-throughput models deserve dedicated endpoints—the optimal design often splits the fleet by traffic tier.

Question 5 - Asynchronous vs Batch Inference Decision

An insurance company processes medical insurance claims using a deep learning model that extracts diagnoses from scanned documents. The processing pipeline has two distinct workloads:

  1. Overnight batch: Every night at 2 AM, approximately 500,000 scanned PDF documents arrive in bulk from the claims intake system.
  2. Daytime processing: Throughout the day, individual priority claims arrive sporadically (approximately 100 per day), each requiring 8-10 minutes of processing time and returning results to a case management system.

The company wants to use Amazon SageMaker AI for both workloads. Which inference configuration should the ML engineer implement? (Select ONE)

  • A) Use SageMaker Batch Transform for the overnight workload and Asynchronous Inference for the daytime workload.
  • B) Use SageMaker Batch Transform for both workloads, triggering additional batch jobs every hour for daytime claims.
  • C) Use a real-time endpoint for the overnight workload and Serverless Inference for daytime claims.
  • D) Use Asynchronous Inference for both workloads, with a scheduled job that submits the overnight documents as queued requests.
  • E) Use a SageMaker real-time endpoint with Auto Scaling for both workloads, relying on queue depth to trigger scale-out events.
Click to reveal Answer & Explanation

Correct Answer: A

Correct Answer Analysis

  • A is Correct: The two workloads map to fundamentally different inference patterns:
    • Overnight: A pre-assembled dataset arriving in bulk on a schedule = Batch Transform. It provisions compute, processes the static dataset, writes results to S3, and terminates.
    • Daytime: Individual requests arriving dynamically with long processing times = Asynchronous Inference. It queues each request, processes it over minutes, and delivers results to S3 with SNS notifications.

Distractor Analysis

  • B is Incorrect: Using hourly batch transform for daytime claims introduces 60+ minute latency for priority claims (vs. 8-10 minute processing time). Batch jobs are for bulk static datasets, not dynamically arriving individual requests. The hourly trigger also processes the same job repeatedly even when no claims arrive, wasting compute.
  • C is Incorrect: Real-time endpoints cannot process a bulk nightly dataset efficiently (they're designed for request-response, not batch). Serverless Inference is capped at 60-second processing, which is far shorter than the 8-10 minute requirement for daytime claims.
  • D is Incorrect: Asynchronous Inference queues individual requests, not bulk datasets. Submitting 500,000 documents as queued requests would be extremely inefficient compared to Batch Transform's ability to optimize and parallelize dataset processing.
  • E is Incorrect: Real-time endpoints enforce a 60-second timeout, making them unsuitable for 8-10 minute processing tasks. Additionally, real-time endpoints are not designed for batch dataset processing or long-running queued workloads.

Key Takeaway: Batch Transform and Asynchronous Inference are not interchangeable—batch handles pre-assembled datasets on schedules, while asynchronous inference handles individually arriving requests that exceed real-time timeouts.

Question 6 - Serverless vs Real-Time Endpoint Selection

A startup has deployed a document summarization model that is invoked by a web application. Traffic analysis over the past three months shows a distinctive pattern: the application receives 0 requests overnight (10 PM - 6 AM) and on weekends, but during weekday business hours, it receives approximately 50-100 requests per hour. The development team wants to minimize costs, has no strict latency SLA for this internal tool, and wants zero infrastructure management overhead. Each request processes a 2-3 page document and completes within 20 seconds.

Which hosting option BEST fits these requirements? (Select ONE)

  • A) A SageMaker real-time endpoint with Auto Scaling configured to scale to zero instances during idle periods.
  • B) A SageMaker Serverless Inference endpoint with no provisioned concurrency.
  • C) A SageMaker Serverless Inference endpoint with provisioned concurrency to eliminate cold starts.
  • D) An Amazon ECS cluster running the model as a Fargate service with scheduled scaling.
  • E) A SageMaker Asynchronous Inference endpoint with the queue automatically draining during idle periods.
Click to reveal Answer & Explanation

Correct Answer: B

Correct Answer Analysis

  • B is Correct: This traffic pattern has genuine, extended idle periods (overnight and weekends), which is exactly what Serverless Inference was designed for. It scales to zero during idle periods, charges only for processing time and data transfer, and requires zero infrastructure management. The 20-second processing time is within the serverless endpoint's 60-second limit, and cold starts are acceptable given the lack of a strict latency SLA.

Distractor Analysis

  • A is Incorrect: Real-time endpoints with scale-to-zero require inference components and a complex scaling policy that provisions instances when a NoCapacityInvocation metric is emitted. Requests during the provisioning window return errors. This adds complexity and doesn't provide the same seamless zero-to-serving experience as serverless inference.
  • C is Incorrect: Provisioned concurrency on serverless inference keeps capacity warm, which would eliminate cold starts but incur costs during idle periods—defeating the cost optimization goal for a workload without a strict latency SLA. The startup explicitly wants to minimize costs.
  • D is Incorrect: While ECS Fargate can scale to zero with scheduled scaling, it requires significant operational overhead: container image management, task definitions, service discovery, and complex scheduled scaling policies. The requirement specifies zero infrastructure management overhead, which points to serverless hosting.
  • E is Incorrect: Asynchronous Inference is designed for large payloads (>6 MB) or processing times beyond 60 seconds. This workload's 20-second processing time and 2-3 page documents fit well within real-time/serverless limits. Asynchronous inference adds unnecessary queue complexity for a synchronous request pattern.

Key Takeaway: Serverless Inference without provisioned concurrency is the optimal choice for genuinely intermittent traffic with large idle gaps and no strict latency SLA—you pay only for compute time, not for idle capacity.

Question 7 - Foundation Model Throughput Planning

A financial technology startup has built a customer support agent using Amazon Bedrock with the Claude Sonnet model. The agent handles an average of 500 customer conversations per hour during business hours, with peaks reaching 800 conversations per hour. However, the startup is concerned about throttling during peak periods when they compete with other Bedrock customers for on-demand capacity. They need guaranteed throughput during their busiest hours.

Which configuration should the ML engineer recommend? (Select ONE)

  • A) Use on-demand inference with exponential backoff retries to handle throttling events.
  • B) Purchase Provisioned Throughput model units for Claude Sonnet with sufficient capacity for peak demand.
  • C) Deploy the model to a SageMaker real-time endpoint with Auto Scaling for guaranteed capacity.
  • D) Use Bedrock Custom Model Import to create a dedicated instance of Claude Sonnet.
  • E) Split traffic between two AWS regions to double the available on-demand capacity.
Click to reveal Answer & Explanation

Correct Answer: B

Correct Answer Analysis

  • B is Correct: Provisioned Throughput in Amazon Bedrock reserves dedicated model processing capacity, guaranteeing throughput for the model without competing with other customers' on-demand usage. This is the only mechanism in Bedrock for ensuring predictable performance during peak traffic periods. The startup would size the provisioned capacity to handle their 800 conversations/hour peak.

Distractor Analysis

  • A is Incorrect: On-demand inference subjects the startup to potential throttling when Bedrock has high aggregate demand. Retry logic with exponential backoff may help recover from throttling, but it adds latency to customer interactions and does not guarantee throughput during peak periods.
  • C is Incorrect: Claude Sonnet is a proprietary Anthropic model not available for self-hosting on SageMaker endpoints. The startup chose Bedrock for access to the foundation model, and moving to SageMaker would require a fundamentally different (and unavailable) deployment strategy.
  • D is Incorrect: Bedrock Custom Model Import supports importing open-weight models (Llama, Mistral, etc.) that have been customized externally. Claude Sonnet is not an open-weight model and cannot be imported. The Import capability is for bringing your own model weights, not for reserving capacity for existing Bedrock models.
  • E is Incorrect: Provisioned capacity and on-demand quotas are region-specific, and splitting traffic across regions introduces additional latency and data residency complexities. More importantly, this approach still uses on-demand inference, which remains subject to throttling in each region. It does not fundamentally solve the capacity guarantee problem.

Key Takeaway: Provisioned Throughput is the only mechanism in Bedrock for guaranteeing model processing capacity—on-demand is shared capacity with throttling risk, and Custom Model Import is for open-weight architectures only.

Question 8 - Multi-Container Endpoint vs Inference Pipeline

A computer vision company processes video frames through a two-stage pipeline: first, an object detection model (PyTorch, GPU-accelerated) identifies regions of interest, then a classification model (TensorFlow, CPU-optimized) categorizes each detected object. Both models are packaged as separate Docker containers with different runtime requirements. The pipeline must process frames synchronously with results returned in under 2 seconds. Traffic is moderate and continuous.

Which SageMaker configuration should the ML engineer use? (Select ONE)

  • A) A SageMaker Multi-Model Endpoint with both models loaded in the same serving container.
  • B) A SageMaker Multi-Container Endpoint configured as an inference pipeline with the detection container feeding the classification container.
  • C) Two separate single-model endpoints connected by an AWS Lambda function for orchestration.
  • D) A SageMaker Asynchronous Inference endpoint running both models sequentially within a single container.
  • E) Two separate single-model endpoints connected by Amazon SQS queues for decoupling.
Click to reveal Answer & Explanation

Correct Answer: B

Correct Answer Analysis

  • B is Correct: Multi-Container Endpoints (MCEs) specifically support inference pipelines where multiple containers with different frameworks or runtime requirements process requests sequentially. The detection container (PyTorch/GPU) passes results directly to the classification container (TensorFlow/CPU) within the same endpoint, minimizing latency and keeping the synchronous flow intact.

Distractor Analysis

  • A is Incorrect: Multi-Model Endpoints (MMEs) host multiple models but require them to share the same serving container and framework. The scenario explicitly states different frameworks (PyTorch vs. TensorFlow) and different runtime requirements (GPU vs. CPU), which makes MMEs unsuitable.
  • C is Incorrect: While this architecture could work, adding a Lambda function between endpoints introduces unnecessary latency (two network hops plus Lambda invocation overhead) for a synchronous 2-second pipeline. It also increases operational complexity with three components to manage instead of one MCE.
  • D is Incorrect: Asynchronous inference is unnecessary for a 2-second synchronous requirement and adds queue latency. Additionally, running both models (PyTorch and TensorFlow, GPU and CPU) in a single container would create conflicting runtime dependencies.
  • E is Incorrect: Decoupling with SQS queues converts a synchronous request into an asynchronous pattern, which violates the under-2-second requirement. The caller expects immediate results, not a queued acknowledgment. This approach also adds significant architectural complexity for no benefit in a moderate, continuous traffic scenario.

Key Takeaway: Multi-Container Endpoints are ideal when models require different runtime environments or frameworks within a synchronous processing pipeline; Multi-Model Endpoints are for same-framework model fleets.

Question 9 - Deployment of Custom Models from External Environments

A research institution has trained a custom natural language processing model using PyTorch on their on-premises infrastructure. The model performs specialized scientific text classification. The institution wants to deploy this model on AWS for real-time inference via API calls, but their IT policy mandates that the model must run on infrastructure they control, with the ability to customize the serving stack (including custom preprocessing and postprocessing logic in the inference container). They require millisecond-level latency for individual predictions.

Which deployment strategy should the ML engineer recommend? (Select ONE)

  • A) Import the model to Amazon Bedrock via Custom Model Import for serverless inference.
  • B) Deploy the model to an Amazon SageMaker real-time endpoint with a custom inference container.
  • C) Upload the model to Amazon SageMaker JumpStart and deploy the recommended preconfigured endpoint.
  • D) Store the model in Amazon S3 and invoke it via AWS Lambda with the PyTorch runtime layer.
  • E) Use Amazon Bedrock Knowledge Bases to embed the model and serve it through the RetrieveAndGenerate API.
Click to reveal Answer & Explanation

Correct Answer: B

Correct Answer Analysis

  • B is Correct: SageMaker real-time endpoints with custom inference containers provide the infrastructure control and customization the institution requires. They can package the PyTorch model with custom preprocessing/postprocessing logic in a Docker container, serve it on GPU instances for millisecond latency, and expose it as a REST API. This approach gives them full control over the serving stack while leveraging SageMaker's managed hosting.

Distractor Analysis

  • A is Incorrect: Bedrock Custom Model Import supports specific open-weight foundation model architectures (Llama, Mistral, etc.), not custom academic PyTorch models. It also doesn't provide the serving stack customization the institution needs—the import path restricts the container configuration.
  • C is Incorrect: SageMaker JumpStart provides pre-built solutions for popular models, but a custom academic model won't be in the JumpStart catalog. JumpStart can't package a bespoke on-premises model without significant reconfiguration, and it wouldn't support the institution's custom inference logic.
  • D is Incorrect: AWS Lambda has a 10 GB memory limit, 6 vCPU limit, no GPU support, 15-minute timeout, and 250 MB deployment package (or 10 GB with container images). A PyTorch model requiring GPU acceleration for millisecond latency is incompatible with Lambda's compute constraints.
  • E is Incorrect: Bedrock Knowledge Bases manages document retrieval for RAG applications—it is not a general-purpose model hosting service. It cannot serve a custom PyTorch classification model. This option confuses retrieval infrastructure with model serving.

Key Takeaway: Custom inference containers on SageMaker real-time endpoints are the answer when you need infrastructure control + custom serving logic + millisecond latency; Bedrock import is for supported foundation model architectures only.

Question 10 - Agent Deployment and Tool Integration

A logistics company is building an AI agent using Amazon Bedrock AgentCore that can answer questions about shipment status and reschedule deliveries. The agent needs to:

  1. Call an existing REST API that provides real-time shipment tracking data
  2. Access a PostgreSQL database containing customer delivery preferences
  3. Use a SageMaker inference endpoint running a custom ETA prediction model

The company wants to expose these tools to the agent using open standards where possible, minimizing custom integration code.

Which architecture should the ML engineer implement? (Select ONE)

  • A) Deploy a Lambda function that wraps all three tools into a single API, and register the Lambda as the agent's only tool.
  • B) Use the Bedrock AgentCore Gateway to expose the REST API and database as tools via the Model Context Protocol (MCP), and register the SageMaker endpoint as a direct tool.
  • C) Embed the tool-calling logic directly in the agent's prompt, instructing the foundation model to generate SQL queries and API calls directly.
  • D) Create three separate Bedrock Knowledge Bases for each tool, and configure the agent to query them through RetrieveAndGenerate.
  • E) Move all three tools to AWS Lambda functions and invoke them using Step Functions orchestrated by the agent.
Click to reveal Answer & Explanation

Correct Answer: B

Correct Answer Analysis

  • B is Correct: Bedrock AgentCore Gateway is specifically designed to expose existing APIs and functions as tools via open protocols like Model Context Protocol (MCP). This minimizes custom integration code by presenting the REST API and PostgreSQL database as MCP tools. The SageMaker endpoint can be registered as a direct inference tool within the agent's tool configuration. This approach leverages AgentCore's native capabilities for tool integration.

Distractor Analysis

  • A is Incorrect: Wrapping all three tools in a single Lambda creates a monolithic integration point that requires custom code to route between tools, handle authentication to all three backends, and manage error scenarios. This defeats the purpose of AgentCore's gateway capabilities and increases operational complexity.
  • C is Incorrect: Instructing the foundation model to generate raw API calls and SQL queries is unsafe (SQL injection risks, no authentication control, potential data exfiltration) and violates the company's implicit security requirements. Agent tool-calling provides proper auth scoping and execution controls that raw prompt generation cannot.
  • D is Incorrect: Bedrock Knowledge Bases are for document retrieval—they cannot serve as an abstraction for real-time API calls, database queries, or SageMaker model invocation. Knowledge Bases index static documents, not live data sources.
  • E is Incorrect: While Step Functions can orchestrate Lambda-based tools, this approach requires wrapping each tool in Lambda and building the entire orchestration layer. It introduces more custom code and infrastructure than AgentCore Gateway's out-of-the-box MCP support.

Key Takeaway: Bedrock AgentCore Gateway with MCP is the modern approach for exposing existing APIs and functions as agent tools—it provides standardized tool discovery, authentication, and execution without heavy custom integration code.