Skip to content

Skill 1.1.1: Extract data from data sources

Question 1 - Vector Store Selection for Hybrid Search Requirements

A financial services company is building a generative AI application that must retrieve product documentation using Amazon Bedrock Knowledge Bases. The application must support exact part number lookups (e.g., "EQ-4471-B") alongside semantically similar text queries. Additionally, the knowledge base must enforce document access based on department-level metadata filters before similarity ranking occurs. The team needs to minimize operational overhead while supporting both exact and semantic search in a single query execution.

Which configuration satisfies these requirements? (Select ONE)

  • A) Configure an Amazon OpenSearch Serverless vector collection with hybrid search enabled, ensuring the text field is filterable and dimension count matches the embedding model.
  • B) Configure an Amazon S3 bucket as the vector store, enabling cost-effective storage for the department metadata filters required for pre-filtering.
  • C) Configure an Amazon Aurora PostgreSQL vector store with pgvector indexing and create a relational join between department tables and document chunks.
  • D) Configure an Amazon Neptune graph store to map relationships between part numbers, departments, and document chunks for graph-based retrieval.
  • E) Configure two separate Bedrock Knowledge Bases—one for semantic search and one for exact match—routing queries through a custom Lambda dispatcher.
Click to reveal Answer & Explanation

Correct Answer: A

Correct Option Analysis

  • A is Correct: Amazon OpenSearch Serverless with hybrid search enabled natively supports both dense vector search (k-NN for semantic similarity) and sparse lexical search (BM25 for exact keyword/part number matching) in a single query. The filterable text field enables metadata-based pre-filtering on department attributes before similarity ranking. Bedrock Knowledge Bases integrates directly with OpenSearch Serverless, minimizing operational overhead.

Distractor Analysis

  • B is Incorrect: Amazon S3 as a vector store (via Amazon S3 vector buckets) is a low-cost option for large vector sets queried infrequently, but it does not support hybrid search or real-time metadata filtering with similarity ranking in a single query.
  • C is Incorrect: While Aurora PostgreSQL with pgvector supports vector search alongside relational joins, it requires significantly more operational overhead (schema design, connection management, indexing strategy) than a managed search service and does not natively support hybrid lexical-semantic search within Bedrock Knowledge Bases.
  • D is Incorrect: Amazon Neptune is a graph database suited for relationship-based retrieval patterns (e.g., entity traversal), not for efficient hybrid search over high-dimensional dense embeddings and text fields.
  • E is Incorrect: Splitting semantic and exact search across two separate knowledge bases introduces unnecessary architectural complexity (dual ingestion pipelines, custom routing logic) and fails to satisfy the "single query execution" requirement.

Key Takeaway: Hybrid search requires a search-service vector store (OpenSearch) with a filterable text field; object storage, relational, and graph stores do not support this capability natively within Bedrock Knowledge Bases.

Question 2 - Embedding Dimension Mismatch During Knowledge Base Creation

An AI engineering team is migrating existing vector data into a new Amazon Bedrock Knowledge Base. The team previously generated embeddings using a custom model producing 768-dimension vectors, but the new knowledge base will use Amazon Titan Embeddings G1 - Text, which produces 1536-dimension vectors. The team attempts to configure an Amazon OpenSearch Serverless collection and encounters a validation error during ingestion.

What is the root cause of this failure and what must the team do? (Select ONE)

  • A) The vector index field mapping must be reconfigured from 768 to 1536 dimensions before the ingestion job runs; this requires recreating the collection with the correct mapping.
  • B) The embedding model selection is incompatible with OpenSearch Serverless; the team must switch to Amazon Kendra for vector storage.
  • C) The OpenSearch Serverless collection requires a minimum of 2048 dimensions, so the team must upgrade to a different embedding model.
  • D) The knowledge base must be configured with a custom embedding model that matches the 768-dimension vectors, since existing vectors cannot be re-embedded.
  • E) The collection was created with an encryption policy that did not match the KMS key region.
Click to reveal Answer & Explanation

Correct Answer: A

Correct Option Analysis

  • A is Correct: In Amazon Bedrock Knowledge Bases, the vector index field mapping must be configured before ingestion. If the embedding model produces 1536-dimension vectors but the vector field in OpenSearch Serverless is mapped to 768 dimensions, ingestion fails with a dimension mismatch error. The resolution is to recreate the OpenSearch Serverless collection with the correct dimension mapping, because field mappings cannot be altered after collection creation.

Distractor Analysis

  • B is Incorrect: Amazon OpenSearch Serverless is fully compatible with Amazon Titan Embeddings models; this is the default integration for Bedrock Knowledge Bases. The issue is dimension mismatch, not model compatibility.
  • C is Incorrect: There is no minimum 2048-dimension requirement for OpenSearch Serverless. Vector dimension counts vary by embedding model (e.g., Titan Text v2 = 1024, Titan Multimodal = 1024, custom models can vary).
  • D is Incorrect: Existing vectors can be regenerated using the new embedding model during a re-ingestion job; there is no requirement to stick with the old 768-dimension custom model. The team should re-embed documents with the new model and configure the correct dimension mapping.
  • E is Incorrect: Encryption policy configuration is unrelated to dimension mismatch errors. Encryption affects data-at-rest protection, not vector field validation.

Key Takeaway: Vector index dimensions must match the selected embedding model's output dimensions, and field mappings cannot be changed after collection creation—plan dimensions before first ingestion.

Question 3 - Agent Long-Term Memory Configuration in Bedrock AgentCore

A customer support organization is deploying an AI agent using Amazon Bedrock AgentCore. The agent handles a high volume of multi-turn conversations with returning customers who expect personalized responses based on previous interactions (e.g., previous issues, product preferences). The compliance team requires that cross-session memory be encrypted with a customer-managed KMS key and scoped to individual customer IDs to prevent cross-tenant data leakage. Short-term conversation state must remain isolated per session.

Which FIVE capabilities must be configured to meet these requirements? (Select FIVE)

  • A) Enable Amazon Bedrock AgentCore long-term memory with a namespace scoped to each customer identifier (e.g., /customers/{customerId}/).
  • B) Configure short-term memory with session isolation enabled to encrypt each conversation session separately.
  • C) Configure a security policy in AgentCore that specifies a KMS CMK for encrypting long-term memory at rest.
  • D) Enable Amazon Bedrock Guardrails to automatically filter cross-session and short-term memory content before writing to the memory store.
  • E) Configure an AWS Lambda function to manually persist conversation summaries to Amazon DynamoDB with per-customer partition keys and KMS encryption.
  • F) Enable AgentCore gateway with REST API integration to expose the memory management endpoints to downstream services.
  • G) Configure an AWS Glue job to transform conversation logs into a relational schema for memory storage.
Click to reveal Answer & Explanation

Correct Answers: A and C

Correct Option Analysis

  • A is Correct: Long-term memory (LTM) persists across sessions and can be scoped to a namespace based on a user/customer identifier. Configuring /customers/{customerId}/ ensures each customer's memory is isolated and prevents cross-tenant leakage.
  • C is Correct: Security policies in AgentCore allow specifying a KMS customer-managed key for encrypting long-term memory data at rest, fulfilling the compliance requirement.

Distractor Analysis

  • B is Incorrect: Short-term memory (STM) is already isolated per session by default in AgentCore; there is no "session isolation enabled" flag for encryption. STM does not require encryption configuration in this scenario.
  • D is Incorrect: Guardrails handle content filtering, PII redaction, and safety checks (e.g., blocking harmful content in prompts or responses)—not memory encryption or session isolation.
  • E is Incorrect: Manually building a memory layer with Lambda and DynamoDB is a high-overhead architectural pattern that violates the "minimize operational overhead" intent and duplicates AgentCore's native memory capabilities.
  • F is Incorrect: AgentCore gateway is for exposing enterprise APIs and tools to the agent as MCP/OpenAPI tools, not for memory management endpoints.
  • G is Incorrect: Glue ETL for conversation logs is a batch processing tool unrelated to real-time agent memory management or cross-session state persistence.

Key Takeaway: AgentCore long-term memory with namespaced scoping (per customer ID) and KMS encryption policies is the native, low-overhead approach for cross-session personalization with compliance controls.

Question 4 - SageMaker Endpoint VPC Configuration - Missing Route

A healthcare organization is deploying a custom PyTorch XGBoost model using Amazon SageMaker AI. The model artifacts are stored in an S3 bucket, and the endpoint must be deployed within a private VPC with no internet gateway, complying with HIPAA data residency requirements. During endpoint creation, the status transitions to Failed after several minutes. CloudWatch logs show the model container cannot access s3.region.amazonaws.com to download the model artifacts.

The VPC subnets route table only contains a local route. What is the minimal configuration to resolve this? (Select ONE)

  • A) Add an S3 Gateway VPC Endpoint to the VPC and update the route table for the private subnets to route S3 traffic through the endpoint.
  • B) Attach an Internet Gateway to the VPC and add a default route 0.0.0.0/0 pointing to the gateway.
  • C) Configure a NAT Gateway in a public subnet and update the route table for private subnets to route 0.0.0.0/0 to the NAT gateway.
  • D) Move the model artifacts to Amazon ECR and configure the endpoint to pull from the container registry's public endpoint.
  • E) Increase the endpoint instance type to ml.m5.4xlarge to speed up artifact downloads.
Click to reveal Answer & Explanation

Correct Answer: A

Correct Option Analysis

  • A is Correct: To allow private subnet resources to reach Amazon S3 without internet access, an S3 Gateway VPC Endpoint must be created in the VPC and attached to the private subnet's route table. This routes S3 traffic over the AWS private network (PrivateLink) directly to the S3 service, resolving the download failure while maintaining HIPAA compliance.

Distractor Analysis

  • B is Incorrect: An Internet Gateway (IGW) provides public internet access, which directly violates HIPAA data residency and the "no internet gateway" requirement. It also introduces security risks.
  • C is Incorrect: A NAT Gateway enables outbound internet access through a public subnet, which still routes traffic over the public internet (though source IPs are translated). This violates the private-network-only requirement and adds unnecessary cost.
  • D is Incorrect: Moving artifacts to ECR does not solve the network isolation problem—the endpoint would still need a private path (ECR VPC Endpoint) to pull images. Additionally, ECR is for container images, not PyTorch model artifacts.
  • E is Incorrect: Instance hardware capacity (CPU/RAM) does not resolve VPC network isolation issues. The endpoint cannot reach S3 regardless of instance size when route tables lack a path to the service.

Key Takeaway: For private VPC endpoints, the S3 Gateway VPC Endpoint is the only mechanism to reach S3 buckets without internet traversal—route table updates alone are insufficient.

Question 5 - Cross-Stack Resource Sharing with CloudFormation

A multi-tenant SaaS company is automating its ML infrastructure deployment using AWS CloudFormation. The network engineering team owns a stack (networking-stack) that creates VPC subnets and security groups. The ML team owns a separate stack (sagemaker-stack) that deploys a SageMaker AI endpoint. The ML team must reference the subnet IDs and security group IDs from the networking stack without hardcoding values or manually copying them. The networking team may update their stack independently without breaking the ML team's deployment.

Which CloudFormation strategy satisfies this requirement? (Select ONE)

  • A) The networking stack exports its subnet and security group outputs using Export fields; the ML stack imports them using Fn::ImportValue for cross-stack references.
  • B) The ML stack passes subnet and security group IDs as stack parameters, with the network team manually copying values from their stack output into the parameter values during deployment.
  • C) Both stacks share a single CloudFormation template, with the ML team referencing the network resources using Fn::GetAtt on resources defined above the endpoint resource.
  • D) The ML stack includes a Lambda custom resource that queries the VPC API at deploy time and returns subnet and security group IDs.
  • E) The network team publishes subnet and security group IDs in an AWS Systems Manager Parameter Store, and the ML stack references them via CloudFormation dynamic references.
Click to reveal Answer & Explanation

Correct Answer: A

Correct Option Analysis

  • A is Correct: CloudFormation cross-stack references using Export in the networking stack's Outputs and Fn::ImportValue in the ML stack's template is the native mechanism for sharing resource values across separately owned stacks. This decouples the two stacks while ensuring the ML stack automatically resolves the correct values. When the networking stack updates, the exported values remain stable; the ML stack cannot be updated or deleted while a dependency exists on its exports.

Distractor Analysis

  • B is Incorrect: Manually copying subnet and security group IDs into stack parameters is exactly the configuration drift problem the requirement addresses. If the networking team updates resources, the ML stack parameters become stale without manual intervention.
  • C is Incorrect: Combining both stacks into a single template couples the teams' lifecycles—the ML team would depend on the network team's resource definitions and be forced to update their stack whenever the network stack updates. This violates the "independently update" requirement.
  • D is Incorrect: While a Lambda custom resource can fetch VPC details at deploy time, it introduces unnecessary complexity. CloudFormation already provides native cross-stack references without custom code.
  • E is Incorrect: SSM Parameter Store with CloudFormation dynamic references is a valid pattern for sharing values, but it requires additional infrastructure (SSM parameter creation, KMS encryption for sensitive values) and does not provide the same CloudFormation-native dependency tracking as Export/Fn::ImportValue.

Key Takeaway: CloudFormation Export/Fn::ImportValue is the native, low-overhead pattern for cross-stack resource sharing; manual parameter copying and SSM Parameter Store introduce drift risk or unnecessary infrastructure.

Question 6 - Auto Scaling Metric Selection for Streaming Inference

A real-time recommendation engine deployed on SageMaker AI processes user behavior events. Each inference request involves a multi-step model pipeline that streams results back over a 15-30 second window. Traffic patterns show sudden spikes—concurrent requests can increase 50x within seconds during flash sales. The current auto scaling policy uses target tracking on SageMakerVariantInvocationsPerInstance with a 1-minute aggregation period, and the team observes that scale-out events consistently trigger too late, causing request queueing and timeout errors.

Which change addresses the latency in scale-out response? (Select ONE)

  • A) Change the target tracking metric to a high-resolution concurrency metric (e.g., ConcurrentRequestsPerModel or ConcurrentRequestsPerCopy) with a 10-second aggregation period.
  • B) Increase the SageMakerVariantInvocationsPerInstance target value from 100 to 500 to request more instances per invocation count.
  • C) Increase the scale-out cooldown period from 300 seconds to 600 seconds to allow more time for new instances to warm up.
  • D) Create a scheduled scaling action for the known flash sale dates, while leaving the target tracking policy unchanged for normal traffic.
  • E) Deploy a separate endpoint with provisioned concurrency for the flash sale traffic.
Click to reveal Answer & Explanation

Correct Answer: A

Correct Option Analysis

  • A is Correct: High-resolution concurrency metrics in SageMaker AI (e.g., ConcurrentRequestsPerModel or ConcurrentRequestsPerCopy) are emitted at 10-second intervals and measure in-flight requests, making them ideal for streaming workloads with rapid concurrency spikes. Target tracking on these metrics allows Application Auto Scaling to react within seconds of the spike, rather than waiting for a 1-minute aggregation.

Distractor Analysis

  • B is Incorrect: Increasing the target value on InvocationsPerInstance makes the policy less sensitive—each instance must handle more invocations before triggering a scale-out. This would worsen queueing and latency under rapid bursts.
  • C is Incorrect: A longer scale-out cooldown delays subsequent scale-out events, making the system even slower to respond to a continuing traffic surge.
  • D is Incorrect: Scheduled scaling works for predictable, recurring events (e.g., monthly flash sale at a fixed time). However, the requirement describes unpredictable spikes during flash sales that may not follow a fixed schedule. A metric-driven response is needed.
  • E is Incorrect: While provisioned concurrency on a serverless endpoint can handle bursts, this is a different hosting option (serverless vs. real-time) and does not address the auto scaling configuration issue on the existing real-time endpoint.

Key Takeaway: High-resolution concurrency metrics (10-second granularity) are the correct scaling signal for streaming inference or fast-burst workloads; invocation metrics with 1-minute aggregation react too slowly.

Question 7 - SageMaker Endpoint Deployment with Private Networking

A financial regulatory technology company is deploying a fraud detection model on SageMaker AI. The endpoint must be accessible only from within the company's VPC, with no public internet exposure. The model artifacts are stored in an S3 bucket, the container image in Amazon ECR, and the endpoint makes calls to a downstream DynamoDB table for feature lookups. The security team mandates that all data plane traffic (model artifact pulls, container image pulls, downstream service calls) must stay on the AWS private network.

Which configuration must be applied? (Select TWO)

  • A) Configure the SageMaker endpoint with VPC settings that include private subnets and security groups, with an execution role that has permission to create network interfaces.
  • B) Create VPC Endpoints (PrivateLink) for Amazon S3, Amazon ECR, and Amazon DynamoDB in the VPC and attach them to the private subnets.
  • C) Attach an Internet Gateway to the VPC and configure a security group that only allows HTTPS outbound to AWS service endpoints.
  • D) Configure the endpoint as serverless with provisioned concurrency to ensure private networking by default.
  • E) Set the EnableNetworkIsolation flag to true on the SageMaker endpoint configuration.
Click to reveal Answer & Explanation

Correct Answers: A and B

Correct Option Analysis

  • A is Correct: SageMaker endpoints with VPC network isolation require private subnets, security groups, and an IAM execution role that includes permissions like ec2:CreateNetworkInterface, ec2:DescribeNetworkInterfaces, ec2:DeleteNetworkInterface, and ec2:DescribeSubnets—these permissions allow SageMaker to create and manage the Elastic Network Interfaces (ENIs) in the designated subnets.
  • B is Correct: With private subnets lacking internet routes, VPC Endpoints (PrivateLink) for S3 (Gateway Endpoint), ECR (Interface Endpoint), and DynamoDB (Gateway Endpoint) provide private network paths to these services, ensuring traffic never leaves the AWS network.

Distractor Analysis

  • C is Incorrect: An Internet Gateway and HTTPS outbound allow traffic to traverse the public internet for API calls (even if encrypted). This violates the "data plane traffic stays on private network" requirement.
  • D is Incorrect: Serverless endpoints do not accept VPC network configuration at all. They are accessible via SageMaker's managed network and cannot enforce private subnet placement or internal-only routing.
  • E is Incorrect: EnableNetworkIsolation is a property used in SageMaker training jobs and batch transform jobs, not endpoint deployment configurations. Real-time endpoints achieve network isolation through the VPC configuration described.

Key Takeaway: For private-network-only SageMaker endpoints, the combination of private subnet placement + execution role ENI permissions + VPC Endpoints for all downstream services is required; serverless endpoints cannot enforce private networking.

Question 8 - SageMaker Container Build Strategy

A computer vision company is developing a custom inference container for a PyTorch model. The container must include a custom preprocessing pipeline (image resizing, color space conversion), a batch-level custom model handler, and GPU-accelerated inference using CUDA. The team's deployment pipeline must support frequent model updates without rebuilding the container image every time, and the image must be pullable by SageMaker endpoints without using public Docker Hub.

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

  • A) Use a prebuilt SageMaker Deep Learning Container (DLC) as the base image, extend it with the custom preprocessing code and handler, and store the image in Amazon ECR. Update model weights as separate S3 artifacts loaded at runtime—no container rebuild needed per model update.
  • B) Build a container from scratch using the SageMaker base image provided by the AWS Marketplace, and bake model weights into the image so SageMaker can pull everything in one step.
  • C) Create a Python virtual environment with OpenCV, CUDA, and PyTorch, and deploy it as a "Bring Your Own Environment" (BYOE) endpoint without a container.
  • D) Use the Amazon Deep Learning AMI as the container image, pushing it to Amazon ECR for the endpoint to pull.
  • E) Deploy the model on SageMaker Autopilot to automatically generate the container with preprocessing built in.
Click to reveal Answer & Explanation

Correct Answer: A

Correct Option Analysis

  • A is Correct: SageMaker Deep Learning Containers (DLCs) are prebuilt with optimized frameworks (PyTorch, TensorFlow, MXNet) and CUDA support, reducing the effort to build GPU-compatible containers. Extending a DLC with custom preprocessing and handler code via a Dockerfile FROM directive maintains compatibility, while storing model weights as separate S3 artifacts (loadable via model_fn) decouples model updates from container rebuilds. ECR serves as the private, AWS-native registry.

Distractor Analysis

  • B is Incorrect: Baking model weights into the container image violates the "frequent model updates without rebuilding" requirement—each new model version would require a new Docker build, image push, and endpoint deployment with container version churn.
  • C is Incorrect: SageMaker does not support BYOE without a container. All SageMaker endpoints must use a container image (DLC, custom, or prebuilt). The phrase "BYOE" is not a SageMaker feature.
  • D is Incorrect: An Amazon Deep Learning AMI is an EC2 machine image used for self-managed instances (e.g., EC2 GPU servers), not a container image. It cannot be pushed to ECR or used as a SageMaker endpoint container.
  • E is Incorrect: SageMaker Autopilot is an automated ML service that trains and deploys models for tabular data problems. It does not support computer vision preprocessing pipelines or custom GPU inference containers.

Key Takeaway: For custom preprocessing with frequent model updates, extend SageMaker DLCs with custom code (Dockerfile FROM) and store model weights in S3; avoid baking model weights into container images.

Question 9 - Bedrock Knowledge Base Ingestion - Incremental Sync

A legal document management platform uses Amazon Bedrock Knowledge Bases with an Amazon OpenSearch Serverless vector store. The platform ingests thousands of PDF legal documents from an S3 bucket on a weekly basis. New documents are added daily, existing documents occasionally have minor revisions (typo fixes, updated dates), and the compliance team requires that no stale content remains in the index after each ingestion cycle. The team must minimize ingestion compute cost and duration while ensuring the index reflects the latest document versions.

Which ingestion strategy is most appropriate? (Select ONE)

  • A) Run a full StartIngestionJob daily that deletes and recreates the OpenSearch Serverless collection from scratch.
  • B) Use Bedrock Knowledge Bases StartIngestionJob with a resync strategy that incrementally processes only new and changed documents, with deleted files removed automatically.
  • C) Configure an AWS Lambda function to monitor S3 ObjectCreated events and trigger a custom ingestion script for each new file.
  • D) Use Amazon Kendra as the retrieval engine instead, running a full data source sync on a daily schedule regardless of document changes.
  • E) Run an AWS Glue ETL job that copies all documents from S3 into a new bucket prefix weekly, triggering a full re-ingestion of all documents.
Click to reveal Answer & Explanation

Correct Answer: B

Correct Option Analysis

  • B is Correct: Amazon Bedrock Knowledge Bases supports incremental sync—when StartIngestionJob is run after the initial ingestion, it processes only new objects, modified objects, and deleted objects. DeletionPolicy settings (e.g., delete from vector store) ensure stale content is removed. This minimizes ingestion compute time and cost while maintaining index freshness.

Distractor Analysis

  • A is Incorrect: Deleting and recreating the OpenSearch Serverless collection daily is an extreme, high-cost operation that significantly increases ingestion compute and duration. It also introduces availability risk and requires full re-indexing of all documents each day.
  • C is Incorrect: A custom Lambda ingestion pipeline for each S3 object creates unnecessary operational overhead compared to Bedrock Knowledge Bases' native incremental sync. It also requires handling deletions and modifications manually.
  • D is Incorrect: Migrating to Amazon Kendra introduces a new service dependency and still requires daily full syncs if configured incorrectly. The question specifically asks about Bedrock Knowledge Bases ingestion, not a retrieval engine migration.
  • E is Incorrect: Copying all documents to a new prefix and re-ingesting everything is a full sync, not an incremental approach, and violates the "minimize ingestion compute cost and duration" requirement.

Key Takeaway: Bedrock Knowledge Bases StartIngestionJob natively performs incremental sync—processing only new, modified, and deleted objects—after the initial full ingestion.

Question 10 - Programmatic Deployment Layer Selection

An ML platform team is building a CI/CD pipeline for deploying and updating SageMaker endpoints. The pipeline must:

  1. Create or update the endpoint if it does not exist.
  2. Use a high-level API that abstracts model creation, endpoint configuration, and endpoint deployment.
  3. Be callable from a Python-based AWS Lambda function in the deployment pipeline.
  4. Avoid managing low-level API request/response structures (e.g., raw JSON bodies for CreateModel, CreateEndpointConfig, CreateEndpoint).

Which programmatic deployment approach is most appropriate? (Select ONE)

  • A) Use the SageMaker Python SDK (sagemaker) Model.deploy() or Estimator.deploy() method, which creates the model, endpoint configuration, and endpoint in a single high-level call.
  • B) Use the AWS CLI aws sagemaker create-model, create-endpoint-config, and create-endpoint commands sequentially in a shell script.
  • C) Use Boto3 to call the low-level SageMaker API methods directly (create_model, create_endpoint_config, create_endpoint) with manually constructed request dictionaries.
  • D) Use AWS CloudFormation with the AWS::SageMaker::Model, AWS::SageMaker::EndpointConfig, and AWS::SageMaker::Endpoint resources defined in a YAML template.
  • E) Use the SageMaker Studio UI to manually create and deploy the model, endpoint configuration, and endpoint from the console.
Click to reveal Answer & Explanation

Correct Answer: A

Correct Option Analysis

  • A is Correct: The SageMaker Python SDK provides a high-level deploy() method that abstracts the underlying API calls (CreateModel, CreateEndpointConfig, CreateEndpoint) into a single function call. It is Python-native, runs easily in AWS Lambda, and handles resource creation/updating transparently. This aligns with the requirement for high-level abstraction and programmatic access without managing low-level request structures.

Distractor Analysis

  • B is Incorrect: The AWS CLI is a command-line tool, not a Python API; while usable in a shell script, it does not fit the "Python-based Lambda function" requirement well and requires managing three separate CLI calls synchronously, which is low-level automation.
  • C is Incorrect: Boto3 is a lower-level client library that requires manually constructing request dictionaries for create_model, create_endpoint_config, and create_endpoint—this violates the "avoid managing low-level API structures" requirement.
  • D is Incorrect: CloudFormation is a valid IaC option for reproducibility, but the question specifies a "CI/CD pipeline" with programmatic deployment from a Lambda function. CloudFormation requires a template-driven approach, not a high-level programmatic API call from Python.
  • E is Incorrect: Manual UI deployment via Studio is not programmatic and cannot be automated in a CI/CD pipeline.

Key Takeaway: The SageMaker Python SDK's deploy() method is the preferred high-level, programmatic abstraction for orchestrating model + endpoint creation; Boto3 is the low-level fallback when precise API control is needed.