Data Preparation for ML
Every question here asks which stage of the data pipeline owns the problem
A model is only as good as the data it sees, and getting that data ready runs as a pipeline in three stages: first you land the raw data somewhere the training job can read it, then you reshape it into features an algorithm understands, and finally you check that what you feed the model is correct, complete, and fair. Most questions in this domain are really asking which of those three stages owns the problem in front of you, and the classic trap dresses a transformation question up as a storage question, or hides a bias problem inside a cleaning task. Name the stage first, because the stage decides the small set of AWS services in play: a scan-heavy training read points at file format and input mode, a categorical column that must become numbers points at encoding, an under-represented group points at Amazon SageMaker Clarify. This is the largest domain on the exam at 28 percent, ahead of ML Model Development at 26 percent, so the stage-first instinct pays off here more than anywhere.
The domain unfolds in three steps: land it, shape it, then trust it
Read this page as a map, then follow the three subtopics in order. Data Ingestion & Storage lands the raw data: choosing a file format that matches the access pattern (columnar Parquet or ORC for wide scans, row-based Avro or JSON for streaming), a SageMaker input mode for how the dataset reaches the training instance, a storage backend from Amazon S3 to Amazon FSx for Lustre, and the right streaming service among Kinesis, Data Firehose, MSK, and Managed Service for Apache Flink. Data Transformation & Feature Engineering shapes that data into features: picking a transform tool by scale and skill (Data Wrangler, Glue DataBrew, AWS Glue, or Spark on Amazon EMR), encoding categoricals, scaling and imputing consistently, and serving those features through SageMaker Feature Store. Data Integrity & Preparation is the gate before training: quality and pre-training bias checks, rebalancing an imbalanced dataset, a clean train/validation/test split, and the compliance rules that decide where the data may live. Each subtopic carries the mechanisms, the numbers, and the traps; this overview only shows how they connect.
When two answers both work, keep the definition in one place and check before you train
The instinct this domain rewards is doing the cheap, correct thing early rather than the expensive fix later. Fit any statistic a transform learns, a scaler's mean and variance, an imputer's median, on training data and reuse it unchanged at inference, because refitting on serving data is training-serving skew, the silent accuracy killer that SageMaker Feature Store and Data Wrangler exist to prevent. In the same spirit, run data-quality and bias checks on the raw dataset before a single training job starts: a model trained on dirty or skewed data learns the dirt and the skew, and Clarify's pre-training metrics are model-agnostic precisely so you can run them up front. When two options both produce a working feature, prefer the one that defines the feature once and reuses it everywhere over the one that recomputes it per environment.
The three data-preparation stages (and where each is covered)
| Stage | Decides | Key AWS services | Drill into |
|---|---|---|---|
| Ingest & store | How raw data lands and reaches the training job | S3, FSx for Lustre, EFS; file vs fast-file vs Pipe mode; Kinesis, Data Firehose, MSK, Managed Flink; Parquet/ORC vs Avro/JSON | Data Ingestion & Storage |
| Transform & engineer | How data becomes model-ready features | Data Wrangler, Glue DataBrew, AWS Glue, Spark on EMR; encoding, scaling, imputation; SageMaker Feature Store | Data Transformation & Feature Engineering |
| Validate & prepare | Whether the data is correct, fair, and split | Glue Data Quality, SageMaker Clarify (CI, DPL); resampling and SMOTE; train/validation/test split; KMS, Macie | Data Integrity & Preparation |