Many wrong answers on MLA-C01 come not from not knowing a concept but from picking the similar service instead. There are four or five data preparation tools alone, the tools for looking inside a model split into Clarify, Debugger, and Model Monitor, and there are several inference options and endpoint configurations. When two options appear as a pair, such as Data Wrangler and Glue DataBrew, knowing each definition is not enough; you need to be able to state in one sentence the criterion that separates them.
This post is the review installment of the MLA-C01 study series. From the services explained separately in the domain posts, it picks only the groups that often show up as each other's wrong answers and reorganizes them by the criteria that separate them and the clue phrases in questions. At the end it also collects the services and features that were renamed or closed to new sign-ups.
---
Three Questions That Separate Confusing Services
When you meet two similar services, asking the following three questions in order settles most cases.
| Question | What it separates | Example | |------|------|------| | When is it used? | The stage of the ML lifecycle (before, during, or after training) | Clarify for bias before and after training, Debugger during training, Model Monitor after deployment | | Who writes the code? | No-code tools vs. code-based tools | DataBrew with clicks, Glue ETL with Spark code | | How fast, and how big? | Real time vs. batch, size and latency | Real-time endpoints answer immediately, batch transform handles large volumes at once |
---
Domain 1: Confusing Pairs in Data Preparation
Data Wrangler vs. Glue DataBrew vs. Glue ETL vs. SageMaker Processing
| Aspect | Data Wrangler | Glue DataBrew | Glue ETL | SageMaker Processing | |------|------|------|------|------| | Approach | Visual ML data preparation (now inside SageMaker Canvas) | No-code data cleaning and normalization | Serverless Spark code ETL | Runs your own scripts in managed containers | | Main users | ML practitioners | Analysts and data preparation staff | Data engineers | ML engineers | | Clue in the question | "build ML features visually and go straight to training" | "clean data quality without code" | "transform many sources at scale, Data Catalog" | "a preprocessing or evaluation step inside a SageMaker pipeline" |
When you need to control large Spark or Hadoop clusters directly or cut costs with Spot Instances, the answer is Amazon EMR.
!Spectrum of data preparation tools from no-code Data Wrangler and DataBrew to Glue ETL, SageMaker Processing, and EMR
How Training Reads Data: File, FastFile, and Pipe Modes, FSx for Lustre, and EFS
| Method | Characteristics | Clue in the question | |------|------|------| | S3 File mode | Copies all the data to the instance before training starts | Small data, the default | | S3 FastFile mode | Looks like files but reads from S3 on demand, so training starts quickly | Large data, fast start without code changes | | S3 Pipe mode | Reads from S3 as a stream | The older approach, now largely replaced by FastFile | | FSx for Lustre | High-performance parallel file system linked to S3 | Large distributed training, fast repeated reads of the same data over many epochs | | EFS | File system shared by several instances | The data is already in EFS |
Feature Store Online Store vs. Offline Store
The online store is for inference and reads the latest feature values in milliseconds, while the offline store is for training and keeps the full history in S3. Writing the same features to both keeps training and serving features consistent.
Related posts: Data Ingestion and Storage, Streaming and Event-Driven ML Pipelines, Feature Engineering and Data Quality
---
Domain 2: Confusing Pairs in Model Development
JumpStart vs. Bedrock vs. Autopilot (Canvas) vs. Built-In Algorithms
| Aspect | SageMaker JumpStart | Amazon Bedrock | Autopilot (Canvas) | Built-in algorithms | |------|------|------|------|------| | Core | Deploy and fine-tune pre-trained models and solutions in your own SageMaker environment | Use and customize foundation models through a serverless API | Give it data and it searches for and trains models automatically (AutoML) | Train directly with algorithms such as XGBoost | | Infrastructure management | Choose and manage endpoint instances | None | Almost none | Choose training and deployment instances | | Clue in the question | "an open model on instances in our VPC" | "a generative AI API with no infrastructure" | "the best model from tabular data without ML specialists" | "control the algorithm and hyperparameters directly" |
Clarify vs. Debugger vs. Model Monitor vs. MLflow
| Aspect | Clarify | Debugger | Model Monitor | MLflow (formerly Experiments) | |------|------|------|------|------| | When | Before and after training | During training | After deployment | While experimenting | | What it does | Bias metrics, SHAP explanations | Watches tensors and loss, detects convergence problems, stops automatically | Data quality, model quality, bias, and feature attribution drift | Records and compares parameters, metrics, and artifacts of experiments | | Clue in the question | "fairness," "which feature influenced it" | "vanishing gradients," "the loss is not decreasing" | "the input distribution changed in production" | "reproduce and compare several experiments" |
Clarify, Debugger, and Model Monitor have not accepted new customers since July 30, 2026, but on MLA-C01 they are still the answers for these situations.
Model Registry vs. MLflow Experiment Tracking, Ground Truth vs. A2I
The model registry manages the versions and approval status of models to be deployed, while experiment tracking records which settings produced which results. Ground Truth labels data before training, and A2I has people review results after inference.
Related posts: Choosing Modeling Approaches, Choosing AWS AI Services, Evaluation Metrics in Practice and Handling Class Imbalance
---
Domain 3: Confusing Pairs in Deployment and Orchestration
Real-Time vs. Serverless vs. Asynchronous vs. Batch Transform
| Aspect | Real-time | Serverless | Asynchronous | Batch transform | |------|------|------|------|------| | Payload and processing time | Up to 25 MB, 60 seconds | Up to 4 MB, 60 seconds | Up to 1 GB, 1 hour | Datasets in the GBs, even days | | Scale to zero | No (yes with inference components) | Automatic | Yes | Instances end when the job finishes | | Clue in the question | "millisecond responses, steady traffic" | "intermittent traffic, cold starts acceptable" | "large files, minutes of processing, a queue" | "score all the data every night" |
Multi-Model vs. Multi-Container vs. Inference Pipeline vs. Inference Components
| Aspect | What it does | Clue in the question | |------|------|------| | Multi-model endpoint (MME) | Keeps thousands of models of the same framework on one endpoint and loads them into memory when invoked | "thousands of per-customer models, lower cost, first-call latency acceptable" | | Multi-container endpoint | Invokes several containers of different frameworks individually on one endpoint | "a TensorFlow model and a PyTorch model on one endpoint" | | Inference pipeline | Runs 2–15 containers in sequence (preprocessing → model → postprocessing) | "apply exactly the same preprocessing at inference as in training" | | Inference components | Assigns resources to several models on one endpoint separately and scales them separately | "split CPU and memory per model and scale down to zero" |
Deployment Strategies: Blue/Green, Canary, Linear, Shadow, and A/B
Blue/green builds a new environment and shifts traffic to it, canary sends a small share first and then shifts everything, and linear shifts traffic in equal steps. All three can roll back automatically on CloudWatch alarms. Shadow testing evaluates a new model without serving its responses to users, and A/B testing splits traffic by production variant weights to compare real results.
Orchestration: SageMaker Pipelines vs. Step Functions vs. MWAA vs. CodePipeline
SageMaker Pipelines is for workflows made only of ML steps, Step Functions for general flows that tie together many AWS services, MWAA for existing Airflow DAGs, and CodePipeline for CI/CD that starts from a code change (source → build → test → deploy).
Related posts: Deployment Infrastructure and Scaling Strategies, SageMaker Endpoint Auto Scaling Deep Dive and Choosing a Deployment Target, Building MLOps and CI/CD Pipelines
---
Domain 4: Confusing Pairs in Monitoring, Cost, and Security
CloudWatch vs. CloudTrail vs. X-Ray vs. AWS Config
| Tool | Question it answers | |------|------| | CloudWatch | Is performance normal right now? (metrics, logs, alarms, dashboards) | | CloudTrail | Who called which API, and when? | | X-Ray | Where did a request slow down as it passed through several services? | | AWS Config | Do resource configurations follow the rules? |
Cost Explorer vs. Budgets vs. Trusted Advisor vs. Compute Optimizer vs. Inference Recommender
| Tool | What it does | |------|------| | Cost Explorer | Analyzes past costs by service and tag and forecasts future costs | | AWS Budgets | Sets budgets and alerts when they are exceeded or forecast to be exceeded | | Trusted Advisor | Checks cost optimization, security, performance, service quotas, and more against best practices | | Compute Optimizer | Recommends rightsizing for resources such as EC2, Lambda, and ECS (Fargate) based on utilization | | Inference Recommender | Recommends instance types for SageMaker endpoints through load tests |
Macie vs. Comprehend PII vs. Secrets Manager
Macie finds sensitive data in S3 objects, Comprehend PII detects and masks personal data inside text, and Secrets Manager stores passwords and API keys and rotates them automatically.
Related posts: Model Monitoring, Cost Optimization, and Security, ML Security Deep