1. Exam Overview

What the exam is really testing

MLA-C01 is not a pure machine-learning theory exam and it is not a broad cloud-architecture exam. It tests whether you can take an ML workload from data preparation to production operations using the correct AWS services, with attention to cost, reliability, security, and maintainability.

Most questions are scenario-based. The exam rarely asks, “What does this service do?” Instead, it asks you to choose the best service or architecture for a specific constraint:

• Low latency or offline inference?
• Stateful streaming or simple delivery?
• Shared features for training and inference?
• Accuracy, recall, or precision?
• Canary deployment or immediate replacement?
• Reactive scaling or scheduled scaling?
• IAM role or long-lived access key?
• Data drift or infrastructure latency?
• Athena, Glue, EMR, Flink, Lambda, or Data Firehose?

Your task is to identify the requirement that matters most, eliminate services that solve a different problem, and choose the least complex managed option that fully satisfies the scenario.

Official exam format

Core exam mindset

Use this sequence for almost every question:

1. Classify the problem: data, model, deployment, monitoring, cost, or security.
2. Underline the decisive constraint: latency, scale, stateful processing, delayed labels, public exposure, cost threshold, auditability, or operational simplicity.
3. Choose the AWS service designed for that job.
4. Reject answers that solve a neighboring problem.
5. Prefer managed and maintainable solutions unless the scenario explicitly requires custom control.

2. Exam Domains

The official blueprint contains four content domains.

Domain task statements

Content Domain 1: Data Preparation for Machine Learning (ML)

Content Domain 2: ML Model Development

Content Domain 3: Deployment and Orchestration of ML Workflows

Content Domain 4: ML Solution Monitoring, Maintenance, and Security

3. Start-to-Finish Study Path

Use this sequence so that each topic builds on the previous one.

Phase 1: Data foundation

Master these first:

1. S3 formats and partitioning.
2. Athena versus Glue versus EMR.
3. Kinesis, Data Firehose, Flink, and Lambda.
4. Data Wrangler, DataBrew, and Glue Data Quality.
5. Feature Store online and offline access.
6. Bias, leakage, splitting, PII masking, KMS encryption.

Checkpoint: You should be able to design a clean, governed path from raw data to training-ready features.

Phase 2: Model development

Study:

1. Business problem to algorithm or managed AI service.
2. Metrics: accuracy, precision, recall, F1, RMSE, ROC, AUC.
3. Overfitting, underfitting, convergence, and catastrophic forgetting.
4. Early stopping, regularization, distributed training, fine-tuning.
5. SageMaker automatic model tuning.
6. SageMaker Clarify, Model Debugger, JumpStart, and Model Registry.

Checkpoint: You should be able to justify a model-development decision using business cost, performance, explainability, and operational requirements.

Phase 3: Production deployment

Study:

1. Real-time endpoint.
2. Batch transform.
3. Serverless inference.
4. Asynchronous inference.
5. Multi-model and multi-container endpoint patterns.
6. Lambda, ECS, EKS, and edge optimization.
7. Endpoint auto scaling and infrastructure as code.
8. ECR and custom containers.

Checkpoint: You should be able to choose a deployment pattern from latency, traffic shape, payload size, processing time, cost, and model count.

Phase 4: Automation, monitoring, and security

Study:

1. SageMaker Pipelines, EventBridge, Step Functions, and MWAA.
2. CodeBuild, CodePipeline, CodeDeploy, and rollback strategies.
3. Model Monitor, Clarify, CloudWatch, CloudTrail, X-Ray.
4. Inference Recommender, Cost Explorer, Budgets, tagging.
5. IAM roles, KMS permissions, Secrets Manager, S3 Block Public Access, and VPC endpoints.

Checkpoint: You should be able to operate the workload safely after deployment and troubleshoot the first production failure.

4. Core Concepts by Domain

Content Domain 1: Data Preparation for Machine Learning (ML)

4.1 Ingest and store data

Choose the data format from the access pattern

Decision rule: If the scenario says Athena, analytical scans, small subset of columns, or reduce scan cost, choose Parquet and a sensible partition scheme.

S3 partitioning

Partition on columns that frequently appear in filters, such as:

• Event date
• Region
• Tenant
• Business unit
• Data source

Avoid:

• Random-only partition keys
• Extremely high-cardinality partitions
• One object per row
• Millions of tiny objects

Small-files trap: Increasing prefixes does not fix the root problem if distributed jobs still open millions of tiny files. Compact files into appropriately sized objects while retaining useful partitions.

Storage selection

Exam trap: Glacier is for archive and retrieval use cases. It is not the default active training-data tier.

Athena, Glue, and EMR

Elimination rule:
If the scenario says query S3 with SQL without provisioning servers, choose Athena.
If it says catalog, ETL, Spark transformation, or curated output, choose Glue.
If it says deep Spark customization, cluster control, or specialized big-data environment, consider EMR.

Batch versus streaming ingestion

Key contrast: Data Firehose versus Flink

• Data Firehose: Deliver streaming records to destinations such as S3 with minimal administration.
• Flink: Stateful processing, windows, aggregations, event-time logic, and late arrivals.

If the question mentions rolling windows, out-of-order events, or stateful processing, Firehose alone is usually too limited.

Transfer and I/O optimization

Do not confuse:

• S3 Transfer Acceleration with EBS IOPS.
• EBS IOPS with S3 scan optimization.
• File compaction with network acceleration.