AWS Machine Learning Engineer: MLA-C01 to MLA-C02
The AWS Certified Machine Learning Engineer – Associate track changed materially in September 2026. MLA-C01 is no longer available in English as of September 28, while the MLA-C02 beta began delivery on September 29. MLA-C01 remains available for Japanese, Korean, and Simplified Chinese candidates during the beta period, with AWS planning full MLA-C02 general availability on January 14, 2027.
That makes the old “MLA-C01 preparation guide” framing incomplete for most candidates studying in English today. The certification still validates the engineering work required to build, deploy, operate, and secure machine learning systems, but MLA-C02 expands the role to include generative AI, foundation models, retrieval-augmented generation, agentic workflows, Amazon Bedrock, and responsible AI alongside traditional ML engineering.
Candidates should therefore use the AWS Machine Learning Engineer – Associate path as the credential target, while treating the legacy MLA-C01 exam as historical context unless they are testing in one of the remaining supported languages.
MLA-C01 organized the role around four large responsibilities: preparing data, developing models, deploying and orchestrating ML workflows, and monitoring, maintaining, and securing ML solutions. Those responsibilities remain highly relevant because a production ML system still needs reliable data, reproducible training, controlled deployment, observability, security, and cost management.
This is an important distinction from data-science-only preparation. The exam has never been primarily about deriving algorithms by hand. It is about taking models and ML workloads into a cloud operating environment. A candidate needs to understand data ingestion and transformation, training jobs, model evaluation, versioning, endpoints, pipelines, CI/CD, monitoring, drift, and resource security.
That operational perspective is why DevOps engineers, data engineers, backend developers, MLOps engineers, and data scientists can all find parts of the certification relevant. The strongest candidates see the ML lifecycle as a system, not a notebook.
The updated exam reflects a major change in ML engineering work. Production teams are no longer dealing only with supervised models trained on internal data. They are also selecting foundation models, integrating managed model APIs, building retrieval systems, orchestrating agents, evaluating generated output, and applying controls to systems whose behavior is probabilistic.
For candidates, that means AI and machine learning fundamentals cannot be treated as a short final chapter. It needs to connect to data preparation, deployment, monitoring, security, and cost. A RAG application still needs a reliable data pipeline. An agent still needs identities and permissions. A foundation model still needs evaluation and observability. Production inference still has latency and cost trade-offs.
The transition is covered in more detail in our MLA-C02 preparation, which is the better starting point for English-language candidates now.
Reliable models begin with reliable data. Candidates should be comfortable reasoning about ingestion, storage formats, batch and streaming patterns, data quality, transformation, feature engineering, and the security controls around training data. The exact AWS service depends on the workload; the durable skill is choosing a data path that is reproducible, observable, and appropriate for the scale.
Practice by building a small pipeline from source to training-ready dataset. Validate schemas, handle missing values, track versions, and make the transformation repeatable. Then deliberately break the input. A pipeline that only works on clean sample data teaches less than one that detects and reports bad records.
Data work also creates a bridge to AWS Data Engineer – Associate. The two roles overlap around ingestion, transformation, orchestration, data quality, and security, but the ML engineer carries those responsibilities forward into training, deployment, and model operation.
Training a model is only one step. A production engineering workflow needs a way to compare experiments, manage features and hyperparameters, evaluate metrics, track artifacts, and decide when a model is good enough to advance. Candidates should understand common model-performance concepts and the practical consequences of overfitting, underfitting, data leakage, class imbalance, and poor evaluation design.
The AWS-specific part is knowing how managed services support those workflows. SageMaker provides tools across data processing, training, tuning, model management, deployment, and monitoring. Candidates should understand where managed capabilities reduce undifferentiated engineering work and where custom code is still required.
For MLA-C02, extend the same thinking to foundation models. “Model selection” may mean choosing between model families or sizes, deciding whether prompting is enough, or determining whether retrieval or fine-tuning is justified. The engineering decision should be driven by quality, latency, security, and cost rather than by novelty.
A trained model creates no business value until an application can use it reliably. Deployment design includes real-time or batch inference, endpoint capacity, scaling behavior, version rollout, rollback, networking, authentication, and integration with the rest of the application.
Practice several deployment patterns. Serve a model behind an endpoint. Run a batch inference job. Deploy a new version with a controlled rollout. Capture logs and metrics. Then consider what changes when the workload uses a foundation model API rather than a model you trained yourself.
The key exam skill is matching the deployment approach to the requirement. A low-latency interactive application, an overnight batch scoring job, and a large asynchronous processing workload should not all use the same pattern.
ML systems are unusually sensitive to change because code, data, features, model artifacts, and infrastructure can all affect behavior. MLOps exists to make those changes repeatable and observable. Candidates should understand pipeline orchestration, source control, automated testing, artifact management, environment separation, approvals, and deployment automation.
A good project for this domain is to build a pipeline that retrains a model from versioned data, evaluates it against a threshold, registers the artifact, and only then allows promotion. The implementation can be small. The value is in creating a controlled path from data change to production change.
For generative AI, the pipeline may also need prompt versions, retrieval-index updates, model configuration, safety tests, and evaluation datasets. MLA-C02 broadens the idea of MLOps into a more general AI operations discipline.
Traditional application monitoring asks whether a service is up, fast, and error-free. ML monitoring adds a second layer: whether the model’s behavior is still acceptable. Data distributions can shift, prediction quality can degrade, and input patterns can move away from the training population even when the endpoint itself is healthy.
ML engineers need metrics for both infrastructure and model behavior. Monitor latency, errors, throughput, and resource utilization, but also data quality, drift, and outcome metrics where ground truth is available. Use alerts that map to an operational response rather than creating dashboards nobody owns.
Generative AI adds further evaluation challenges: relevance, groundedness, safety, hallucination risk, tool-use success, and cost per interaction. The exact metrics depend on the application, but the operational principle remains the same—observe the behavior users actually depend on.
ML workloads can expose sensitive data, expensive compute, proprietary models, inference endpoints, and credentials. Candidates should understand IAM roles, least privilege, encryption, network controls, secrets, and audit logging. Security is not a final deployment checkbox; it changes how data is accessed, where training runs, how endpoints are exposed, and how automation is authorized.
Generative AI increases the attack surface. Prompt injection, unsafe tool use, retrieval poisoning, model-access control, and sensitive-data exposure all require explicit design. A strong security foundation is therefore becoming more valuable for ML engineers, not less.
The wider AWS AI security and governance material can help connect those controls to modern generative-AI application patterns.
The best preparation artifact is an end-to-end system. Start with a dataset. Build ingestion and validation. Train or integrate a model. Evaluate it. Deploy it. Add monitoring. Secure the workload. Then document what happens when input data changes or the model no longer meets the target metric.
If you are preparing for MLA-C02, add one generative-AI component. For example, build a retrieval application that indexes trusted documents, calls a foundation model, evaluates responses against a small test set, and logs latency and cost. The project does not need to be large; it needs to force you to connect the lifecycle.
That creates much better exam readiness than memorizing dozens of SageMaker feature names. It also creates a stronger interview story because you can explain the decisions, failures, and trade-offs you encountered.
As of October 3, 2026, English-language candidates should plan around MLA-C02. MLA-C01 English testing has ended. Candidates testing in Japanese, Korean, or Simplified Chinese may still have an MLA-C01 window during the beta period, but that path is temporary.
Whatever version you take, do not discard the production-ML foundation. Data preparation, model development, deployment, orchestration, monitoring, and security remain the core engineering system. MLA-C02 adds the AI patterns that modern ML engineers are increasingly expected to operate.
The durable goal is therefore larger than an exam code: become capable of taking an ML or AI workload from data to reliable production operation. The certification is most valuable when your preparation builds exactly that skill.
