Skill 3.2.4: Configure SageMaker AI endpoints within VPC network environments
| Question | Answer & Explanation |
|---|---|
| ### Question 1 - Supported Endpoint Types for VPC Configuration A machine learning engineering team is deploying a custom fraud detection model to Amazon SageMaker AI. The company's security policies mandate that the endpoint must be deployed within an isolated Amazon VPC with no direct internet access, ensuring all traffic remains on the AWS private network backbone. Which TWO SageMaker AI endpoint types natively support VPC network configuration to fulfill this compliance requirement? (Select TWO) - A) Serverless Inference endpoint - B) Real-time Inference endpoint - C) Asynchronous Inference endpoint - D) Batch Transform job |
Correct Answers: B and C Correct Options Analysis: - B is Correct: Real-time Inference endpoints natively support VPC configuration, allowing you to specify private subnets and security groups to isolate the compute instances from the public internet. - C is Correct: Asynchronous Inference endpoints also support VPC configuration, utilizing the same private networking capabilities as Real-time endpoints for workloads with long processing times and payloads up to 1GB. Distractor Analysis: - A is Incorrect: Serverless Inference endpoints currently do not support VPC configuration. They are managed by AWS and run outside of your custom VPCs, which means they cannot meet strict private networking isolation requirements. - D is Incorrect: While Batch Transform jobs can be configured to run in a VPC, Batch Transform is an offline processing job, not a hosted endpoint type that serves real-time or asynchronous inference requests. > Key Takeaway: If a compliance requirement explicitly mandates VPC isolation for inference traffic, Serverless endpoints are automatically eliminated as an architectural option. Only Real-time, Asynchronous, and (technically) Inference Components support VPC configuration. |
| ### Question 2 - Resolving Model Artifact Download Failures A SageMaker AI real-time endpoint is deployed into private subnets that have no route to the internet. The endpoint fails to transition to the InService state and returns a timeout error while attempting to download the model artifacts stored in Amazon S3. The solution must maintain strict network isolation and minimize operational overhead.Which configuration change will resolve this issue without compromising network isolation? - A) Attach a NAT Gateway to the private subnet's route table. - B) Create an Amazon S3 Gateway VPC Endpoint and attach it to the private subnet's route table. - C) Move the model artifacts to an Amazon EFS file system and mount it to the endpoint. - D) Increase the size of the SageMaker compute instance to allow more memory for artifact caching. |
Correct Answer: B Correct Options Analysis: - B is Correct: An S3 Gateway VPC Endpoint allows resources in a private VPC to securely access Amazon S3 without traversing the public internet. Adding the endpoint to the private subnet's route table routes S3 traffic over the AWS private network, resolving the timeout while maintaining strict compliance. Distractor Analysis: - A is Incorrect: While a NAT Gateway would allow the endpoint to reach S3 via the internet, it violates the strict network isolation compliance requirement. - C is Incorrect: SageMaker real-time endpoints do not natively mount Amazon EFS for model artifacts in this manner; they pull artifacts from S3 during endpoint initialization. - D is Incorrect: Increasing the instance size addresses compute/memory capacity but does not resolve underlying VPC route table network isolation issues preventing S3 access. > Key Takeaway: For SageMaker endpoints in isolated VPCs, an S3 Gateway VPC Endpoint is the most cost-effective and compliant way to reach model artifacts in Amazon S3 without internet access. |
| ### Question 3 - Securing Custom Container Image Pulls An AI team has packaged a custom inference container and pushed it to Amazon ECR. A SageMaker AI real-time endpoint is configured to use this custom image, but the endpoint deployment fails in an isolated VPC with an error indicating it cannot pull the Docker image. The VPC already has an S3 Gateway Endpoint configured. Which additional networking component is required to resolve this issue while keeping traffic private? - A) Create an Interface VPC Endpoint for Amazon ECR. - B) Create a Gateway VPC Endpoint for Amazon ECR. - C) Create an Interface VPC Endpoint for Amazon S3. - D) Configure an AWS Site-to-Site VPN to the ECR registry. |
Correct Answer: A Correct Options Analysis: - A is Correct: Amazon ECR requires an Interface VPC Endpoint (powered by AWS PrivateLink) to allow private subnets to pull Docker images without an internet gateway or NAT gateway. ECR does not support Gateway VPC Endpoints. Distractor Analysis: - B is Incorrect: Amazon ECR supports Interface VPC Endpoints, not Gateway VPC Endpoints. Gateway endpoints are only supported for Amazon S3 and Amazon DynamoDB. - C is Incorrect: While ECR stores container image layers in S3, the Docker daemon must first authenticate and resolve the manifest via the ECR API, which requires an Interface Endpoint for ECR. An S3 Interface endpoint alone won't resolve the authentication failure. - D is Incorrect: A Site-to-Site VPN introduces unnecessary operational complexity, cost, and does not leverage native AWS private networking via PrivateLink. > Key Takeaway: When using custom containers in an isolated SageMaker VPC, you must configure an Interface VPC Endpoint for Amazon ECR (and an S3 Gateway/Interface Endpoint for the image layers) to successfully pull images privately. |
| ### Question 4 - Cross-Stack VPC Configuration A centralized networking team manages the Amazon VPC infrastructure using AWS CloudFormation. A separate data science team manages the SageMaker AI deployment stack. The data science team needs to deploy a SageMaker endpoint using the private subnets and security groups provisioned by the networking team. The solution must prevent configuration drift if the networking team updates or recreates the subnets. How should the SageMaker stack reference the network configurations? - A) Manually copy the Subnet IDs and Security Group IDs into the SageMaker stack's parameters. - B) Use an Fn::ImportValue function in the SageMaker stack to dynamically import exported values from the networking stack.- C) Create a cross-account IAM role allowing the data science team to read the networking stack's template. - D) Deploy the SageMaker endpoint in the default VPC and use VPC peering. |
Correct Answer: B Correct Options Analysis: - B is Correct: AWS CloudFormation cross-stack references allow one stack to export values (like Subnet IDs) and another stack to import them using Fn::ImportValue. This decouples infrastructure ownership while ensuring the SageMaker stack dynamically references the correct, current network resources without manual intervention.Distractor Analysis: - A is Incorrect: Manually copying identifiers creates configuration drift. If the networking team changes the subnets, the SageMaker stack will still reference the old, potentially non-existent subnets, causing deployment failures. - C is Incorrect: Granting IAM permissions to read templates does not automatically pass runtime resource values (like Subnet IDs) into the SageMaker stack configuration. - D is Incorrect: Using the default VPC violates enterprise security best practices, and VPC peering is unnecessary and overly complex for stacks existing within the same account. > Key Takeaway: Use CloudFormation Export and Fn::ImportValue to cleanly share VPC subnet and security group IDs across team boundaries without hardcoding identifiers or risking configuration drift. |
| ### Question 5 - IAM Permissions for VPC Network Interfaces A data scientist is attempting to deploy a SageMaker AI real-time endpoint into a private VPC. The deployment fails with the following error: ClientError: SageMaker was unable to assume the execution role with network interface creation permissions.Which IAM policy action must be added to the SageMaker execution role to resolve this error? - A) ec2:CreateNetworkInterface- B) sagemaker:CreateEndpointConfig- C) s3:GetObject- D) ecr:BatchGetImage |
Correct Answer: A Correct Options Analysis: - A is Correct: When you deploy a SageMaker endpoint into a VPC, SageMaker creates Elastic Network Interfaces (ENIs) in your specified subnets to attach to the compute instances. The execution role must have permissions to create, describe, and delete these network interfaces, specifically including ec2:CreateNetworkInterface.Distractor Analysis: - B is Incorrect: sagemaker:CreateEndpointConfig is required to create the endpoint configuration itself, but it does not grant the underlying compute environment permission to provision network interfaces within the VPC.- C is Incorrect: s3:GetObject allows the endpoint to download model artifacts from S3, but it does not resolve network interface creation failures.- D is Incorrect: ecr:BatchGetImage allows the endpoint to pull container images, but similarly, it does not affect VPC ENI creation.> Key Takeaway: The SageMaker execution role requires EC2 network interface permissions ( ec2:CreateNetworkInterface, ec2:DescribeNetworkInterfaces, ec2:DeleteNetworkInterface) to attach the endpoint to your private VPC subnets. |
| ### Question 6 - Invoking Private Downstream Microservices A SageMaker AI real-time endpoint is deployed in an isolated VPC. During inference, the model container must synchronously invoke an internal microservice hosted on an Amazon API Gateway (Private REST API) to fetch user metadata. The endpoint currently fails to reach the microservice and times out. Which networking configuration is required to allow the SageMaker endpoint to securely communicate with the private API Gateway? - A) Create a Gateway VPC Endpoint for API Gateway. - B) Create an Interface VPC Endpoint for API Gateway. - C) Attach an Internet Gateway to the VPC and update the private subnet route table. - D) Deploy the microservice on AWS Lambda and configure a VPC peering connection. |
Correct Answer: B Correct Options Analysis: - B is Correct: To access a private REST API on Amazon API Gateway from a private VPC without internet access, you must create an Interface VPC Endpoint for API Gateway. The SageMaker endpoint can then route traffic to the API Gateway privately via AWS PrivateLink. Distractor Analysis: - A is Incorrect: API Gateway does not support Gateway VPC Endpoints. Only Amazon S3 and DynamoDB support Gateway VPC Endpoints. - C is Incorrect: Attaching an Internet Gateway to a private subnet defeats the purpose of network isolation and violates standard private VPC security postures. - D is Incorrect: Rebuilding the microservice on Lambda with VPC peering introduces unnecessary operational overhead and complexity when API Gateway natively supports Interface VPC Endpoints. > Key Takeaway: To invoke private AWS services like API Gateway, SageMaker, or KMS from an isolated VPC, use Interface VPC Endpoints (AWS PrivateLink). Gateway Endpoints are exclusively for S3 and DynamoDB. |
| ### Question 7 - VPC Endpoint Security Group Configuration A ML engineer is configuring an Interface VPC Endpoint for Amazon ECR so a SageMaker real-time endpoint in a private subnet can pull its Docker image. The endpoint deployment fails, and VPC Flow Logs show traffic being silently dropped on port 443. The SageMaker endpoint's security group allows all outbound traffic. How should the engineer configure the security groups to resolve this connectivity issue? - A) Add an inbound rule to the ECR Interface VPC Endpoint's security group allowing TCP 443 from the SageMaker endpoint's security group. - B) Add an inbound rule to the SageMaker endpoint's security group allowing TCP 443 from the ECR Interface VPC Endpoint's security group. - C) Add an outbound rule to the ECR Interface VPC Endpoint's security group allowing TCP 443 to 0.0.0.0/0.- D) Configure the ECR Interface VPC Endpoint to use the VPC's default security group. |
Correct Answer: A Correct Options Analysis: - A is Correct: Interface VPC Endpoints operate by attaching an ENI to your subnets, which is governed by a security group. To allow the SageMaker endpoint (source) to send requests to the ECR Endpoint (destination), the ECR Endpoint's security group must have an inbound rule allowing TCP 443 from the SageMaker endpoint's security group ID. Distractor Analysis: - B is Incorrect: The SageMaker endpoint is the initiator of the connection. Inbound rules on the SageMaker endpoint are not evaluated for outbound request initiation unless return traffic is explicitly blocked (which is not the case if all outbound is allowed; stateful firewalls handle return traffic). - C is Incorrect: The issue is that the request traffic is being dropped before reaching the ECR endpoint. Outbound rules on the destination endpoint do not affect incoming traffic filtering. - D is Incorrect: Using the default security group is not a specific fix and often defaults to allowing no external inbound traffic, which would not resolve the dropped packets without explicit configuration. > Key Takeaway: Interface VPC Endpoints require explicit inbound security group rules to accept traffic. The standard practice is to allow TCP 443 from the source resource's (SageMaker endpoint) security group. |
| ### Question 8 - Handling Outbound Dependencies in Isolated VPCs A custom SageMaker inference container requires downloading dynamic Python dependencies from PyPI during the container startup ( /opt/ml/ code path) before serving traffic. The endpoint is deployed in an isolated private VPC. The compliance team permits outbound internet access for dependency resolution, but forbids inbound internet access.Which configuration satisfies these constraints with the least operational overhead? - A) Provision a NAT Gateway in a public subnet and update the private subnet route table to route 0.0.0.0/0 to the NAT Gateway.- B) Pre-bake the dependencies into the Docker image and remove the startup download logic. - C) Create an Interface VPC Endpoint for PyPI. - D) Attach an Internet Gateway directly to the private subnet route table. |
Correct Answer: B Correct Options Analysis: - B is Correct: While the question permits outbound internet access, baking dependencies into the Docker image is an AWS best practice that results in the least operational overhead, faster startup times, and higher availability. It removes the runtime dependency on external networks entirely. Distractor Analysis: - A is Incorrect: While a NAT Gateway would technically satisfy the outbound internet access requirement, it introduces ongoing operational overhead (managing NAT ports, costs) and container startup latency. Pre-baking dependencies is a simpler, more robust architecture. - C is Incorrect: PyPI is an external public repository and does not support AWS PrivateLink Interface VPC Endpoints. - D is Incorrect: You cannot attach an Internet Gateway directly to a private subnet route table to provide outbound-only internet access for private instances; this would also allow inbound public routing, violating the compliance rule and bypassing the NAT requirement. > Key Takeaway: For SageMaker custom containers in VPCs, always pre-bake external dependencies into the ECR image. If runtime internet access is absolutely unavoidable, a NAT Gateway is required, but it increases latency and operational overhead. |
| ### Question 9 - Multi-AZ Constraints for VPC Endpoints A team is deploying a single-instance SageMaker AI real-time endpoint in a private VPC for a low-traffic development environment. They specify a single private subnet in the VpcConfig parameter of the endpoint configuration. The deployment fails with a validation error regarding subnet requirements.How can the team resolve this error while meeting SageMaker VPC networking constraints? - A) Specify at least two private subnets located in different Availability Zones within the same VPC. - B) Specify a single public subnet with an Internet Gateway attached. - C) Upgrade the endpoint to a Serverless Inference endpoint, which does not require multiple subnets. - D) Deploy the endpoint in the default VPC and disable VPC configuration. |
Correct Answer: A Correct Options Analysis: - A is Correct: When configuring a SageMaker real-time or asynchronous endpoint in a VPC, you must specify at least two subnets in different Availability Zones. This ensures high availability and allows SageMaker to seamlessly shift the endpoint to another AZ in the event of an AZ failure, even for single-instance configurations. Distractor Analysis: - B is Incorrect: Using a public subnet violates the standard private VPC isolation pattern and does not resolve the requirement for multiple AZs for SageMaker VPC endpoints. - C is Incorrect: Serverless endpoints do not support VPC configuration at all. Furthermore, the prompt mandates the endpoint be configured within the VPC network environment. - D is Incorrect: Disabling VPC configuration violates the premise of the task, which is to deploy the endpoint within the existing VPC architecture. > Key Takeaway: SageMaker requires at least two subnets in different Availability Zones when deploying Real-time and Asynchronous endpoints in a VPC, regardless of the initial instance count. |
| ### Question 10 - Private Access to AWS KMS for Artifact Decryption A SageMaker AI endpoint in an isolated VPC pulls encrypted model artifacts from Amazon S3. The artifacts are encrypted using a customer-managed AWS KMS key. An S3 Gateway VPC Endpoint is correctly configured, and the IAM role has KMS decrypt permissions, but the endpoint fails to decrypt the artifacts. Which networking component is missing to ensure the endpoint can access the KMS key privately? - A) A Gateway VPC Endpoint for AWS KMS. - B) An Interface VPC Endpoint for AWS KMS. - C) A VPC Peering connection to the KMS service account. - D) A NAT Gateway to allow the KMS API to resolve over public DNS. |
Correct Answer: B Correct Options Analysis: - B is Correct: AWS KMS API calls are required to decrypt S3 objects. To keep this traffic private and off the public internet, you must provision an Interface VPC Endpoint for AWS KMS. KMS does not support Gateway VPC Endpoints. Distractor Analysis: - A is Incorrect: AWS KMS only supports Interface VPC Endpoints (AWS PrivateLink). Gateway Endpoints are exclusively supported for Amazon S3 and Amazon DynamoDB. - C is Incorrect: VPC Peering cannot be used to access AWS managed services like KMS. Interface VPC Endpoints are the supported mechanism for private service access. - D is Incorrect: Using a NAT Gateway breaks the strict isolated VPC compliance requirement and introduces unnecessary cost and complexity when native PrivateLink is available. > Key Takeaway: If your SageMaker endpoint uses KMS-encrypted artifacts in S3, you need both an S3 VPC Endpoint (Gateway or Interface) for the storage and an Interface VPC Endpoint for AWS KMS to perform the decryption privately. |