Skill 3.2.2: Automate compute resource provisioning with integrated communication between stacks and orchestration services.

Question 1 - Cross-Stack Dependencies in Infrastructure as Code

A financial services company is deploying a fraud detection model for real-time inference. The infrastructure is managed by two separate teams: a Platform Engineering team that owns VPC networking resources (subnets, security groups, NAT gateways) via a CloudFormation stack named platform-network, and a Data Science team that owns the SageMaker endpoint resources via a separate CloudFormation stack named ml-hosting.

The Data Science team must deploy their endpoint into the private subnets owned by the Platform team, and the endpoint must persist the VPC configuration across stack updates. The Platform team has agreed to expose only high-level outputs from their stack. The Data Science team needs zero manual copying of identifiers and automatic updates if the Platform team's stack exports change.

Which ONE approach should the Data Science team implement?

A) Use a CloudFormation parameter in the ml-hosting stack for Subnet IDs and instruct the Platform team to notify them whenever the values may change.
B) In the ml-hosting stack, use Fn::ImportValue to reference the Subnet IDs exported by the platform-network stack.
C) Store the Subnet IDs in AWS Secrets Manager, and have the ml-hosting stack retrieve them via a dynamic reference when creating the endpoint.
D) Use AWS Step Functions to read the Subnet IDs from the platform-network stack's resource output and pass them to the ml-hosting stack as overrides.
E) Hardcode the Subnet IDs in the ml-hosting template and use a CloudFormation drift detection workflow to identify any changes.

Click to reveal Answer & Explanation

Correct Answer: B

Correct Options Analysis

B is Correct: CloudFormation cross-stack references via Fn::ImportValue allow a stack to import values from another stack's exported outputs. When the platform-network stack exports updated values, the ml-hosting stack automatically references the new values on the next update, maintaining a decoupled but synchronized relationship. This eliminates manual copying and provides automatic updates.

Distractor Analysis

A is Incorrect: Using a parameter with manually copied identifiers creates drift, requires operational coordination, and does not provide automatic updates when the Platform team changes the subnets.
C is Incorrect: AWS Secrets Manager is designed for secrets like passwords and API keys, not for storing subnet identifiers. This adds unnecessary operational overhead and creates a false dependency.
D is Incorrect: Step Functions does not provide CloudFormation stack resource introspection in this context, and this approach introduces orchestration complexity without addressing the core need for cross-stack reference linkage.
E is Incorrect: Hardcoding identifiers creates a fragile architecture with drift, and CloudFormation drift detection only identifies inconsistencies after the fact—it does not automatically reconcile or update configuration.

Key Takeaway: Use CloudFormation cross-stack references (Fn::ImportValue and Export) to decouple network and hosting stacks, eliminating manual copying and enabling automatic propagation of exported values.

Question 2 - Automated Model Deployment with CloudFormation

A retail company wants to automate the deployment of a product recommendation model on Amazon SageMaker. The model training job produces a model.tar.gz artifact in an S3 bucket. The deployment pipeline must create:

A SageMaker model
An endpoint configuration
An endpoint

Each resource must be created in the correct order (model → endpoint configuration → endpoint). The cloud engineering team wants to manage this entire stack using infrastructure as code (IaC) so it can be committed to a Git repository and reproduced across dev, staging, and prod environments.

Which ONE of the following is the best way to define this automated pipeline with the least operational overhead?

A) Write a Python script using Boto3 that creates the model, endpoint configuration, and endpoint in sequence.
B) Create a CloudFormation template that defines the AWS::SageMaker::Model, AWS::SageMaker::EndpointConfig, and AWS::SageMaker::Endpoint resources with DependsOn attributes to enforce ordering.
C) Use AWS Lambda functions triggered by S3 events to create the model, endpoint configuration, and endpoint step-by-step.
D) Use AWS Glue workflows to orchestrate the creation of SageMaker resources across dev, staging, and prod.
E) Register a scaled target in Application Auto Scaling and let it provision the endpoint automatically.

Click to reveal Answer & Explanation

Correct Answer: B

Correct Options Analysis

B is Correct: CloudFormation is the native AWS Infrastructure as Code (IaC) service, and the AWS::SageMaker::Model, AWS::SageMaker::EndpointConfig, and AWS::SageMaker::Endpoint resource types are all natively supported. The DependsOn attribute ensures correct resource creation ordering. The template can be committed to Git, versioned, and reused across environments with parameters. This is an idempotent, declarative approach.

Distractor Analysis

A is Incorrect: While Boto3 scripting works, it lacks IaC benefits like idempotency, declarative state, and reproducibility via CloudFormation stacks. A script would need manual error handling and state tracking.
C is Incorrect: Using Lambda functions for this use case introduces unnecessary operational complexity and custom code, and Lambda has execution time limits that may complicate orchestrating multi-resource deployments.
D is Incorrect: AWS Glue workflows are used for ETL job orchestration and data pipeline management, not for provisioning SageMaker model hosting resources.
E is Incorrect: Application Auto Scaling only manages scaling policies for existing endpoints—it does not create or deploy models or endpoint configurations.

Key Takeaway: For reproducible, versioned, and declarative ML infrastructure deployment, CloudFormation (or CDK) is the preferred approach over custom scripts or serverless orchestration.

Question 3 - SageMaker SDK Programmatic Deployment

A data science team is automating the deployment of a trained XGBoost model to Amazon SageMaker. The model artifact is stored at s3://ml-models/xgboost/model.tar.gz. The team wants to deploy the model using the SageMaker Python SDK for a simpler, higher-level abstraction than raw Boto3 API calls.

The deployment script needs to:

Create a model from the S3 artifact
Deploy it to a real-time endpoint with one ml.m5.xlarge instance
Set the endpoint name to xgboost-endpoint-prod

Which ONE code pattern using the SageMaker Python SDK best accomplishes this with the least code?

A) Use sagemaker.model.Model and call .deploy() with the instance type, initial instance count, and endpoint name.
B) Use Boto3 create_model(), create_endpoint_config(), and create_endpoint() in sequence.
C) Use the AWS CLI aws sagemaker create-model, create-endpoint-config, and create-endpoint commands in a shell script.
D) Use CloudFormation to define AWS::SageMaker::Model, AWS::SageMaker::EndpointConfig, and AWS::SageMaker::Endpoint resources.
E) Use an S3 lifecycle policy to trigger a SageMaker deployment job.

Click to reveal Answer & Explanation

Correct Answer: A

Correct Options Analysis

A is Correct: The SageMaker Python SDK provides a high-level abstraction that simplifies model deployment. The Model class accepts a model artifact and can call .deploy(instance_type='ml.m5.xlarge', initial_instance_count=1, endpoint_name='xgboost-endpoint-prod') to automatically create all underlying resources (model, endpoint configuration, endpoint) in one method call.

Distractor Analysis

B is Incorrect: Boto3 is the lower-level client that requires three distinct API calls with separate parameter structures. This is more verbose and provides less abstraction, even though it's the underlying foundation of the SageMaker SDK.
C is Incorrect: AWS CLI also requires multiple commands with explicit parameter files and creates a procedural shell script rather than leveraging the Python SDK's higher-level abstraction.
D is Incorrect: CloudFormation is a valid IaC approach but involves significantly more code (template YAML/JSON) compared to the SageMaker Python SDK's .deploy() method for a simple single endpoint deployment.
E is Incorrect: S3 lifecycle policies are used for object transition (e.g., Archive/Delete), not for triggering SageMaker model deployments.

Key Takeaway: For simple programmatic deployments, the SageMaker Python SDK .deploy() method provides the highest-level abstraction; Boto3, CLI, and CloudFormation offer progressively more control at the cost of more code.

Question 4 - Step Functions Orchestration of ML Workflow

An e-commerce company is building an end-to-end ML pipeline that must:

Trigger a Glue job to preprocess incoming customer transaction data from S3
Run a SageMaker training job using the preprocessed data
Perform hyperparameter tuning and select the best model
Create a SageMaker model and deploy it to an endpoint
If the training step fails, send an SNS notification and halt the pipeline

The data engineering team wants to orchestrate this pipeline using an event-driven serverless workflow with built-in retry logic for each step and least operational overhead.

Which ONE AWS service is best suited to define and manage this workflow?

A) AWS CloudFormation with a custom Lambda-backed custom resource for each step
B) AWS Step Functions with a state machine that defines each step as a task with built-in Retry and Catch blocks
C) A sequence of S3 event notifications triggering Lambda functions that invoke each ML step
D) A cron job running on an EC2 instance that polls status and invokes each service sequentially
E) Amazon SageMaker Pipelines with a ConditionStep and Retry logic for orchestration

Click to reveal Answer & Explanation

Correct Answer: B

Correct Options Analysis

B is Correct: AWS Step Functions is the native serverless orchestration service. It supports task states for Glue jobs, SageMaker training, tuning, model creation, and endpoint deployment, with built-in Retry blocks for transient failures, Catch blocks for error handling (e.g., failed training → SNS notification → halt), and a visual workflow to track state transitions. This is fully managed with zero infrastructure overhead.

Distractor Analysis

A is Incorrect: CloudFormation alone is not designed for stateful workflow orchestration; custom Lambda-backed resources would introduce significant complexity and custom code for a use case that Step Functions natively supports.
C is Incorrect: Chaining S3 event notifications and Lambda functions lacks built-in retry logic, error handling (Catch), and state management, making it error-prone and operationally complex.
D is Incorrect: An EC2 cron job requires managing compute infrastructure and introduces availability and reliability concerns; Step Functions is serverless and fully managed.
E is Incorrect: While SageMaker Pipelines is excellent for ML training orchestration, Step Functions is the more general-purpose serverless workflow orchestrator that can natively integrate Glue, SageMaker training, model deployment, and SNS notifications with broader service integration.

Key Takeaway: AWS Step Functions is the optimal orchestrator for multi-service ML workflows with complex error handling, retry logic, and state tracking, while SageMaker Pipelines is specialized for the training pipeline itself.

Question 5 - ECR Container Image Versioning

A machine learning team is deploying a custom inference container to Amazon SageMaker. The container includes a preprocessing layer, a custom model loading mechanism, and a Flask-based prediction handler.

The team is pushing the container to Amazon Elastic Container Registry (ECR) and will reference the image in the SageMaker model definition.

For production reliability, what is the best practice for referencing the container image?

A) Use the latest tag in ECR and override it with every deployment.
B) Use a unique immutable tag (e.g., a Git commit SHA or build number) for each production deployment.
C) Store the container image in S3 and reference it via a presigned URL in the SageMaker model.
D) Use a mutable tag like prod that is force-pushed with each new build.
E) Reference the container image by digest URL (@sha256:...) without any tag.

Click to reveal Answer & Explanation

Correct Answer: B

Correct Options Analysis

B is Correct: Using an immutable unique tag per build (e.g., sha-9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08 or a build number) ensures that the container image referenced by a SageMaker endpoint configuration is deterministic and reproducible. Rolling back to a previous version is straightforward since each tag points to a fixed image digest.

Distractor Analysis

A is Incorrect: Using latest is dangerous because the tag is mutable—a new push to latest can silently change which image a new endpoint deployment pulls, leading to unpredictable behavior and difficult debugging.
C is Incorrect: SageMaker endpoints pull container images from ECR (or a compatible OCI registry), not from S3 presigned URLs. This is an invalid architectural pattern.
D is Incorrect: Using a mutable prod tag has the same issue as latest: force-pushing a new build invisibly changes the meaning of the tag, making rollback and reproducibility difficult.
E is Incorrect: While digest references are immutable and deterministic, they are non-human-readable and difficult to manage in CI/CD pipelines. A unique tag is equally immutable and more practical. Digest references may be used as a supplement, not a replacement.

Key Takeaway: Use immutable Docker image tags (Git SHA, build number) for production inference containers; never rely on mutable tags like latest or prod for deployed endpoints.

Question 6 - Application Auto Scaling Metric Selection

A financial forecasting application uses Amazon SageMaker to serve multiple models (e.g., revenue prediction, cash flow forecasting) via SageMaker multi-model endpoints.

The workload exhibits periodic traffic spikes that occur within seconds (e.g., when the finance dashboard opens at 8:00 AM and numerous analysts query models simultaneously). The team notices the current auto scaling policy on SageMakerVariantInvocationsPerInstance takes too long to add capacity during these rapid spikes.

The team has enabled concurrency-based scaling and wants to monitor the in-flight requests to trigger scaling faster.

Which ONE configuration should they use to reduce the time to detect and respond to these traffic spikes?

A) Use a target tracking policy on SageMakerVariantInvocationsPerInstance with a lower target value.
B) Use a target tracking policy on a high-resolution concurrency metric such as ConcurrentRequestsPerModel or ConcurrentRequestsPerCopy.
C) Increase the scale-out cooldown period to ensure faster scaling actions.
D) Use a scheduled scaling action that anticipates the 8:00 AM traffic spike.
E) Disable auto scaling and provision a fixed number of instances.

Click to reveal Answer & Explanation

Correct Answer: B

Correct Options Analysis

B is Correct: High-resolution concurrency metrics like ConcurrentRequestsPerModel or ConcurrentRequestsPerCopy are emitted at sub-minute intervals (e.g., every 10 seconds), enabling Application Auto Scaling to detect and react to sudden traffic spikes much faster than the standard 1-minute InvocationsPerInstance metric. This is the optimal solution for rapidly changing concurrent traffic.

Distractor Analysis

A is Incorrect: A lower target value on SageMakerVariantInvocationsPerInstance would make scaling more sensitive, but the underlying metric still publishes at 1-minute granularity, so it cannot react to sub-minute traffic spikes quickly enough.
C is Incorrect: Increasing the scale-out cooldown period delays subsequent scaling actions, making the policy even slower to react to new traffic spikes.
D is Incorrect: Scheduled scaling helps with predictable calendar-based events (e.g., 8:00 AM on weekdays), but it does not address sudden unpredictable spikes or dynamic in-flight request changes.
E is Incorrect: Disabling auto scaling and using a fixed number of instances removes the elasticity needed to handle variable traffic patterns efficiently, potentially leading to under-provisioning (high latency) or over-provisioning (wasted cost).

Key Takeaway: For sub-minute traffic spikes in SageMaker inference, use high-resolution concurrency metrics like ConcurrentRequestsPerModel or ConcurrentRequestsPerCopy in target tracking policies for fast scaling decisions.

Question 7 - Bedrock Knowledge Base Vector Store Configuration

A legal document review application is being built using Amazon Bedrock Knowledge Bases and Amazon OpenSearch Serverless.

The application must support:

Semantic similarity search over legal case summaries
Exact keyword matching for case numbers (e.g., "Case-2024-0891")
Metadata filtering on case_status and court_jurisdiction

The data engineering team must configure the knowledge base with the correct vector store configuration to support all three retrieval patterns.

Which TWO configurations are required before ingesting documents? (Select TWO)

A) Create an OpenSearch Serverless collection with a vector index that has dimensions matching the embedding model's output vector dimension.
B) Map the case_number field as a filterable text field in the index mapping to support exact-match search.
C) Enable server-side encryption on the S3 bucket to ensure hybrid search is supported.
D) Configure a relational database as the primary vector store to enable case number lookups.
E) Enable metadata filtering using structured fields (case_status, court_jurisdiction) in the OpenSearch index mapping.

Click to reveal Answer & Explanation

Correct Answer: A and E

Correct Options Analysis

A is Correct: Vector dimensions must match the embedding model's output dimension (e.g., Amazon Titan Text Embeddings v2 produces 1024-dimensional vectors). If dimensions don't match, ingestion fails. This is a mechanical requirement for any vector store used with Bedrock Knowledge Bases.
E is Correct: Metadata fields must be declared in the index mapping before ingestion, enabling filtering by structured attributes (case_status, court_jurisdiction) at query time. Without metadata mapping, the retrieval pipeline cannot apply pre-similarity filters.

Distractor Analysis

B is Incorrect: Mapping case_number as a filterable text field supports lexical/exact matching, but this is a configuration detail rather than a requirement for hybrid search per se. Hybrid search requires both dense vectors and a filterable text field—case_number is an example of a field suitable for lexical matching.
C is Incorrect: S3 server-side encryption is a security and compliance best practice but has no connection to enabling hybrid search or metadata filtering.
D is Incorrect: A relational database (e.g., Amazon RDS) stores embeddings alongside relational records, but it does not provide native hybrid search over unstructured text corpus like legal case summaries. OpenSearch Service (with its built-in BM25 and k-NN search) is the correct choice for hybrid search over case summaries and metadata filtering.

Key Takeaway: Before ingesting documents into Bedrock Knowledge Bases, ensure index dimensions match the embedding model and metadata fields are mapped in the vector store schema.

Question 8 - SageMaker Endpoint in Private VPC

A healthcare AI startup is deploying a medical image diagnostic model on Amazon SageMaker to comply with HIPAA regulations.

Requirements:

All model traffic and data flows must stay within the private AWS network (no internet traversal).
The model artifact is stored in an S3 bucket.
The endpoint container must pull its image from Amazon ECR.
The endpoint needs to make inference requests to an internal service via AWS PrivateLink.

The team wants to configure the SageMaker endpoint in private subnets with no internet gateway and ensure all service endpoints are reachable.

Which THREE steps must be completed? (Select THREE)

A) Create an Amazon S3 VPC endpoint (gateway endpoint) and add it to the route table of the private subnets.
B) Create an Amazon ECR VPC endpoint (interface endpoint) in the VPC so SageMaker can pull the container image without internet access.
C) Configure the SageMaker endpoint with NetworkConfig specifying private subnets in the VPC.
D) Attach an Internet Gateway to the VPC and add a route in the private subnets for outbound internet access.
E) Create an AWS PrivateLink endpoint for the internal downstream service and ensure the SageMaker execution role has the necessary permissions to create and attach network interfaces.

Click to reveal Answer & Explanation

Correct Answer: A, B, C

Correct Options Analysis

A is Correct: An S3 VPC gateway endpoint (Amazon S3 Gateway Endpoint) added to the private subnet route tables allows SageMaker instances to retrieve model artifacts from S3 using private AWS network paths without internet traversal.
B is Correct: An ECR VPC interface endpoint (AWS PrivateLink) provides a private DNS name and network path so SageMaker can pull the container image from ECR without traversing the internet.
C is Correct: The SageMaker endpoint must be configured with NetworkConfig (VpcConfig) specifying the private subnets and security groups. This places the endpoint's network interfaces in the private subnets, enabling all traffic to remain within the VPC.

Distractor Analysis

D is Incorrect: An Internet Gateway with an outbound route provides internet access, which directly violates the requirement of no internet traversal. Private subnets with no IGW or NAT are required.
E is Incorrect: While creating a PrivateLink endpoint for internal services is correct, this option incorrectly describes the execution role permissions. The execution role for SageMaker needs ec2:CreateNetworkInterface and related permissions, but the VPC endpoint creation is a separate architectural step (option E was misleadingly combining both). AWS PrivateLink endpoints are used for service-to-service communication, but the question asks specifically for S3 and ECR access paths.

Key Takeaway: For fully private SageMaker endpoints: configure VpcConfig with private subnets, create VPC endpoints for S3 (gateway) and ECR (interface), and ensure the execution role has network interface permissions.

Question 9 - SageMaker HyperPod for Resilient Training

A deep learning research team is training a massive transformer model (billions of parameters) on a multi-node GPU cluster using SageMaker HyperPod.

Training takes 3-4 weeks, and any node failure could cost days of lost progress. The team needs a solution where faulty nodes are automatically detected and replaced so training can continue without manual intervention.

Which TWO features of SageMaker HyperPod best support this requirement? (Select TWO)

A) Automatic node health monitoring and replacement of faulty instances.
B) Integration with Amazon EKS or Slurm for cluster orchestration.
C) Built-in hyperparameter tuning with Bayesian optimization.
D) Automatic model quantization and compression for faster inference.
E) Elastic Inference accelerators (EIA) attached to the cluster for cost optimization.

Click to reveal Answer & Explanation

Correct Answer: A and B

Correct Options Analysis

A is Correct: SageMaker HyperPod provides automatic health checks and self-healing capabilities. When a node fails (e.g., GPU failure, network partition), HyperPod detects the failure and automatically replaces the faulty node with a healthy one, allowing distributed training to resume without manual intervention.
B is Correct: SageMaker HyperPod supports workload managers like Slurm and Amazon EKS for cluster orchestration, which helps schedule distributed training jobs and manage the cluster. This is a core capability for running multi-node resilient training.

Distractor Analysis

C is Incorrect: Hyperparameter tuning is provided by SageMaker Automatic Model Tuning (AMT), not by HyperPod. HyperPod is specifically for resilient distributed training infrastructure.
D is Incorrect: Model quantization and compression are post-training optimization techniques for inference, typically done using SageMaker Neo or custom scripts—not a feature of HyperPod.
E is Incorrect: Elastic Inference (EIA) is a legacy feature for CPU-based inference acceleration, not relevant to training workloads on HyperPod GPU clusters.

Key Takeaway: SageMaker HyperPod's self-healing node replacement and workload manager integration (Slurm/EKS) make it ideal for long-running distributed training jobs that require resilience against hardware failures.

Question 10 - Bedrock Knowledge Base Ingestion and Retrieval Pipeline

A customer support team is building a chatbot using Amazon Bedrock Knowledge Bases with Amazon OpenSearch Serverless as the vector store.

The initial knowledge base contains 10,000 documents (product manuals, FAQs, troubleshooting guides). The team uploads a new batch of 500 updated documents to the S3 bucket that serves as the knowledge base data source.

The team needs to process only the new and changed documents since the last ingestion to minimize indexing time and cost.

Which ONE approach should they use?

A) Delete the existing OpenSearch collection and re-ingest all 10,500 documents from scratch to ensure consistency.
B) Use StartIngestionJob on the knowledge base, as it automatically performs incremental ingestion—processing only new and modified documents since the last run.
C) Write a custom Lambda function that uses S3 Event Notifications to detect new files and manually index them into OpenSearch.
D) Create a new Bedrock Knowledge Base data source pointing to the same S3 bucket and trigger a one-time full ingestion for the new batch.
E) Use CloudWatch Events to schedule a daily batch transform job to convert documents into vector embeddings.

Click to reveal Answer & Explanation

Correct Answer: B

Correct Options Analysis

B is Correct: Amazon Bedrock Knowledge Bases StartIngestionJob (or IngestKnowledgeBase action) natively supports incremental ingestion. It automatically detects new and modified documents in the S3 bucket since the last ingestion job and processes only those changes, avoiding the cost and time of re-indexing all documents. This is the least operational overhead approach.

Distractor Analysis

A is Incorrect: Deleting and re-ingesting all 10,500 documents is extremely inefficient and unnecessary. Incremental ingestion avoids this overhead.
C is Incorrect: Writing a custom Lambda function for document parsing, embedding, and indexing introduces significant operational complexity and custom code when Bedrock Knowledge Bases already provides native ingestion and reconciliation.
D is Incorrect: Creating a new data source and full ingestion doesn't leverage incremental processing; it would either duplicate or overwrite data and doesn't provide differential processing.
E is Incorrect: CloudWatch Events (or EventBridge) cannot directly trigger batch transform jobs for document embedding. Batch transform is for model inference on tabular/data records, not for knowledge base document indexing.

Key Takeaway: Bedrock Knowledge Bases StartIngestionJob performs incremental ingestion automatically—use it for updates rather than rebuilding the entire index from scratch.