AWS ML Engineer Associate Prep Series — Part 2

SageMaker Core Workflows: Studio, Training, Algorithms, Script Mode, and Processing

Part 1 covered the data foundation, S3, storage, streaming, and feature engineering. If you haven't read it yet, I'd start there, because the SageMaker concepts here land better when you already understand how data gets into the system in the first place.

Now it's time to move into SageMaker itself. If the exam is a house, Part 1 was the foundation, and Part 2 is the framing, the parts that give the whole structure its shape.

This post walks through five SageMaker topics that show up repeatedly in MLA-C01 scenarios: the development environment (Studio vs notebook instances), training jobs, built-in algorithms, Script Mode, and processing jobs. Getting these five right makes the rest of the exam, tuning, deployment, and MLOps, much easier to reason about. They all build on each other.

1) SageMaker Studio vs Classic Notebook Instances

This one tripped me up early, mostly because I kept thinking of them as interchangeable. They're not. They solve different problems, and the exam is very deliberate about which scenario calls for which.

Classic notebook instances

The original SageMaker development environment. You provision a single EC2 instance with a Jupyter server pre-installed, connect via the AWS console, and work in isolation.

• Pre-installed with ML frameworks (TensorFlow, PyTorch, MXNet, Scikit-Learn)
• Your IAM role grants access to S3, ECR, and other services
• Kernel-based: you pick a kernel per notebook (Python 3, Spark, etc.)
• Data persists on the attached EBS volume
• Simple, predictable, and easy to reason about

The main limitation is the word "isolation" in that last paragraph. Each instance is a single user environment. There's no built-in collaboration, no shared file system across users, and no integrated visual debugging. It's a solid tool when one engineer needs one environment. It starts to feel limiting the moment you add a second person.

SageMaker Studio

Studio is the next-generation IDE purpose-built for ML. It runs on a shared architecture built around SageMaker domains and user profiles, and once you understand that model, the rest of Studio makes sense.

Key architectural differences:

• Domains organize users, apps, and resources under a shared EFS volume
• User profiles own personal apps and a private EFS directory, with shared spaces for team collaboration
• Apps are managed individually — Studio instances, notebooks, terminals, and Data Wrangler flows each run as separate apps within the same domain
• VPC models: by default, Studio uses a managed VPC for internet access and your own VPC for encrypted traffic to EFS. You can also configure "VPC Only" mode to route all traffic through your VPC, relevant for stricter enterprise network requirements
  

Exam instinct: if the question describes a team of data scientists who need to share notebooks, track experiments collaboratively, or use Data Wrangler and Pipelines visually, that's Studio. If the scenario is a single engineer running an isolated analysis on a predetermined instance type, a notebook instance is simpler, and that's the right call. The exam usually makes the collaboration signal pretty obvious.

2) Training Jobs — The Engine of SageMaker

A training job is the fundamental unit of model training in SageMaker. Whether you use a built-in algorithm, a framework estimator, or your own Docker container, the training job abstraction is the same underneath. Understanding this lifecycle well is worth your time; it shows up in scenario questions more than you'd expect.

Anatomy of a training job

When you call estimator.fit(), SageMaker runs through a predictable sequence:

1. Retrieves your training code from ECR (or uses a built-in algorithm image)
2. Provisions the specified EC2 instances (CPU or GPU)
3. Copies training data from your S3 input channels to the local training environment
4. Sets environment variables for your training script to consume
5. Runs your training code
6. Saves model artifacts from SM_MODEL_DIR back to your output S3 bucket
7. Terminates the instances

Step 7 is worth internalizing: the instances go away when the job ends. This is why SM_MODEL_DIR matters — anything you don't explicitly save there is gone.

Key components

• Estimator: the SageMaker SDK object that encapsulates your training configuration (image, instance type, hyperparameters, IAM role, output path)
• Instance type: CPU (ml.m5, ml.c5), GPU (ml.p3, ml.p4, ml.g5), or AWS Trainium (ml.trn1)
• Data channels: named input sources (typically train and validation) pointing to S3 locations
• Hyperparameters: passed as a dictionary to the estimator, received as command line arguments by your script
• Environment variables: SM_MODEL_DIR (where to save artifacts), SM_CHANNEL_TRAINING (path to training data), SM_NUM_GPUS, SM_CURRENT_HOST

Input modes for training data

This is one of those areas where the exam asks questions that seem simple but require knowing the exact trade-off between each mode:

• File mode (default): copies data from S3 to the local instance disk before training starts. Simple but incurs a download wait, at scale, that wait matters.
• Fast File mode: streams data from S3 on demand, letting training begin without a full download. Best for sequential access patterns.
• Pipe mode: streams data directly from S3 as a FIFO pipe. Lowest latency to start, but it restricts random access.
• FSx for Lustre: mounts an S3 bucket as a high-performance file system. Scales to hundreds of GB/s throughput with low latency. Requires VPC configuration, and if you read Part 1, you'll recognize this from the storage section.
• EFS: mounts an existing EFS file system. Requires data to already be in EFS and VPC access configured.

Local mode for testing

Setting instance_type='local' runs your training script on the notebook instance itself instead of provisioning remote infrastructure. This sounds minor, but it's genuinely useful: catch import errors, shape mismatches, and path issues before you burn GPU hours on a remote job. It's the kind of habit that saves hours in practice.

Quick gut check: Your training job needs to start processing data immediately without waiting for a full S3 download, but your algorithm requires random access to individual records. Which input mode? Fast File mode. It streams data on demand without requiring a full download, unlike basic File mode, and still supports random access, unlike Pipe mode, which rules it out the moment you need non-sequential reads.

3) Built-in Algorithms — Quick Reference

SageMaker ships with over a dozen built-in algorithms optimized for distributed training. They're a fast path to a strong baseline for common problem types, and they remove a lot of infrastructure overhead when the problem fits.

When to use built-in algorithms

There's a mental model I keep coming back to here: built-in algorithms exist to skip the "write infrastructure to train a known problem type" step. Use them when:

• You have a well-understood problem type (classification, regression, forecasting, anomaly detection)
• You want a quick, reliable baseline before investing in a custom model
• Your dataset fits the algorithm's expected input format
• You want distributed training without writing distributed code

Algorithm reference for the exam

The exam doesn't ask you to implement these; it asks you to pick the right one for a described scenario. The most tested mappings are XGBoost for tabular data, DeepAR for time series, RCF for anomaly detection, and BlazingText for text classification. Know those four cold.

One thing worth remembering: Random Cut Forest appears three times across the AWS ecosystem: SageMaker (as a training algorithm), QuickSight (as a dashboard anomaly feature), and Managed Service for Apache Flink (as a built-in SQL function). If a question is about anomaly detection on AWS and doesn't lock you into a specific service, RCF is usually where to start.

Exam instinct: when a scenario describes a specific problem type, forecasting store sales → DeepAR, detecting credit card fraud → RCF, classifying news articles → BlazingText, map it to the matching algorithm first, then worry about instance types and hyperparameters.

4) Script Mode — Your Code, Their Containers

Script Mode is the bridge between built-in algorithms and fully custom Docker containers. You write your own training script, and SageMaker runs it inside a managed framework container. It's the option I'd reach for most often in practice.

How it works

Instead of using a built-in algorithm estimator, you use a framework estimator (TensorFlow, PyTorch, XGBoost) and point it at your training script:

from sagemaker.tensorflow import TensorFlow

estimator = TensorFlow(
    entry_point='train.py',
    source_dir='./src',
    instance_type='ml.p3.2xlarge',
    instance_count=1,
    framework_version='2.12',
    py_version='py39',
    hyperparameters={
        'epochs': 10,
        'batch-size': 32,
        'learning-rate': 0.001
    }
)

estimator.fit({'training': 's3://my-bucket/training-data'})

The training script contract

Your script follows a predictable pattern, and once you've seen it once, it becomes second nature:

1. Import SageMaker environment variables — SM_MODEL_DIR for saving, SM_CHANNEL_* for input paths
2. Parse hyperparameters — via argparse, matching the keys in the estimator's hyperparameters dict
3. Load data — from the path provided by SM_CHANNEL_TRAINING (or whatever channel name you used)
4. Train the model — using your framework of choice
5. Save the model — to SM_MODEL_DIR

This pattern shows up repeatedly across exam questions and labs, so it's worth getting fluent with it rather than just recognizing it.

When Script Mode shines

• You need custom architecture or loss functions that built-in algorithms can't express
• You want SageMaker's managed infrastructure (automatic provisioning, artifact upload, distributed training) without being locked into a fixed algorithm
• You're porting an existing training script to SageMaker with minimal changes; this last one is probably the most common real-world case

The mental model I use: if your training logic already exists in a script and you just want SageMaker to run it at scale, Script Mode is almost always the right answer. You only need a fully custom Docker container if you have unusual system-level dependencies that aren't covered by the managed framework images.

Quick gut check: Your team has a working PyTorch training script for a custom transformer model. You need to run it on SageMaker with GPU instances and automatic model artifact upload to S3. Built-in algorithm, Script Mode, or custom container? Script Mode with the PyTorch estimator. It wraps your existing script with minimal changes while giving you full SageMaker infrastructure benefits. Custom container is overkill unless you have unusual system dependencies that the managed image can't satisfy.

5) Processing Jobs — Preprocessing and Beyond

Processing jobs extend SageMaker's managed infrastructure beyond training. They run scripts for data preprocessing, feature engineering, model evaluation, or postprocessing, all on fully managed containers, with no infrastructure to babysit.

This is the component people tend to underestimate. In a well-designed ML pipeline, preprocessing logic deserves the same treatment as training logic: versioned, reproducible, tracked. Processing jobs gives you that without extra complexity.

Processing vs Training Jobs

Processing jobs use a Processor instead of an Estimator, but the operational model is similar: provision instances, run your code, save outputs to S3, tear down. The key difference is what you're doing and where the output goes:

Using Processing Jobs

from sagemaker.sklearn.processing import SKLearnProcessor
from sagemaker.processing import ProcessingInput, ProcessingOutput

processor = SKLearnProcessor(
    framework_version='1.0',
    role=role,
    instance_type='ml.m5.large',
    instance_count=1
)

processor.run(
    code='preprocess.py',
    inputs=[ProcessingInput(
        source='s3://my-bucket/raw-data',
        destination='/opt/ml/processing/input'
    )],
    outputs=[ProcessingOutput(
        source='/opt/ml/processing/output',
        destination='s3://my-bucket/processed-data'
    )]
)

Processing jobs accept both built-in containers (SKLearn, Spark) and custom Docker images. They're also the standard way to add data transformation steps to SageMaker Pipelines — and when you get to the MLOps material, you'll see them show up as ProcessingStep objects inside pipeline definitions.

Common use cases

• Feature engineering: normalization, encoding, imputation at scale
• Data validation: compute statistics, detect drift before training
• Model evaluation: run a trained model against a test set, compute metrics, compare against thresholds
• Postprocessing: format predictions, join with metadata, prepare for downstream systems

Quick gut check: You need to run a Scikit-Learn preprocessing script that normalizes features and splits data into train/validation/test sets before training. The output should be stored in S3 and tracked as a pipeline artifact. Processing Job or Training Job? Processing Job. This is pure data transformation with no model training involved. The SKLearnProcessor gives you a managed container for exactly this, and the outputs land in S3 as proper pipeline artifacts.

Putting It All Together

Here's how these five components connect in practice, and in the exam scenarios that test architectural judgment:

A data scientist starts in SageMaker Studio, exploring data in a notebook and prototyping transformations. The shared EFS volume means teammates can see the same files and experiment results without setting up separate environments.

Once the exploration phase is done, the transformation logic gets formalized into a Processing Job, isolated, reproducible, and tracked as a pipeline step. This is where the ad-hoc notebook work becomes something you'd actually trust in production.

Before investing in a custom model, the team runs a quick baseline using a built-in algorithm like XGBoost. One of the things I've appreciated about studying this: built-in algorithms aren't a shortcut to avoid learning, they're a smart first step before writing custom code.

When the baseline falls short, the team writes a custom model in PyTorch and trains it via Script Mode on GPU instances. The existing training script ports over with minimal changes, and SageMaker handles provisioning, artifact upload, and teardown.

After training, another Processing Job runs model evaluation, computing accuracy, precision, and recall on a held-out test set and storing the results as a pipeline artifact. Deployment comes next, which I'll cover in a later post.

Each component plays a specific role, and the exam tests whether you know the boundaries: when to use a built-in algorithm vs Script Mode, when to use a Processing Job vs a Training Job, when Studio's overhead is worth it vs when a notebook instance is simply the right tool.

What to remember for the exam

1. Studio vs notebook instances: Studio is for teams, collaboration, shared EFS, and integrated tooling. Notebook instances are simpler, single-user, and sufficient for isolated work. Match the tool to the collaboration requirement in the scenario.
2. Training jobs: understand the lifecycle (Estimator → fit → provisioning → training → artifacts → teardown), the input mode trade-offs (File, Fast File, Pipe, FSx, EFS), and the environment variables (SM_MODEL_DIR, SM_CHANNEL_*, SM_NUM_GPUS). Step 7, instance teardown, is what makes SM_MODEL_DIR non-optional.
3. Built-in algorithms: know the algorithm-to-problem-type mapping cold (DeepAR for forecasting, RCF for anomaly detection, XGBoost for tabular, BlazingText for text classification) and which algorithms are GPU vs CPU. RCF in particular keeps showing up across services.
4. Script Mode: lets you bring custom training code while using SageMaker's managed framework containers. The script contract (argparse + env vars + SM_MODEL_DIR) is a recurring pattern in both exam questions and lab exercises.
5. Processing jobs: the managed way to run data transformation, evaluation, and postprocessing code. Use SKLearnProcessor or SparkProcessor for common cases, and remember they output to arbitrary S3 paths, not to SM_MODEL_DIR.

Practice questions

Work through these before moving to Part 3. The goal isn't to look up the answer, it's to reason through the trade-off and explain why:

1. A team of five ML engineers needs to collaborate on feature-engineering notebooks, share experimental results, and run SageMaker Pipelines, all within a single domain. Should they use Studio or notebook instances? What's the deciding factor?
2. Your training job's data is 500 GB of Parquet files in S3. The algorithm needs sequential access. You want training to start within seconds of job launch without waiting for a full download. Which input mode fits, and which would you rule out first?
3. An exam scenario describes detecting fraudulent transactions in real-time credit card data. Which SageMaker built-in algorithm is the best fit, and where else does the same algorithm appear in the AWS ecosystem?
4. You have an existing TensorFlow training script with custom layers. You want to run it on SageMaker with automatic GPU provisioning and artifact upload, but with minimal code changes. Built-in algorithm, Script Mode, or custom Docker container, and what would tip you toward the custom container instead?
5. Your pipeline needs a step that computes evaluation metrics (accuracy, precision, recall) on a held-out test set after training completes. Results should be stored in S3 and registered as a pipeline artifact. Which SageMaker component handles this, and which pipeline step type does it become?

Closing

The theme I keep coming back to while studying this section is that SageMaker is not a single tool; it's a set of clearly scoped components that fit together. Studio for environment, Processing Jobs for transformation, Training Jobs for model fitting, built-in algorithms, or Script Mode, depending on how custom your logic needs to be.

Once you see each piece as filling a specific role, the exam questions that ask "which component handles this" become much more approachable. The architecture makes sense when you stop thinking of SageMaker as one thing.

Part 3 will go into hyperparameter tuning, model deployment, and inference patterns, the parts of the pipeline that come after training, and where a lot of real-world decisions get made.