AWS ML Engineer Associate Prep Series — Part 1

The Data Foundation You Need Before You Train Any Model

If you are preparing for AWS Certified Machine Learning Engineer - Associate (MLA-C01), one thing becomes clear quickly: this is not just a model-training exam.

A large part of both the exam and real-world ML work is data engineering. You need to understand how data is structured, where it is stored, how it moves, how it is secured, and how it is transformed into features that models can actually learn from.

This post is a practical, engineer-focused walkthrough of the core concepts I’ve studied, consolidated into a single, cohesive foundation.

Why this matters for MLA-C01

You can know SageMaker very well and still struggle if you are weak in:

• Data lake vs warehouse choices
• Amazon S3 storage and security design
• Streaming architecture (Kinesis, Firehose, Kafka)
• Batch transformation with EMR and Spark
• Feature engineering fundamentals

These are not side topics. They are the plumbing behind successful ML systems.

1) Start with data reality: type and shape

Structured, unstructured, semi-structured

Most architecture mistakes happen when teams pick tools before classifying data correctly.

• Structured data:
  • Fixed schema, rows/columns
  • Easy SQL querying
  • Examples: relational tables, consistent CSVs
• Unstructured data:
  • No predefined schema
  • Requires preprocessing before analytics
  • Examples: images, videos, audio, free text
• Semi-structured data:
  • Some structure, but flexible
  • Often tag- or key-value-based
  • Examples: JSON, XML, logs, email headers

The 3Vs you should actively design for

• Volume: how much data exists (GB to PB scale)
• Velocity: how fast it arrives (batch vs near-real-time vs streaming)
• Variety: how many formats/sources you combine

Practical takeaway: these three dimensions should determine your storage and processing architecture before any model discussion starts.

2) Storage strategy: warehouse, lake, lakehouse, and mesh

Data warehouse

Use when you need highly reliable, fast analytics on clean, structured data.

• Schema-on-write
• ETL first, load second
• Optimized for complex reads
• AWS anchor service: Amazon Redshift

Data lake

Use when you need scalable, low-cost storage for raw data in mixed formats.

• Schema-on-read
• ELT is common
• Excellent for exploration and ML feature discovery
• AWS anchor service: Amazon S3 (often with Glue + Athena)

Quick decision rule

• Choose warehouse first when BI/reporting with strict data contracts is your primary objective.
• Choose lake first when data diversity and future flexibility are primary objectives.
• Most mature teams use both: raw in lake, curated in warehouse.

Lakehouse concept

Lakehouse combines the low-cost scale of lakes with the reliability and governance of warehouse-like behavior.

In practice, this gives teams one logical platform for SQL analytics and ML without duplicating too many pipelines.

Data mesh (important framing)

Data mesh is not a storage technology. It is an organizational model:

• Domain teams own data products
• Governance is federated with shared standards
• The platform enables self-service

You can run a mesh on top of lakes, warehouses, or both.

Quick gut check: A retailer wants to dump clickstream logs, product images, and POS transactions into one place for future ML experimentation, with no fixed schema decided yet. Warehouse or lake? — Lake. Schema-on-read and mixed formats are exactly the scenario it's built for. If the question instead said "finance needs a daily reconciled sales report with strict accuracy," that's a warehouse problem.

3) ETL/ELT pipeline thinking

No matter the stack, your data path is still some variation of:

• Extract from databases, APIs, logs, and streams
• Transform via cleaning, enrichment, formatting, and aggregation
• Load into serving/analytics/training stores

On AWS, common orchestration patterns include:

• AWS Glue for managed ETL
• Amazon EventBridge for event/schedule triggers
• Amazon MWAA (Managed Workflows for Apache Airflow) for Airflow-style DAG orchestration
• AWS Lambda for lightweight transformations and glue logic

Engineer mindset: automation and reliability are part of pipeline design, not an afterthought.

4) File formats that directly affect cost and performance

CSV

• Human-readable and easy to exchange
• Great for simple interoperability
• Not ideal for large analytical workloads

JSON

• Flexible and nested
• Great for APIs and semi-structured payloads
• Can become expensive for large-scale scan-heavy analytics

Avro

• Binary format with schema support
• Excellent for streaming ecosystems and schema evolution

Parquet

• Columnar format optimized for analytics
• Better compression and selective column reads
• Usually, the best default for lake analytics and many ML preprocessing tasks

Exam instinct: if the question hints at large-scale analytical reads, Parquet is often the right answer.

5) Amazon S3 essentials every ML engineer should know

S3 is the backbone of AWS data and ML architectures. If you can reason well about S3, many exam scenarios become easier.

Buckets, objects, and keys

• Buckets are globally unique by name
• Buckets are region-scoped resources
• Objects are identified by keys (full path-like names)
• There are no true directories, only key prefixes

Security model

Access is controlled through a combination of:

• IAM policies (identity-based)
• Bucket policies (resource-based)
• ACLs (legacy/finer-grain, often disabled in modern setups)

Access is only granted when:

• You have an allow path
• And there is no explicit deny

Encryption options

• SSE-S3:
  • S3-managed keys
  • Enabled by default for new objects
• SSE-KMS:
  • KMS-managed keys
  • Better control and auditability
  • Be aware of KMS API quota impact at high throughput
• SSE-C:
  • Customer-provided keys in request headers
  • HTTPS required
• Client-side encryption:
  • Data encrypted before upload
  • Full key lifecycle ownership on the customer side

Versioning and replication

• Versioning protects against accidental overwrite/delete
• CRR replicates across regions
• SRR replicates within the region
• Replication is asynchronous
• By default, only new objects replicate after rules are enabled

Storage classes (cost/performance tiering)

Know the intent, not just names:

• Standard: frequent access
• Standard-IA and One Zone-IA: less frequent access with faster retrieval
• Glacier tiers: archival with slower retrieval and lower cost
• Intelligent-Tiering: access-pattern-driven automatic movement

A number worth memorizing: every storage class shares the same 99.999999999% (11 nines) durability. Put plainly, if you stored 10 million objects, you'd expect to lose roughly one every 10,000 years. The classes differ on availability, retrieval speed, and cost — never on durability.

Performance numbers that show up in scenarios

A few baseline figures are worth keeping in your back pocket, because exam scenarios often hinge on whether you'd hit a default limit:

• S3 supports roughly 3,500 PUT/COPY/POST/DELETE and 5,500 GET/HEAD requests per second, per prefix — design key naming with this in mind if you're expecting heavy parallel access.
• Multipart upload is recommended for files above 100 MB and required for files above 5 GB.
• SSE-KMS encryption routes through KMS API calls, which count against your KMS request quota (typically in the 5,500–30,000 requests/second range depending on key type). At high-throughput ingestion, this is a real bottleneck that people miss.

S3 Object Lambda

A pattern worth knowing beyond plain storage: S3 Object Lambda lets you run a Lambda function on an object during retrieval, without creating a second copy of the data. Common uses are redacting PII before handing data to an analytics job, converting formats on the fly, or resizing images. It's a clean way to add a transformation step without building a separate pipeline.

Lifecycle rules

Lifecycle is where S3 cost control gets real.

• Transition objects to cheaper classes by age/access profile
• Expire old objects and noncurrent versions
• Scope rules by prefix or tags

Eventing and integration

S3 can emit object events to:

• SNS
• SQS
• Lambda
• EventBridge (for richer routing/filtering and replay patterns)

Typical ML pattern: upload raw data to S3 -> trigger Lambda/Step orchestration -> run transformation or training prep jobs.

Quick gut check: You need to fan out a single S3 upload event to three different downstream systems, with the ability to replay events if one system was down during an incident. SNS, SQS, or EventBridge? — EventBridge. It supports advanced filtering, multiple targets, and archive/replay, which plain SNS/SQS notifications don't give you out of the box.

6) EC2-era storage choices for ML workloads

EBS

• Block storage for single-instance attachment (with specific multi-attach exceptions)
• AZ-scoped
• Snapshot/restore to move across AZs
• Good for instance-bound state and predictable performance

EFS

• Managed NFS for shared file access across multiple EC2 instances and AZs
• Linux/POSIX-oriented usage
• Great for shared model assets, CMS-like content, and collaborative workloads
• Higher cost than EBS, but a very different value proposition
• Bursting throughput mode scales with storage size (roughly 50 MiB/s per TB stored, with burst capacity), while Provisioned mode lets you set throughput independent of how much you've stored — worth knowing when a scenario describes a small but throughput-hungry workload

FSx family (managed specialist file systems)

• FSx for Windows File Server: SMB/Windows integrations
• FSx for Lustre: high-performance compute, HPC, ML, tight S3 integration
• FSx for NetApp ONTAP and OpenZFS: enterprise NAS and migration-heavy scenarios

FSx for Lustre deserves a second look for ML specifically: it can mount your S3 bucket directly as a file system, so training jobs read S3 data with file-system semantics instead of API calls. Choose Scratch when you just need fast temporary processing storage for a training run, and Persistent when the file system itself needs to outlive any single job.

Exam instinct: map protocol and workload requirements first, then choose storage.

7) Streaming stack: Kinesis, Firehose, Flink, and MSK

Kinesis Data Streams

Use when you need custom real-time stream processing with replayability.

• Retention up to 365 days
• Ordered processing per partition key
• Provisioned or on-demand capacity modes, on-demand defaults to 4 MB/s in (about 4,000 records/s) and auto-scales based on your recent peak traffic
• Producer/consumer app responsibility remains with your team

Firehose

Use when you mainly want managed delivery into destinations.

• Near-real-time buffering and delivery
• Minimal operational overhead
• Destination-focused (S3, Redshift, OpenSearch, partner endpoints)
• No long-term stream replay model like Data Streams

Managed Service for Apache Flink

Use when SQL-on-stream or custom stream processing logic is needed at scale.

• Stateful stream processing
• SQL and code-based processing patterns
• Integrates with Kinesis and Kafka ecosystems
• Naming gotcha worth knowing: this service used to be called "Kinesis Data Analytics for Apache Flink." You'll still see the old name in plenty of materials and forum posts, so don't let it throw you if a question or article uses either term — they're the same service.
• It ships with a built-in RANDOM_CUT_FOREST SQL function for anomaly detection directly on streaming numeric data — handy for flagging unusual metrics in real time without standing up a separate ML pipeline. The same Random Cut Forest algorithm shows up again later in feature engineering, and in SageMaker and QuickSight, so it's worth remembering as one algorithm AWS reuses across several services.

Amazon MSK (Managed Kafka)

Use when your team is Kafka-native or needs Kafka-compatible tooling.

• Managed Kafka brokers and infrastructure
• Broad auth/authz options
• Strong fit for existing Kafka producer/consumer estates

Fast architecture heuristic

• Need fine-grained custom real-time processing + replay: Kinesis Data Streams
• Need managed ingestion to destinations quickly: Firehose
• Need Kafka ecosystem compatibility: MSK
• Need richer stateful stream computation: Flink

Quick gut check: A streaming pipeline needs to land raw events into S3 with minimal code, no custom consumer logic, and you're fine without replay. Kinesis Data Streams or Firehose? — Firehose. The moment "minimal operational overhead" and "just deliver it to a destination" show up together, that's the Firehose signal.

8) EMR and Spark for large-scale transformation

EMR fundamentals

EMR is a managed big-data infrastructure on EC2 for engines like Spark, Hive, and Flink.

Typical node responsibilities:

• Master node: cluster control plane
• Core nodes: store HDFS data and run tasks
• Task nodes: compute-only, good spot candidate

EMR Serverless

EMR Serverless reduces capacity planning burden by scaling workers based on submitted jobs.

Important operational point: lifecycle management still matters. Idle/orphaned serverless applications can still cost money if not managed well.

Spark relevance to ML pipelines

Spark remains a strong choice for distributed transformations and feature preparation.

Common advantages:

• Scales feature engineering and joins over large datasets
• Integrates with S3 and the AWS ecosystem well on EMR
• Supports SQL, DataFrame APIs, and ML libraries

9) Feature engineering: where ML quality is won or lost

This is the highest leverage section for many practical ML systems.

Dimensionality awareness

More features are not always better.

• High-dimensional spaces become sparse
• Irrelevant features hurt generalization
• Use selection/reduction patterns (for example, PCA) when needed

TF-IDF in plain language

TF-IDF helps identify words that are important to a specific document, but not common everywhere.

• High term frequency in one document: likely relevant there
• High document frequency across corpus: likely generic term

This is foundational in search and many text ML baselines.

A natural extension is n-grams: instead of scoring single words, you score sequences of two or more (bigrams, trigrams). "Not good" carries different meaning than "not" and "good" scored separately, and n-grams capture that, at the cost of a much larger vocabulary to track.

Missing data handling

There is no universal best method. Choose based on context:

• Quick baseline: mean/median/mode imputation
• Better structure-aware methods: KNN/regression/model-based imputation, or MICE (Multiple Imputation by Chained Equations) when you want a method that models relationships between features rather than treating each column in isolation
• Sometimes dropping rows is acceptable, but usually only when missingness is small and non-biased
• Best answer when possible: improve upstream data collection

Imbalanced classes

Typical in fraud/anomaly detection.

Common techniques:

• Oversampling the minority class
• Undersampling the majority class (use cautiously)
• SMOTE synthetic minority generation
• Threshold adjustment for precision/recall trade-offs

Outlier treatment

Use domain judgment, not blind deletion.

• Standard deviation and robust statistics help detect unusual points
• Outliers can be errors, bots, or rare but valid behavior
• Removing outliers without context can damage model quality
• AWS has a purpose-built algorithm for this: Random Cut Forest, which shows up across SageMaker, QuickSight, and (as mentioned above) Managed Service for Apache Flink. If a question is specifically about anomaly detection on AWS rather than outlier handling in general, Random Cut Forest is usually the name they're looking for.

Binning

Sometimes the right move isn't to clean a numeric feature, but to bucket it. Grouping ages into "20s," "30s," "40s," or grouping incomes into ranges trades precision for stability, especially when the raw measurement is noisy, or the model benefits more from a category than an exact value. Quantile binning, where bin edges are chosen so each bucket has a roughly equal number of observations, is a common way to do this without hand-picking thresholds.

Encoding, scaling, and shuffling

These are basic, but critical:

• One-hot encoding for categorical features
• Scaling/normalization to avoid magnitude bias
• Shuffle training data to reduce sequence artifacts

Quick gut check: A QuickSight dashboard needs to flag unusual spikes in daily transaction volume without anyone writing custom anomaly-detection code. What's the AWS-native answer? — Random Cut Forest, used directly inside QuickSight's anomaly detection feature. Same algorithm, different surface, which is exactly the kind of cross-service pattern matching this exam rewards.

What to remember for the exam

If you only keep one checklist from this post, keep this one:

1. Always match architecture to data type, velocity, and access pattern.
2. S3 is foundational: know security, encryption, versioning, storage classes, lifecycle, eventing, and the concrete numbers behind them (11 nines durability, request-rate baselines, multipart thresholds).
3. Distinguish clearly between Kinesis Data Streams, Firehose, Flink, and MSK — and don't let the Flink service's old "Kinesis Data Analytics" name confuse you in older materials.
4. Understand when to use EBS vs EFS vs FSx, including FSx for Lustre's direct S3 mount for training data.
5. Treat feature engineering as first-class system design, not cleanup work, and notice how often Random Cut Forest reappears across AWS services as the go-to anomaly/outlier algorithm.

Closing

My biggest preparation insight so far: the exam rewards architecture judgment more than memorization.

When you can explain why a specific storage class, stream service, or feature-engineering tactic is right for a concrete workload, you are preparing the right way.

In Part 2, I will go deeper into SageMaker-focused topics: training patterns, tuning, deployment modes, and practical MLOps decisions that show up frequently in MLA-C01 scenarios.