Skip to content

Skill 3.1.3: Select model inference strategies (for example, real-time and batch processing)

Question 1 - Real-Time vs. Serverless Inference for Fraud Detection

A fintech company is deploying a credit card fraud detection model that scores each transaction during checkout. The model must return a risk score within 150 milliseconds while the customer is waiting at the payment gateway. Traffic is continuous throughout the day with predictable peaks during lunch hours and evenings, and the operations team wants to minimize infrastructure management overhead while ensuring consistent low latency.

Which inference option BEST satisfies these requirements? (Select ONE)

  • A) Amazon SageMaker Serverless Inference endpoint with provisioned concurrency
  • B) Amazon SageMaker Real-Time Inference endpoint with Application Auto Scaling on invocation metrics
  • C) Amazon SageMaker Asynchronous Inference endpoint with scale-to-zero enabled
  • D) AWS Lambda function with the model loaded from Amazon S3 into the Lambda layer
  • E) Amazon SageMaker Batch Transform job scheduled every 5 minutes
Click to reveal Answer & Explanation

Correct Answer: B

Correct Answer Analysis

Option B is correct. The scenario requires synchronous, low-latency responses (150 ms) for a continuously flowing stream of transactions where the end user is actively waiting. Amazon SageMaker Real-Time Inference provides persistent warm compute instances capable of meeting strict millisecond latency budgets. Application Auto Scaling on invocation metrics (e.g., SageMakerVariantInvocationsPerInstance) automatically provisions additional instances during predictable peaks and scales down during valleys, maintaining cost efficiency without sacrificing latency.

Distractor Analysis

  • Option A is incorrect: While Serverless Inference with provisioned concurrency can reduce cold starts, it still introduces variable latency compared to a dedicated real-time endpoint with always-warm instances. Additionally, provisioned concurrency adds cost and complexity without the deterministic latency guarantees required for 150 ms payment scoring.
  • Option C is incorrect: Asynchronous Inference is designed for non-blocking workloads with processing times of minutes or large payloads. It queues requests and returns an acknowledgment immediately, which violates the requirement that the customer receives a synchronous risk score during checkout.
  • Option D is incorrect: AWS Lambda has a maximum execution time of 15 minutes and limited storage in layers (250 MB unzipped), making it unsuitable for hosting most ML models with large model artifacts. Lambda cold starts would also likely exceed the 150 ms latency budget.
  • Option E is incorrect: Batch Transform is designed for processing pre-assembled, static datasets offline. It cannot provide real-time, synchronous predictions for individual transactions arriving dynamically throughout the day.

Key Takeaway: Continuous synchronous traffic with strict latency SLAs always points to Real-Time Inference endpoints with Auto Scaling, while Serverless Inference is reserved for intermittent traffic with genuine idle gaps where cold starts are tolerable.

Question 2 - Batch Transform Selection for Overnight Document Processing

An insurance company processes approximately 2 million scanned claim documents nightly through a custom OCR and document classification model. The documents arrive as a bulk upload to Amazon S3 at midnight, and results must be written back to S3 by 6 AM. The data science team wants to minimize operational overhead and ensure compute resources are only provisioned during the processing window.

Which inference strategy meets these requirements? (Select ONE)

  • A) Amazon SageMaker Asynchronous Inference endpoint with a queue consuming S3 events
  • B) Amazon SageMaker Batch Transform job launched by an Amazon EventBridge scheduled rule
  • C) Amazon SageMaker Real-Time Inference endpoint with aggressive nocturnal auto scaling policies
  • D) Amazon ECS cluster with Fargate tasks running the model continuously, polling S3 for new data
  • E) Amazon SageMaker Serverless Inference endpoint with provisioned concurrency at midnight
Click to reveal Answer & Explanation

Correct Answer: B

Correct Answer Analysis

Option B is correct. The workload is a pre-assembled, bulk dataset that arrives on a fixed schedule (midnight). Amazon SageMaker Batch Transform is purpose-built for exactly this pattern: it provisions a temporary compute cluster, processes large batches of file-based data (up to hundreds of millions of records) from Amazon S3, writes predictions back to S3, and automatically shuts down. It charges only for the duration of the job. Amazon EventBridge can trigger the Batch Transform job on a nightly cron schedule, fully automating the workflow.

Distractor Analysis

  • Option A is incorrect: Asynchronous Inference is designed for individual, dynamically arriving requests (up to 1 GB per request) that are queued and processed with unbounded latency. A bulk nightly upload of 2 million files is better suited to batch processing, which handles large static datasets more efficiently.
  • Option C is incorrect: Real-Time Inference endpoints are designed for synchronous, low-latency predictions on individual requests as they arrive. Keeping real-time infrastructure running overnight for a batch job would be excessively expensive and unnecessarily complex.
  • Option D is incorrect: Running a continuously available ECS cluster that polls S3 manually reintroduces operational overhead (container orchestration, scaling policies, task scheduling, and resource management). It also incurs 24/7 compute costs, violating the constraint of provisioning resources only during the processing window.
  • Option E is incorrect: Serverless Inference is a synchronous endpoint designed for intermittent real-time requests. It has a 60-second timeout and limited payload sizes, making it unsuitable for processing millions of documents in bulk.

Key Takeaway: Batch Transform is the correct choice when no caller is waiting, data arrives in bulk on a schedule, and compute should run only for the duration of the job.

Question 3 - Asynchronous Inference for Large Payload Processing

A healthcare analytics platform processes individual pathology reports (5–15 MB PDF files) through a custom medical NLP model. Each report takes approximately 4–8 minutes to process. Reports arrive unpredictably throughout the day as pathologists upload them. The system must not block users, must support payloads larger than 6 MB, and should scale down to zero when no requests are queued to minimize costs.

Which inference option satisfies all these requirements? (Select ONE)

  • A) Amazon SageMaker Real-Time Inference endpoint with large instance types
  • B) Amazon SageMaker Serverless Inference endpoint with maximum concurrency
  • C) Amazon SageMaker Asynchronous Inference endpoint with scale-to-zero configuration
  • D) Amazon SageMaker Batch Transform job scheduled hourly
  • E) AWS Lambda function with EFS storage for large model artifacts
Click to reveal Answer & Explanation

Correct Answer: C

Correct Answer Analysis

Option C is correct. Amazon SageMaker Asynchronous Inference is specifically designed for this workload pattern. Key requirements violations solved by this option: 1. Large payloads: Asynchronous endpoints support payload sizes up to 1 GB, while real-time/serverless only support up to 6 MB. 2. Long processing times: Asynchronous endpoints support processing durations up to 15 minutes (extendable to 1 hour), while synchronous endpoints enforce a 60-second timeout. 3. Non-blocking: Requests are placed in an internal queue and the API returns an immediate acknowledgment (202 Accepted), so pathologists are not blocked waiting for results. 4. Scale-to-zero: Asynchronous endpoints can be configured to scale the instance count to zero when the queue is empty, minimizing cost during idle periods.

Distractor Analysis

  • Option A is incorrect: Real-Time endpoints have a 60-second timeout, which would fail for processing times of 4–8 minutes. They also have a 6 MB payload limit, insufficient for 5–15 MB PDF files.
  • Option B is incorrect: Serverless Inference also has a 60-second timeout and 6 MB payload limit. It is designed for synchronous responses, not queued asynchronous processing.
  • Option D is incorrect: Batch Transform processes pre-assembled, static datasets in bulk. It cannot accept dynamically arriving individual report submissions throughout the day. Reports would accumulate in S3 until the scheduled batch run, causing unacceptable delays for clinicians.
  • Option E is incorrect: Lambda has a 15-minute maximum timeout but a 6 MB sync invocation payload and 256 KB async payload limit for incoming requests. The 5–15 MB PDF files would exceed Lambda's payload capacity, and model loading from EFS adds cold-start latency.

Key Takeaway: Asynchronous Inference bridges the gap between synchronous real-time and scheduled batch processing, supporting large payloads (up to 1 GB), long processing times (up to 15–60 minutes), queued requests, and scale-to-zero for infrequent workloads.

Question 4 - Multi-Model Endpoint for Cost-Efficient Model Management

A financial services company hosts 150 fraud detection models—one for each geographic region—all using TensorFlow with identical preprocessing steps. Traffic is highly uneven: approximately 15% of the models handle 85% of the inference traffic, while the remaining 85% are called infrequently. The MLOps team wants to minimize hosting costs while serving all models in real-time.

Which SageMaker deployment strategy best meets these requirements? (Select ONE)

  • A) Deploy each model to a separate single-model real-time endpoint with Auto Scaling
  • B) Deploy all models to a single multi-model endpoint using a shared TensorFlow serving container
  • C) Deploy all models to a multi-container endpoint with one container per model
  • D) Deploy frequently used models to single endpoints and rarely used models to Batch Transform
  • E) Deploy all models to Amazon SageMaker Serverless Inference using a multi-model serverless configuration
Click to reveal Answer & Explanation

Correct Answer: B

Correct Answer Analysis

Option B is correct. Amazon SageMaker Multi-Model Endpoints (MMEs) are specifically designed for hosting multiple models that share the same inference container (in this case, TensorFlow Serving). The core benefit is cost efficiency through fleet sharing: compute resources are shared across all 150 models rather than paying for 150 separate idle endpoints. SageMaker dynamically loads frequently used models into memory for fast responses and unloads idle models, loading them on demand with a <1 second penalty from S3. Since all models use the same framework and preprocessing, they are ideal candidates for a shared container.

Distractor Analysis

  • Option A is incorrect: Hosting each model on its own real-time endpoint creates 150 separate compute fleets, each with its own minimum instance count and Auto Scaling policies. This incurs massive idle infrastructure costs for the 85% of rarely called models.
  • Option C is incorrect: Multi-container endpoints are designed for scenarios where containers have different framework dependencies or serving stacks (e.g., PyTorch and XGBoost), or for inference pipelines where one container's output feeds another. Hosting 150 identical TensorFlow containers defeats the purpose and does not scale to 150 containers (limited to 15).
  • Option D is incorrect: Rarely used models still need to serve real-time predictions when called. Batch Transform cannot deliver synchronous responses and would add unacceptable latency for fraud detection, which requires immediate scoring.
  • Option E is incorrect: Serverless Inference does not support multi-model or multi-container hosting. Each model would require its own serverless endpoint configuration, reverting to the high-overhead scenario of Option A (with added complexity in managing 150 serverless configurations).

Key Takeaway: Multi-Model Endpoints are the most cost-effective option for hosting many small models that share an inference framework, trading occasional cold-start load latency for rarely used models against significant cost savings.

Question 5 - Amazon Bedrock Provisioned Throughput vs. On-Demand for Foundation Models

An enterprise is building a generative AI application using Amazon Bedrock with the Anthropic Claude 3 Sonnet model. The application serves 50,000 internal customer support agents during business hours. The application requires guaranteed low-latency responses (under 2 seconds) during peak load, and the business has committed to a fixed monthly budget. Usage patterns show consistent high volume from 8 AM to 8 PM on weekdays with minimal weekend traffic.

Which capacity configuration should the MLOps engineer select? (Select ONE)

  • A) On-Demand capacity with AWS Auto Scaling through Application Auto Scaling
  • B) Provisioned Throughput with a one-month commitment for the base model
  • C) Multiple On-Demand API keys distributed across AWS accounts
  • D) Amazon SageMaker Real-Time endpoint hosting the Claude model via a SageMaker JumpStart deployment
  • E) Custom Model Import with On-Demand invocation
Click to reveal Answer & Explanation

Correct Answer: B

Correct Answer Analysis

Option B is correct. Amazon Bedrock Provisioned Throughput (PT) provides dedicated, reserved model processing capacity for a specified base or custom model. It guarantees: 1. Consistent throughput: A predetermined number of model units (MUs) that can process a set input/output token rate. 2. Low latency: No cold starts or contention with other customers sharing the same on-demand capacity pool. 3. Predictable billing: Fixed hourly billing for the commitment term (1 or 6 months), enabling the business to budget precisely. For a workload with predictable high-volume business hours and strict latency requirements, Provisioned Throughput is the correct choice over the shared, best-effort nature of On-Demand capacity.

Distractor Analysis

  • Option A is incorrect: On-Demand capacity is a shared pool of resources with no guaranteed throughput or latency. During peak traffic, the application can experience throttling or elevated latency due to contention with other AWS customers. It also offers no cost predictability for a committed budget.
  • Option C is incorrect: Distributing API keys across accounts does not increase throughput; it only spreads the load across separate API calls that still contend for the same shared On-Demand capacity pool. This introduces unnecessary complexity without addressing the core throughput limitation.
  • Option D is incorrect: Deploying Claude via SageMaker JumpStart requires managing a SageMaker endpoint (instance sizing, scaling policies, infrastructure overhead). The scenario specifies using Amazon Bedrock, which removes endpoint management entirely.
  • Option E is incorrect: Custom Model Import is for importing models fine-tuned or customized externally. The scenario uses the base Claude 3 Sonnet model, and On-Demand invocation does not provide the consistent low-latency guarantees required.

Key Takeaway: Provisioned Throughput in Amazon Bedrock is the correct choice when guaranteed latency and predictable throughput are required; On-Demand capacity is suitable for bursty workloads without strict latency SLAs.

Question 6 - Amazon Bedrock Custom Model Import for External Fine-Tuning

A research team fine-tuned an open-weight Llama 3.1 8B model on proprietary biomedical literature in their on-premises GPU cluster. The team now wants to serve the fine-tuned model through a serverless API without managing any infrastructure or endpoints. The foundation model API must support both InvokeModel and Converse API operations. The team plans to invoke the model on demand with intermittent traffic.

Which deployment path meets these requirements? (Select ONE)

  • A) Package the model in a Docker container and deploy it to Amazon SageMaker Real-Time Inference
  • B) Import the fine-tuned model from Amazon S3 into Amazon Bedrock using Custom Model Import
  • C) Deploy the model to Amazon SageMaker Serverless Inference with a custom inference script
  • D) Fine-tune the Llama model directly in Amazon Bedrock using the base Llama model
  • E) Deploy the model to Amazon SageMaker Multi-Model Endpoint with the Llama container
Click to reveal Answer & Explanation

Correct Answer: B

Correct Answer Analysis

Option B is correct. Amazon Bedrock Custom Model Import is purpose-built for this scenario. The team fine-tuned an open-weight model (Llama 3.1) in their own environment and now needs to serve it through the managed Bedrock API. The process involves: 1. Uploading the fine-tuned model artifacts to Amazon S3 in a Bedrock-supported format (e.g., Hugging Face safetensors). 2. Initiating the import, which validates the architecture and creates a model resource in Bedrock. 3. Invoking the imported model via the standard InvokeModel or Converse API on demand, with no endpoint or infrastructure to manage. This provides a fully serverless inference path for custom open-weight models, with pay-per-token billing for on-demand invocation.

Distractor Analysis

  • Option A is incorrect: Deploying to SageMaker Real-Time Inference requires managing an endpoint (instance selection, scaling policies, manual deployment). The scenario explicitly requires a serverless API without endpoint management.
  • Option C is incorrect: SageMaker Serverless Inference is serverless but still requires configuration of a SageMaker endpoint, including infrastructure sizing (max concurrency), and does not expose the Bedrock InvokeModel/Converse API surface. It incurs endpoint provisioning time and does not use token-based billing.
  • Option D is incorrect: The team already fine-tuned the model externally. Re-fine-tuning inside Bedrock would require transferring training data to AWS and repeating the fine-tuning process, wasting time and compute resources. It also does not leverage the team's existing fine-tuned weights.
  • Option E is incorrect: Multi-Model Endpoints still require managing a SageMaker endpoint with EC2 instances. It also does not expose the Bedrock API surface and does not meet the serverless requirement.

Key Takeaway: Amazon Bedrock Custom Model Import enables externally fine-tuned open-weight models to be served through the serverless Bedrock API, while SageMaker endpoints (including serverless) require endpoint configuration and deployment management.

Question 7 - Retrieval Configuration for RAG System Optimization

A legal services firm operates a RAG (Retrieval Augmented Generation) application built on Amazon Bedrock Knowledge Bases with Amazon OpenSearch Serverless. Users complain that when searching for exact legal case citations (e.g., "Brown v. Board of Education, 347 U.S. 483"), the retrieved passages are sometimes off-topic and miss exact keyword matches. The vector search returns 20 passages, but the exact-match documents appear at positions 10–15 in the results. The system must improve precision while minimizing additional operational complexity.

Which TWO configuration changes should the MLOps engineer implement? (Select TWO)

  • A) Enable hybrid search on the OpenSearch Serverless vector collection to combine vector similarity with BM25 keyword matching
  • B) Add a reranking model (e.g., Amazon Rerank or Cohere Rerank) to reorder retrieved passages by cross-encoder relevance scores
  • C) Increase the number of returned passages to 100 to ensure the exact match is included
  • D) Re-embed all documents with a higher-dimensional embedding model (e.g., 1024 dimensions instead of 384)
  • E) Configure a metadata filter to restrict retrieval to only case law documents with known citations
Click to reveal Answer & Explanation

Correct Answer: A and B

Correct Answer Analysis

  • Option A is correct: Hybrid search combines vector similarity (semantic understanding) with BM25 keyword matching (exact term matching) in a single query. For queries involving exact legal citations—where precise string matching matters—BM25 recovers the precise terms that vector embeddings may blur (because embeddings capture semantics, not exact token matching). OpenSearch Serverless supports hybrid search natively, making this a low-operational-overhead change.
  • Option B is correct: Reranking is a second-pass relevance reordering of the candidate passages already retrieved by vector search. A cross-encoder reranker evaluates each passage alongside the query, producing a deep semantic relevance score that reorders the correct passage (currently ranked 10–15) to the top. This directly fixes the "right passage, wrong position" problem without requiring re-indexing.

Distractor Analysis

  • Option C is incorrect: Increasing the number of returned passages to 100 does not fix the ordering problem. While it would include the exact match in the retrieved set, the LLM would still receive the exact match at positions 10–15 relative to weaker passages, potentially overwhelming the context window and increasing costs (more tokens sent to the LLM). It introduces more unrelated text into the prompt.
  • Option D is incorrect: Re-embedding with higher-dimensional embeddings only marginally increases representational capacity and does not address the fundamental issue that bi-encoder models struggle with exact string matching. It also requires a full re-indexing of the knowledge base, which is a high-overhead operational change.
  • Option E is incorrect: The problem is ordering and exact-match recall, not filtering out stale or out-of-scope documents. Metadata filters reduce the candidate set before retrieval; they cannot retrieve a document that the search never finds. If the exact-match document exists in the vector database but ranks low, this option would not fix the ranking issue.

Key Takeaway: Hybrid search fixes exact-term matching issues (recall) while reranking fixes ordering issues (precision), and these two levers are independent tools for different retrieval complaints.

Question 8 - Serverless Inference with VPC Constraints

A pharmaceutical company runs a machine learning inference workload that must integrate with a MySQL database inside a private VPC subnet. The model is called asynchronously and handles moderate traffic with intermittent idle periods. The security team requires that the inference endpoint reside within the VPC to comply with data residency and isolation requirements.

Which inference option satisfies the VPC requirement AND the intermittent traffic pattern? (Select ONE)

  • A) Amazon SageMaker Serverless Inference endpoint with VPC configuration enabled
  • B) Amazon SageMaker Real-Time Inference endpoint with VPC configuration and Auto Scaling
  • C) Amazon SageMaker Asynchronous Inference endpoint with VPC configuration
  • D) AWS Lambda function deployed inside the VPC calling the model via a SageMaker endpoint
  • E) Amazon SageMaker Batch Transform job with VPC configuration
Click to reveal Answer & Explanation

Correct Answer: B

Correct Answer Analysis

Option B is correct. The scenario has an explicit VPC requirement. Amazon SageMaker Serverless Inference does not support VPC configuration (no VPC connectivity, no accelerated instances, no multi-model hosting). Real-Time Inference endpoints provide full VPC integration through Elastic Network Interfaces (ENIs) attached to the SageMaker-managed instances. For intermittent traffic with VPC requirements, a real-time endpoint with Auto Scaling (including scale-in to zero if properly configured) is the correct choice. The endpoint can scale in during idle periods using Application Auto Scaling policies on invocation metrics.

Distractor Analysis

  • Option A is incorrect: Serverless Inference is explicitly ruled out by the VPC requirement. Serverless endpoints do not support VPC configuration, so they cannot access resources inside a private subnet (like the MySQL database). This is a critical limitation to recognize when evaluating serverless options.
  • Option C is incorrect: Asynchronous Inference with VPC is possible, but the model is called in a way that requires database access during inference. While asynchronous endpoints support VPC configurations, the workload is "called asynchronously" in the API sense, but the question statement suggests the model is not blocking users—making it ambiguous. The strongest signal is the VPC requirement, which Serverless fails but Real-Time satisfies.
  • Option D is incorrect: Lambda inside VPC invoking an endpoint adds unnecessary architectural complexity. The Lambda function itself would need VPC connectivity to reach the endpoint, and the endpoint still needs VPC configuration. This is a two-hop solution that introduces additional latency and cost.
  • Option E is incorrect: Batch Transform does not support continuous, dynamically arriving requests. It processes pre-assembled datasets on a schedule and cannot handle intermittent traffic arriving at unpredictable times. It also does not maintain persistent database connections for individual requests.

Key Takeaway: Serverless Inference lacks VPC configuration support, so any requirement for private network access immediately rules it out in favor of Real-Time or Asynchronous endpoints with VPC integration.

Question 9 - Multi-Container Endpoint for Inference Pipeline

An e-commerce company deploys a product recommendation system that runs a two-stage inference pipeline: (1) a candidate generation model using PyTorch that outputs the top 50 recommendation candidates, followed by (2) a ranking model using XGBoost that reorders the 50 candidates into a personalized top-10 list. Both models must execute sequentially per request, with the PyTorch model's output passed directly as input to the XGBoost model. Latency budget for the entire pipeline is under 300 ms.

Which deployment strategy best meets these requirements? (Select ONE)

  • A) Two real-time endpoints, one for each model, orchestrated by an AWS Lambda function
  • B) A multi-container endpoint configured as an inference pipeline with both models in sequence
  • C) A multi-model endpoint hosting both models behind a shared PyTorch container
  • D) An asynchronous inference endpoint with a custom orchestration script
  • E) A single-container endpoint with both models packaged in one Docker image
Click to reveal Answer & Explanation

Correct Answer: B

Correct Answer Analysis

Option B is correct. Amazon SageMaker Multi-Container Endpoints support two deployment patterns: (1) parallel "direct invocation" where containers are called independently, and (2) inference pipelines where containers run sequentially, with each container's output fed as input to the next. In this scenario, the PyTorch container (candidate generation) outputs the top-50 list, which is then automatically passed to the XGBoost container (ranking model) for reordering. This serial pipeline is exactly what a multi-container inference pipeline provides—zero external orchestration, per-request sequential execution, and minimal latency (both containers run on the same instance, eliminating network hops).

Distractor Analysis

  • Option A is incorrect: Two separate endpoints introduce a network hop between services (endpoint-to-endpoint via a Lambda function). This adds Lambda invocation latency, network transfer time, and operational complexity (managing two endpoints with Auto Scaling). It also requires custom orchestration code in Lambda, increasing failure modes.
  • Option C is incorrect: Multi-model endpoints require all models to share the same serving container (framework). The scenario includes PyTorch and XGBoost—two different frameworks that cannot share the same container. Additionally, multi-model endpoints do not provide sequential inference pipeline capabilities; they serve models independently.
  • Option D is incorrect: Asynchronous inference is designed for non-blocking, long-running workloads. The 300 ms latency budget requires synchronous processing. Asynchronous endpoints also require custom orchestration to coordinate the two models, adding complexity.
  • Option E is incorrect: While technically feasible to package both models in one Docker container, this approach increases the build complexity, reduces modularity, and makes it harder to update or swap individual models. It violates the AWS best practice of using the built-in inference pipeline pattern for sequential model execution.

Key Takeaway: Multi-container endpoints with inference pipeline configuration provide low-latency, sequential execution with zero external orchestration when models run in a fixed order with output-to-input dependencies.

Question 10 - Foundation Model Deployment in VPC via Amazon Bedrock

A government agency requires that all generative AI model inferencing infrastructure remain within their controlled AWS VPC. They want to use the Amazon Bedrock API to invoke foundation models without exposing any traffic outside their private network. The agency also requires that all data processed remain within the VPC and that no public internet access is used.

Which deployment option satisfies these requirements? (Select ONE)

  • A) Amazon Bedrock with VPC endpoints (AWS PrivateLink) and a VPC endpoint policy restricting access to the Bedrock API
  • B) Amazon Bedrock Custom Model Import with the imported model deployed to a SageMaker VPC endpoint
  • C) Amazon Bedrock with a NAT Gateway and private subnet routing
  • D) Amazon SageMaker Real-Time Inference endpoint with the foundation model deployed from JumpStart
  • E) Amazon Bedrock AgentCore with VPC configuration enabled
Click to reveal Answer & Explanation

Correct Answer: A

Correct Answer Analysis

Option A is correct. Amazon Bedrock supports VPC endpoint (AWS PrivateLink) access through interface endpoints. This architecture ensures: 1. Private connectivity: All traffic between the VPC and Amazon Bedrock travels entirely within the AWS network using a private IP address, without traversing the public internet. 2. VPC endpoint policies: Attaching an IAM resource policy to the VPC endpoint allows the agency to restrict which principals can invoke Bedrock through that endpoint, enforcing least-privilege access. 3. Compliance with data residency: All inference bytes (prompts and responses) are processed within the Bedrock service, and the VPC endpoint ensures no public internet exposure for the API calls. This is the standard AWS pattern for accessing Bedrock from a controlled VPC environment.

Distractor Analysis

  • Option B is incorrect: Custom Model Import imports a model into Bedrock (still invoked via the Bedrock API, not via a SageMaker endpoint). The statement about deploying to a SageMaker VPC endpoint conflates two different services and architectures. Imported models in Bedrock are still accessed via the Bedrock API, which requires VPC endpoints for private access.
  • Option C is incorrect: A NAT Gateway allows instances inside a private subnet to access the public internet (e.g., to call the Bedrock public API endpoint). This exposes traffic to the public internet, violating the requirement that no public internet access is used and that all traffic remains within the VPC.
  • Option D is incorrect: Deploying a foundation model via SageMaker JumpStart creates a SageMaker endpoint, not a Bedrock API endpoint. While SageMaker endpoints can be VPC-enabled, the agency explicitly requested Bedrock API access. Additionally, SageMaker JumpStart does not provide the same serverless Bedrock API surface or token-based billing.
  • Option E is incorrect: Amazon Bedrock AgentCore (the agent runtime) does not have a separate VPC configuration distinct from the Bedrock API. While agents can be invoked via the Bedrock API through VPC endpoints, the specific claim about "VPC configuration enabled" in AgentCore is a non-existent feature—Bedrock uses the VPC endpoint of the Bedrock service itself.

Key Takeaway: When a VPC-isolated foundation model API is required, always use AWS PrivateLink VPC endpoints for Amazon Bedrock with a VPC endpoint policy, rather than creating separate endpoint infrastructure or routing through the public internet.