The AWS Certified Machine Learning Engineer \u2013 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.<\/p>\n
That makes the old \u201cMLA-C01 preparation guide\u201d 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.<\/p>\n
Candidates should therefore use the AWS Machine Learning Engineer \u2013 Associate<\/a> path as the credential target, while treating the legacy MLA-C01 exam<\/a> as historical context unless they are testing in one of the remaining supported languages.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n For candidates, that means AI and machine learning fundamentals<\/a> 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.<\/p>\n The transition is covered in more detail in our MLA-C02 preparation<\/a>, which is the better starting point for English-language candidates now.<\/p>\n 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.<\/p>\n 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.<\/p>\n Data work also creates a bridge to AWS Data Engineer \u2013 Associate<\/a>. 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n For MLA-C02, extend the same thinking to foundation models. \u201cModel selection\u201d 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\nMLA-C01 established the production-ML foundation that still matters<\/h2>\n
MLA-C02 adds generative AI to the engineering job, not as a side topic<\/h2>\n
Data preparation remains the first engineering bottleneck<\/h2>\n
Model development should be studied as an experiment system<\/h2>\n
Deployment is where ML becomes a software-engineering problem<\/h2>\n
MLOps turns repeated work into controlled pipelines<\/h2>\n
Monitoring must include model behavior, not only infrastructure health<\/h2>\n