MLA-C02 data preparation for ML and AI
Data Preparation for ML and AI is worth 28% of MLA-C02 — the largest domain. AWS frames the task as ingesting, transforming, validating and preparing data for AI and ML modelling.
Engineers arriving from a modelling background routinely underrate this. In practice most ML failures are data failures, and AWS has weighted the exam to reflect that.
Ingestion and storage
Getting data in, and choosing where it lives:
- The common AWS sources and how data arrives — batch versus streaming.
- Storage choices, and the cost and access trade-offs behind them.
- Data formats. Columnar formats compress well and read efficiently for analytics; row formats suit record-at-a-time access. Choosing the right one is a cost and performance decision the exam tests.
- Partitioning, so queries and training jobs read only what they need.
Transformation and cleaning
- Handling missing values, duplicates and outliers, and knowing that each choice is a modelling decision rather than housekeeping.
- Type conversion, normalisation and scaling.
- Joining and aggregating across sources.
- Doing this at scale, which is what distinguishes this exam from a data science course.
Feature engineering
- Creating features that carry signal, and encoding categorical variables.
- Storing and reusing features so training and inference compute them identically.
That last point matters more than it sounds: training/serving skew, where features are computed one way in training and another at inference, is a classic production failure and a natural exam scenario.
SageMaker Feature Store and Data Wrangler
The outline names two SageMaker AI components in this domain: objective 1.1.9 asks you to ingest data into SageMaker Feature Store, objective 1.2.2 to create and manage features with it, and objective 1.2.1 lists SageMaker Data Wrangler next to AWS Glue, Glue DataBrew and Spark on Amazon EMR as transformation tools.
Feature Store is the shared store that prevents the skew described above. Features live in a feature group. Every record needs a record identifier and an event time, and the two stores behave differently:
| Store | Keeps | Used for |
|---|---|---|
| Online store | Only the record with the latest event time per identifier | Low-latency lookups at inference, via GetRecord |
| Offline store (in your S3 bucket) | Every historical record | Exploration, training and batch inference |
Ingestion has three common routes: the PutRecord API, which takes records from streaming sources such as Kinesis or Kafka for fresh features; batch ingestion from Amazon EMR through the Feature Store Spark connector; and exporting a Data Wrangler flow to a feature group.
Data Wrangler is the low-code way to import, clean, transform, featurize and analyse data. In the current Studio it runs inside SageMaker Canvas (it used to be part of Studio Classic). It offers built-in transforms such as encoding and formatting, a data quality and insights report, and analyses including target leakage. A flow can be exported to S3 or Feature Store, or turned into a SageMaker Pipelines workflow so the same preparation runs on every retraining.
How to choose on the exam: Data Wrangler or DataBrew for visual, low-code preparation; Glue or Spark on EMR for large code-based ETL; Lambda or Spark for streaming transforms (1.2.3); Feature Store when features must be reused across teams or served identically to training and inference.
Exam pitfall: the online store keeps only the latest value per record, so it cannot rebuild a point-in-time training set. A question about creating training data from historical feature values points to the offline store. Equally, a real-time endpoint that needs a customer’s current features in milliseconds needs the online store; querying the offline store in S3 is too slow.
More on where Feature Store and Data Wrangler fit in the lifecycle is in the SageMaker AI components guide.
Validation and data quality
- Completeness, schema conformity, and detecting corrupt or anomalous data before it reaches training.
- Detecting bias in the dataset, including under-representation.
- Establishing a baseline so you can detect drift later.
Splitting data, and leakage
Training, validation and test sets, and why the split must reflect how the model will be used.
Data leakage is the concept most worth internalising. It occurs when information unavailable at prediction time reaches the training data — a column derived from the outcome, or a random split applied to time-series data so the model effectively sees the future. The signature is the same every time: excellent test performance, poor production performance. Any scenario with that shape is a leakage question.
Preparing data for foundation models
New in C02, and different from preparing training data:
- Content for retrieval is chunked and embedded rather than used to fit a model.
- Chunk size and overlap affect retrieval quality directly.
- Data for fine-tuning is example pairs demonstrating desired behaviour, and needs far less volume than training from scratch.
Sample questions
Question 1. A team trains a model on time-series sales data using a random 80/20 split. Test accuracy is excellent but production accuracy is poor. What is the most likely cause?
- A. A random split leaked future information; the data should be split chronologically
- B. The model needs more training epochs
- C. The inference endpoint is under-provisioned
- D. The test set is too small to be meaningful
Show answer
Answer: A
A random split on time-series data lets the model train on later periods and test on earlier ones, effectively seeing the future, which inflates test performance and collapses in production. Insufficient epochs and endpoint sizing would not produce strong test results, and an imbalanced test set would not systematically inflate accuracy this way.
Want more questions like this? Full MLA-C02 practice tests →
Question 2. Analytical queries over a very large training dataset are slow and expensive because each job reads every column. Which change most directly helps?
- A. Compress the existing row-based files
- B. Move the data to a larger instance type
- C. Convert to a partitioned columnar format
- D. Sample the data down to fewer rows
Show answer
Answer: C
Storing data in a columnar format lets jobs read only the columns they need, cutting both scan volume and cost, and partitioning further limits what is read. Compressing a row format still requires reading whole rows, a larger instance treats the symptom, and reducing rows discards data.
Want more questions like this? Full MLA-C02 practice tests →
Question 3. A feature is computed one way in the training pipeline and a slightly different way in the inference code. What problem does this create?
- A. Overfitting
- B. Training/serving skew
- C. Data drift
- D. Data leakage
Show answer
Answer: B
Computing features differently in training and serving is training/serving skew, so the model receives inputs at inference that do not match what it learned from, degrading production performance. Overfitting is memorisation of training data, drift develops over time from changing data, and leakage involves information unavailable at prediction time.
Want more questions like this? Full MLA-C02 practice tests →
Question 4. A fraud model on a real-time SageMaker AI endpoint needs each customer's latest transaction features within milliseconds, and the data science team must also build training sets from the full feature history. Which setup meets both needs?
- A. A feature group with only the offline store, queried from the endpoint
- B. A feature group with both the online store and the offline store enabled
- C. A feature group with only the online store, exported nightly for training
- D. Features recomputed inside the endpoint code from raw tables
Show answer
Answer: B
A feature group with both stores serves the latest record per customer from the online store at low latency, while the offline store in S3 keeps every historical record for building training sets. The offline store alone is too slow for real-time lookups, the online store alone keeps only the latest record, and recomputing features separately in the endpoint code invites training/serving skew.
Want more questions like this? Full MLA-C02 practice tests →
What to practise
Take one dataset and run it end to end: ingest, clean, engineer two features, validate, and split it correctly for its type. Then deliberately introduce a leak and watch your test metric jump. That second exercise teaches the most heavily tested concept in the largest domain in about twenty minutes.