AWS MLA-C01 to AWS MLA-C02: Machine Learning Engineer Foundations

The AWS Certified Machine Learning Engineer – Associate certification is in an active transition. For English-language candidates, AWS MLA-C01 stopped testing on September 28, 2026, and the AWS MLA-C02 beta began delivery on September 29. AWS MLA-C01 is still available in Japanese, Korean, and Simplified Chinese during the beta period, while general availability for AWS MLA-C02 is scheduled for January 14, 2027. That means a current English-language study plan should be built around AWS MLA-C02, while AWS MLA-C01 remains useful as a map of the core machine-learning engineering skills that carried forward.

The transition is not a reset. AWS MLA-C02 still tests data preparation, model development, deployment, orchestration, monitoring, maintenance, and security. What changes is the breadth of the role. Generative AI, foundation models, Amazon Bedrock, retrieval-augmented generation, agentic workflows, and responsible AI now sit beside traditional ML engineering. Candidates who understand the older foundations can reuse much of that knowledge, but they need to broaden the model from “train and deploy a model” to “implement and operate AI and ML solutions in production.”

The older AWS MLA-C01 exam destination still matters as historical context, but new English-language preparation should be anchored to the updated scope and transition resources rather than treating AWS MLA-C01 as the current English exam.

Start by separating what changed from what stayed foundational

AWS MLA-C02 keeps four broad content domains, but the wording now explicitly includes AI as well as ML. Data Preparation for ML and AI carries 28% of scored content. Model and Foundation Model Development carries 24%. Deployment and Orchestration of ML and AI Workflows carries 24%. Operating, Monitoring, and Securing ML and AI Solutions carries the remaining 24%. That structure is useful because it tells candidates that no single phase of the lifecycle can be ignored.

The strongest transition plan begins by mapping old knowledge to those four domains. Feature engineering, data quality, SageMaker training, endpoint deployment, pipeline automation, monitoring, and security remain relevant. The new work is identifying where foundation models, RAG, agentic orchestration, Amazon Bedrock, evaluation of generative systems, and responsible AI change the engineering decisions. The AWS MLA-C01 to AWS MLA-C02 transition is therefore best treated as a continuity exercise, not a complete restart.

Data preparation now has to support both predictive ML and generative AI

Traditional ML data preparation still requires reliable ingestion, transformation, cleaning, feature preparation, and train-validation-test logic. AWS MLA-C02 adds a second layer: AI workloads may rely on unstructured documents, embeddings, retrieval stores, prompt context, metadata, and content filtering. Candidates need to recognize that “prepare the data” can now mean preparing supervised training data, preparing inference features, or preparing knowledge sources for a retrieval-augmented system.

That changes the failure modes. A tabular model can fail because labels are wrong, leakage exists, or features drift. A RAG system can fail because the source documents are stale, chunks are poorly sized, metadata filters are weak, retrieval returns irrelevant context, or embeddings do not support the intended search behavior. The AWS MLA-C01 to AWS MLA-C02 data-preparation work should therefore include data quality, governance, and retrieval quality in the same engineering conversation.

Model development expands into foundation-model selection and adaptation

AWS MLA-C02 still expects candidates to reason about model quality, training decisions, hyperparameters, evaluation metrics, and cost-performance trade-offs. The difference is that the “model” may now be a traditional supervised model or a foundation model accessed through a managed AI platform. Selecting between building, fine-tuning, prompting, or using retrieval is an engineering decision driven by data, latency, accuracy, cost, privacy, and operational control.

Generative AI also changes what evaluation means. Accuracy can no longer be reduced to a single classification metric. Candidates should think about grounding, relevance, hallucination risk, safety, latency, token or inference cost, and task-specific quality. The AWS MLA-C02 model-development scope is strongest when studied through scenario trade-offs: choose the smallest adaptation technique that meets the requirement, then identify the evidence that would prove the choice works.

Amazon Bedrock belongs in an engineering workflow, not a product list

AWS MLA-C02 gives Amazon Bedrock more explicit importance because the modern machine-learning engineer may implement generative AI without managing the entire model-training stack. The exam-relevant skill is not memorizing every available model. It is understanding how a managed foundation-model service fits into architecture, security, retrieval, orchestration, evaluation, and operations.

For a scenario, ask what the application needs from the model layer. Does it need access to a foundation model, retrieval over enterprise content, agentic tool use, guardrails, evaluation, or controlled customization? Then ask what belongs outside the model: identity, data permissions, application logic, observability, and cost controls. This systems view prevents a common mistake in GenAI preparation—assuming that choosing a model automatically solves the data, security, and operational problems around it.

Deployment now includes agents and AI workflows as well as endpoints

AWS MLA-C01 candidates already needed to understand real-time endpoints, batch inference, pipeline automation, and deployment trade-offs. AWS MLA-C02 keeps those ideas but expands orchestration to systems where a request may trigger retrieval, model calls, tool use, multiple agents, validation, and downstream actions. A production workflow is therefore more than “model artifact to endpoint.”

Reliability becomes a chain. If retrieval is unavailable, if a tool call fails, if the model produces unusable output, or if an agent loops, the system needs controlled behavior. The AWS MLA-C02 deployment and orchestration material should be practiced with failure scenarios. Decide where retries are safe, where human review is needed, what state must be preserved, and what signals indicate that the workflow is healthy.

Monitoring has to distinguish model drift from AI-system quality problems

Traditional production ML monitoring still matters: input drift, prediction distribution changes, latency, resource behavior, endpoint errors, and business outcomes. Generative AI adds different questions. Are retrieved documents relevant? Are outputs grounded in approved context? Is safety behavior changing? Are token costs or response times growing? Are agent tools being called as expected?

Do not collapse all problems into “model drift.” A RAG application can become worse while the foundation model is unchanged because the knowledge corpus changed. An agent can fail because an API permission changed. A traditional model can degrade because the source distribution shifted. The AWS MLA-C02 MLOps and operations perspective should connect every symptom to the correct layer before proposing retraining or replacement.

Security and responsible AI now have to be designed together

AWS MLA-C02 broadens security reasoning beyond protecting training data and endpoints. Candidates should think about IAM boundaries, encryption, secrets, data residency, logging, private connectivity, and least privilege, but also about prompt injection, unsafe tool use, sensitive data exposure, model access, retrieval authorization, and responsible use of generated output.

The right architecture starts with trust boundaries. Which principal can access which data? Which model or agent can call which tool? Which content is permitted to enter a prompt? What should be logged without creating a second sensitive-data store? Where does human approval belong? Responsible AI is not a decorative layer added after deployment; it changes what the system is allowed to do and what evidence must be collected to show that behavior remains acceptable.

Use the beta format as a planning constraint, not a study topic

The AWS MLA-C02 beta is longer than the previous exam: 85 questions in 170 minutes, with beta pricing of $75 during the beta period. The additional items support statistical evaluation, so candidates should expect the session to demand sustained concentration. The format does not change the underlying preparation principle: breadth and decision quality matter more than memorizing isolated service descriptions.

Run mixed practice that moves across all four domains. A single scenario might begin with data ingestion, require a model or foundation-model choice, ask for deployment architecture, and finish with monitoring or security. Those integrated cases are more representative of the machine-learning engineer role than studying one AWS service at a time. They also expose where a candidate knows a product name but cannot connect it to an end-to-end requirement.

Build the final transition plan around continuity, additions, and evidence

Make three columns. In the first, list AWS MLA-C01 skills that clearly carry forward: data preparation, model development, deployment, orchestration, monitoring, maintenance, and security. In the second, list AWS MLA-C02 additions or expanded emphasis: foundation models, generative AI, RAG, agentic workflows, Amazon Bedrock, and responsible AI. In the third, write an evidence task for each item—a small architecture decision, lab, metric interpretation, or failure scenario that proves you can apply it.

English-language candidates should focus on AWS MLA-C02. Candidates still taking AWS MLA-C01 in a supported transition language should keep the older blueprint and its retirement timeline separate from AWS MLA-C02 preparation.

One useful final exercise is to take the same business requirement and solve it twice: once as a conventional supervised ML workload and once as a generative-AI workload. Compare the data path, model choice, evaluation criteria, deployment pattern, monitoring signals, and security boundaries. The point is not that one approach must win. The point is learning to recognize when a foundation model is genuinely justified and when a simpler predictive model is easier to govern, cheaper to operate, and more reliable.

That comparison also exposes weak preparation quickly. If you can describe a managed foundation-model solution but cannot explain how retrieval quality would be measured, the architecture is incomplete. If you can configure a training pipeline but cannot explain how a model will be monitored after deployment, the lifecycle is incomplete. AWS MLA-C02 is broad because production AI and ML engineering is broad; exam readiness comes from connecting the stages rather than mastering one service in isolation.