Skill 2.2.2: Configure SageMaker AI script mode with supported frameworks for simplicity and performance

Question	Answer & Explanation
### Question 1 - SageMaker AI Script Mode vs. Bring Your Own Container (BYOC) A data science team has written a custom PyTorch training script to train a computer vision model. The script uses standard PyTorch libraries and does not require any external dependencies outside of the base PyTorch environment. The team wants to run this script as a managed SageMaker AI training job with the least operational overhead and wishes to avoid maintaining Docker images. Which approach should the team use to configure the training job? - A) Build a custom Docker container with PyTorch installed, push it to Amazon ECR, and use a `sagemaker.estimator.Estimator` to point to the ECR image. - B) Use the `sagemaker.pytorch.PyTorch` estimator, provide the Python script as the `entry_point`, and rely on the AWS-maintained PyTorch Deep Learning Container (DLC). - C) Use the SageMaker AI built-in Image Classification algorithm and pass the custom PyTorch script as a hyperparameter. - D) Use an AWS Lambda function to execute the PyTorch script on an AWS Fargate container to avoid managing EC2 instances. (Select ONE)	Correct Answer: B Correct Option Analysis: - B is Correct: Using the `PyTorch` estimator in SageMaker AI Script Mode allows you to supply your custom Python script via the `entry_point` parameter. SageMaker automatically pulls a pre-built, AWS-managed Deep Learning Container (DLC) that matches your specified framework version, injects your script, and executes it. This completely removes the need to write Dockerfiles or manage container registries. Distractor Analysis: - A is Incorrect: Building a custom Docker container (BYOC) requires writing Dockerfiles, maintaining base images, and pushing to ECR. This violates the constraint of avoiding Docker image maintenance and introduces high operational overhead. - C is Incorrect: SageMaker AI built-in algorithms (like Image Classification) come with pre-packaged training logic. You cannot inject a custom PyTorch training script into a built-in algorithm. - D is Incorrect: AWS Lambda and Fargate are not designed for long-running, compute-intensive GPU training jobs. SageMaker AI is the native service for managed ML training. > Key Takeaway: Script Mode combines custom training logic (your script) with managed infrastructure (AWS Deep Learning Containers), eliminating the need for BYOC when using supported frameworks like PyTorch and TensorFlow.
### Question 2 - Adding Custom Dependencies in Script Mode An ML engineering team is running a TensorFlow training script in SageMaker AI Script Mode. The script requires a specific external Python library (`texttable`) that is not included in the standard AWS TensorFlow Deep Learning Container. The team must deploy this dependency with the lowest operational overhead and without building a custom container image. Which configuration fulfills these requirements? - A) Create a `requirements.txt` file listing `texttable`, place it in the same S3 directory as the entry point script, and specify this directory in the `source_dir` parameter of the TensorFlow estimator. - B) Use the `subprocess` module inside the training script to run `pip install texttable` at the start of the training loop. - C) Build a custom Docker image extending the TensorFlow DLC, install `texttable`, and push it to Amazon ECR. - D) Package the `texttable` library source code into an AWS Lambda layer and attach it to the SageMaker training job. (Select ONE)	Correct Answer: A Correct Option Analysis: - A is Correct: In SageMaker AI Script Mode, if you provide a `requirements.txt` file in the same directory as your `entry_point` script (specified via `source_dir`), SageMaker will automatically run `pip install -r requirements.txt` inside the managed container before executing your training script. This is the simplest, code-free way to add external dependencies without BYOC. Distractor Analysis: - B is Incorrect: While running `subprocess.run(['pip', 'install', 'texttable'])` in the script works, it is an anti-pattern, introduces unnecessary code overhead, and slows down the start of every training job. `requirements.txt` is the native, supported method. - C is Incorrect: Building a custom Docker image violates the constraint of avoiding custom container images and introduces unnecessary operational overhead. - D is Incorrect: AWS Lambda layers are for serverless functions, not SageMaker AI training containers. SageMaker does not support attaching Lambda layers to training jobs. > Key Takeaway: To add Python dependencies in Script Mode without building a custom container, include a `requirements.txt` file alongside your training script in the `source_dir`.
### Question 3 - Passing Hyperparameters in Script Mode A machine learning engineer is configuring a Scikit-Learn training script to run in SageMaker AI Script Mode. The estimator passes hyperparameters such as `learning_rate` and `n_estimators`. The script must retrieve these values seamlessly within the Python code with the least amount of custom parsing logic. How should the training script access these hyperparameters? - A) Use the `boto3` client to call the `DescribeTrainingJob` API and parse the hyperparameters from the JSON response. - B) Read the hyperparameters from a JSON file located at `/opt/ml/input/config/hyperparameters.json` using standard Python file I/O. - C) Access them as environment variables prefixed with `SM_HP_` (e.g., `os.environ['SM_HP_learning_rate']`). - D) Pass the hyperparameters into the script via command-line arguments and parse them using `argparse`. (Select TWO that are applicable)	Correct Answer: C and D Correct Option Analysis: - C is Correct: SageMaker AI automatically exposes all hyperparameters passed to the estimator as environment variables inside the container, prefixed with `SM_HP_`. This allows direct access without any file parsing. - D is Correct: The standard and most robust approach supported by SageMaker's Script Mode documentation is to pass the hyperparameters as command-line arguments to the entry point script and parse them using Python's `argparse` library. SageMaker handles the injection of these arguments automatically. Distractor Analysis: - A is Incorrect: Using the `boto3` API to describe the training job from within the job itself is an unnecessary, high-overhead anti-pattern that requires IAM permissions and network calls. - B is Incorrect: While SageMaker does write hyperparameters to `/opt/ml/input/config/hyperparameters.json`, standard Script Mode abstracts this away by directly providing them as command-line arguments or environment variables, making manual JSON file I/O unnecessary overhead. > Key Takeaway: SageMaker passes hyperparameters to Script Mode either as command-line arguments (parsed via `argparse`) or as environment variables prefixed with `SM_HP_`.
### Question 4 - Tracking Custom Metrics in CloudWatch A team is running a custom PyTorch training script in SageMaker AI Script Mode. The script prints the output `Validation Loss: 0.15` to standard output (`stdout`) during the evaluation phase. The team needs to visualize this validation loss curve in the SageMaker console and CloudWatch with minimal infrastructure changes. Which TWO actions must the team take to achieve this? (Select TWO) - A) Configure the `metric_definitions` parameter in the `PyTorch` estimator with a regular expression that extracts the numerical value from `Validation Loss: 0.15`. - B) Modify the training script to use the `boto3` client to push custom metrics to CloudWatch using `put_metric_data`. - C) Ensure the training script prints the metric string (e.g., `Validation Loss: 0.15`) to `stdout` or `stderr`. - D) Save the loss values to a CSV file in `/opt/ml/output/metrics.csv` and configure SageMaker to parse it. - E) Enable SageMaker Debugger and configure a custom rule to extract the loss metric. (Select TWO)	Correct Answer: A and C Correct Option Analysis: - A is Correct: By defining a regex pattern in the `metric_definitions` parameter of the estimator (e.g., `{'Name': 'validation:loss', 'Regex': 'Validation Loss: ([0-9\\.]+)'}`), SageMaker will automatically parse the console output and emit the metric to CloudWatch. - C is Correct: SageMaker Script Mode natively streams all standard output (`stdout`) and standard error (`stderr`) to CloudWatch Logs. The metric definitions rely on this text stream to extract the values. Distractor Analysis: - B is Incorrect: Using `boto3` to manually push metrics introduces unnecessary code complexity and requires IAM permissions. SageMaker natively handles metric parsing from stdout via regex. - D is Incorrect: SageMaker does not automatically parse CSV files from the output directory for metrics. It uses stdout/stderr and regex. - E is Incorrect: While SageMaker Debugger can capture metrics, it requires more setup and is overkill for simply parsing a printed loss string. Regex metric definitions are the simplest native method. > Key Takeaway: To track custom metrics in SageMaker Script Mode, simply print them to `stdout` and define a regex pattern in the `metric_definitions` parameter of the estimator.
### Question 5 - Accessing Input Data Channels A training script running in SageMaker AI Script Mode requires access to the training dataset. The dataset is stored in Amazon S3 and passed to the estimator via the `inputs` parameter (e.g., `inputs={'train': 's3://bucket/train'}`). The script needs to locate this data on the local container filesystem dynamically, without hardcoding paths. Which environment variable should the script reference to find the local path for the 'train' channel? - A) `SM_INPUT_DIR` - B) `SM_CHANNEL_TRAIN` - C) `SM_MODULE_DIR` - D) `S3_TRAIN_BUCKET` (Select ONE)	Correct Answer: B Correct Option Analysis: - B is Correct: SageMaker AI automatically downloads data from the specified S3 URI to the local container before the training script begins. For a channel named `train`, the local path is exposed via the `SM_CHANNEL_TRAIN` environment variable (typically pointing to `/opt/ml/input/data/train`). Distractor Analysis: - A is Incorrect: `SM_INPUT_DIR` points to the parent directory `/opt/ml/input`, but it does not specify the specific subdirectory for the 'train' data channel. - C is Incorrect: `SM_MODULE_DIR` points to the directory where the training script itself is stored, not the input data. - D is Incorrect: `S3_TRAIN_BUCKET` is not a standard SageMaker environment variable. SageMaker abstracts the S3 bucket away and provides local file paths instead. > Key Takeaway: SageMaker downloads input channels to local paths accessible via environment variables named `SM_CHANNEL_<CHANNEL_NAME>` (e.g., `SM_CHANNEL_TRAIN`).
### Question 6 - Saving Model Artifacts for Deployment A data scientist has completed a custom training script using SageMaker AI Script Mode with the Hugging Face `Transformer` class. The script successfully trains the model and saves the weights. The team needs to deploy this model to a SageMaker AI real-time endpoint with the least operational overhead. Where inside the training container must the script save the serialized model artifact (e.g., `model.tar.gz`) so that SageMaker AI automatically uploads it to S3 for hosting? - A) `/opt/ml/model/` - B) `/opt/ml/output/` - C) `/opt/ml/input/data/` - D) `/opt/ml/checkpoints/` (Select ONE)	Correct Answer: A Correct Option Analysis: - A is Correct: SageMaker AI automatically captures the contents of the `/opt/ml/model/` directory at the end of the training job, compresses it into a `model.tar.gz` file, and uploads it to the S3 output path specified in the estimator. This artifact is then used directly to create a model package for deployment. Distractor Analysis: - B is Incorrect: `/opt/ml/output/` is used for writing artifacts like the failure reason or metric data, not the final model artifact for deployment. - C is Incorrect: `/opt/ml/input/data/` is where SageMaker downloads the input training and validation data channels. - D is Incorrect: `/opt/ml/checkpoints/` is used for saving intermediate training states for spot instance interruption recovery, not the final model artifact. > Key Takeaway: To ensure SageMaker captures and uploads your trained model for deployment, always save the serialized model files to the `/opt/ml/model/` directory in your training script.
### Question 7 - Enabling Distributed Training in Script Mode An AI team is training a large language model using a custom PyTorch script in SageMaker AI Script Mode. The model fits in the memory of a single GPU, but the dataset is massive, and training takes weeks on a single instance. The team needs to reduce training time with the least amount of code rewrite to their training loop. Which configuration should the team implement? - A) Build a custom Docker container with MPI and Horovod pre-configured, and manually update the training script to use MPI primitives. - B) Configure the `distribution` parameter in the `PyTorch` estimator to use `smdistributed` with `dataparallel` enabled. - C) Use SageMaker AI Automatic Model Tuning (AMT) to run multiple training jobs in parallel across different instances. - D) Save intermediate weights to S3 after every epoch and use an AWS Step Functions state machine to trigger sequential jobs on new instances. (Select ONE)	Correct Answer: B Correct Option Analysis: - B is Correct: By setting `distribution={"smdistributed": {"dataparallel": {"enabled": True}}}` in the PyTorch estimator, SageMaker AI automatically handles the complex setup of distributed data parallelism across multiple instances. The AWS DLC comes pre-installed with the SageMaker Distributed Data Parallel (SMDDP) library, requiring minimal code changes (just initializing the SMDDP framework in the script) to split batches across workers. Distractor Analysis: - A is Incorrect: Building a custom MPI/Horovod container introduces heavy operational overhead. The SMDDP library is already available in AWS DLCs and is optimized for AWS network infrastructure, making it the simpler choice. - C is Incorrect: AMT (Hyperparameter tuning) runs multiple jobs to find the best hyperparameters; it does not parallelize a single training job to make it run faster. - D is Incorrect: Using Step Functions to manually orchestrate sequential epoch-based jobs introduces massive overhead and breaks the standard ML training loop. > Key Takeaway: To enable distributed data parallelism in Script Mode with minimal overhead, use the `smdistributed` configuration in the estimator, leveraging the pre-installed SMDDP library.
### Question 8 - Source Code from Git Repositories A machine learning team maintains their training scripts in a private GitHub repository. They want to run these scripts in SageMaker AI Script Mode directly from the repository without manually cloning the repo to a local machine and uploading it to S3 first. The solution must have the least operational overhead. Which configuration achieves this requirement? - A) Create an AWS CodePipeline that clones the GitHub repository, builds a custom Docker container, and pushes it to Amazon ECR for SageMaker to use. - B) Use the `git_config` parameter in the SageMaker AI estimator to specify the GitHub repository URL, branch, and commit hash, pointing to the training script as the entry point. - C) Configure an AWS Lambda function triggered by GitHub Webhooks to clone the repository, package it, and send it to the SageMaker AI API. - D) Manually download the ZIP file from GitHub, extract it locally, and pass the local directory path to the `source_dir` parameter. (Select ONE)	Correct Answer: B Correct Option Analysis: - B is Correct: SageMaker AI estimators natively support a `git_config` dictionary parameter where you can specify `repo_url`, `branch`, and `commit`. SageMaker will automatically clone the repository during the job setup phase and use the specified `entry_point` script, entirely eliminating the need for local cloning or custom CI/CD pipelines. Distractor Analysis: - A is Incorrect: Building a CI/CD pipeline to create custom containers violates the least overhead constraint and ignores the native Git integration capabilities of SageMaker AI Script Mode. - C is Incorrect: Using Lambda and Webhooks introduces significant operational overhead and custom orchestration that is natively handled by SageMaker. - D is Incorrect: Manually downloading and uploading the ZIP file requires local developer actions and does not meet the requirement of running directly from the repository with minimal overhead. > Key Takeaway: SageMaker AI Script Mode can natively fetch source code directly from Git repositories using the `git_config` parameter in the estimator.
### Question 9 - Built-in Algorithm vs. Script Mode for XGBoost A retail company wants to train an XGBoost model on a large tabular dataset stored in S3. They need to implement a custom evaluation metric that is not natively supported by the standard XGBoost algorithm output. The team wants to maintain simplicity and performance while avoiding the maintenance of a custom container image. Which approach should the ML engineer take? - A) Use the SageMaker AI built-in XGBoost algorithm and pass the custom metric as a hyperparameter JSON string. - B) Use the SageMaker AI built-in XGBoost algorithm container in Script Mode by providing a custom Python training script as the `entry_point`. - C) Build a custom Scikit-Learn container from scratch, install XGBoost manually, and execute it via `sagemaker.estimator.Estimator`. - D) Use Amazon Bedrock to fine-tune a foundation model, as it natively supports custom tabular evaluation metrics. (Select ONE)	Correct Answer: B Correct Option Analysis: - B is Correct: SageMaker AI provides a pre-built Docker container for XGBoost that can be used in Script Mode. By passing your own Python script as the `entry_point`, you can leverage the managed XGBoost environment but inject custom logic for data preprocessing or custom evaluation metrics, all without maintaining a custom container. Distractor Analysis: - A is Incorrect: The built-in XGBoost algorithm (when run without a custom script) only supports standard metrics defined in its hyperparameter configuration (like `rmse` or `error`). It does not support custom evaluation functions via hyperparameters. - C is Incorrect: Building a custom container introduces unnecessary operational overhead since AWS already maintains a DLC for XGBoost. - D is Incorrect: Amazon Bedrock is for customizing foundation models (LLMs), not for training gradient-boosted trees on tabular data. > Key Takeaway: For algorithms like XGBoost that have a supported framework container, Script Mode allows you to inject custom metrics or preprocessing logic while still using an AWS-managed container.
### Question 10 - Checkpointing with Managed Spot Training A team is running a long-running PyTorch training script in SageMaker AI Script Mode to reduce costs. They have configured the estimator to use Managed Spot Training. To ensure the training job can resume efficiently if interrupted by a spot instance reclaim, the script must save intermediate model states to a specific local directory that SageMaker automatically syncs to S3. Which local directory path should the script use for saving checkpoint files? - A) `/opt/ml/model/` - B) `/opt/ml/checkpoints/` - C) `/opt/ml/input/data/checkpoints/` - D) `/opt/ml/output/checkpoints/` (Select ONE)	Correct Answer: B Correct Option Analysis: - B is Correct: When `checkpoint_s3_uri` is configured in the SageMaker estimator, SageMaker automatically syncs the contents of the local `/opt/ml/checkpoints/` directory to the specified S3 bucket. If a spot interruption occurs, SageMaker downloads the latest checkpoint from S3 back to `/opt/ml/checkpoints/` when the job restarts, allowing the training script to resume from the last saved state. Distractor Analysis: - A is Incorrect: `/opt/ml/model/` is strictly for the final model artifact, which SageMaker packages and uploads only at the end of a successful training run. - C is Incorrect: `/opt/ml/input/data/` is for the input data channels (train, test, validation), not for saving intermediate checkpoints. - D is Incorrect: `/opt/ml/output/` is typically used for writing logs or failure reasons, not for automated checkpoint synchronization. > Key Takeaway: To leverage SageMaker's built-in checkpoint sync for Managed Spot Training, save intermediate model weights to the `/opt/ml/checkpoints/` directory in your Script Mode training loop.