---
title: "The AI/ML Lifecycle and What MLOps Adds, for AWS AIF-C01"
description: "Each lifecycle stage by what it produces, the two feedback loops around deployment, which AWS service fits each stage, and the seven things MLOps adds."
source: "https://confidentprep.com/blog/the-ai-ml-lifecycle-from-raw-data-to-a-maintained-model/"
date: "2026-10-08"
tags: ["aws", "aif-c01", "mlops", "sagemaker"]
token_estimate: 3309
---

# The AI/ML Lifecycle and MLOps for the AIF-C01 Exam

A model can pass every test before launch and still fail after it meets real traffic. For the AIF-C01 exam, explaining that failure requires more than memorizing a pipeline: you need to know what each stage produces, how neighboring stages differ, which AWS services belong at each stage, and where a symptom occurs. The central claim is simple: the AI/ML lifecycle turns data into a deployed model, while MLOps adds the repeatability, monitoring, ownership, and feedback loops needed to keep that model useful.

## Each lifecycle stage hands a distinct output to the next

The lifecycle is often drawn as a pipeline, but knowing the order is only the beginning. Exam questions commonly describe an activity or symptom and ask you to identify its stage. The reliable method is to ask what output that stage creates.

Data collection produces a stored, accessible dataset. Its purpose is to make relevant data available, not yet to understand, repair, or reshape it.

Exploratory data analysis, or EDA, produces understanding. It reveals distributions, gaps, outliers, and patterns without necessarily changing the dataset.

Data pre-processing produces clean, consistent, usable data. It corrects problems found during exploration, such as missing values, duplicate records, or inconsistent formats.

Feature engineering produces model-ready input variables. A feature is a value supplied to a model. Feature engineering creates useful variables from sufficiently clean data—for example, converting a purchase timestamp into “days since last purchase.”

Model training produces a candidate model by learning internal parameters from data. Hyperparameter tuning produces a better-configured candidate by changing settings that govern learning rather than values learned during it.

Evaluation produces a pass-or-fail verdict against the success metric. Deployment produces a callable model in production. Monitoring produces signals about live quality, drift, and cost.

![Data becomes understanding, usable inputs, a candidate model, a verdict, a deployment, and live signals.](visuals/visual-01.svg)

*Each lifecycle stage produces an output needed by the next stage.*

Consider duplicate customer records. Discovering that duplicates exist belongs to EDA because it creates understanding. Removing them belongs to pre-processing because it changes the dataset. The same records appear in both stages, but the purpose and output differ.

## Adjacent stages are separated by what they do to the system

Most confusing lifecycle choices sit beside each other. Four distinctions resolve many of them.

EDA looks; pre-processing changes. Inspecting distributions or identifying gaps is exploration. Filling missing values, standardizing formats, or removing duplicates is pre-processing.

Pre-processing fixes what is wrong; feature engineering creates what is useful. Correcting malformed timestamps is pre-processing. Deriving the day of the week from those corrected timestamps is feature engineering.

Training learns parameters; tuning selects the settings that govern learning. Parameters are learned from examples. Hyperparameters are chosen settings that control how learning happens. A tuning run may train several candidates under different settings, but the concepts remain distinct.

Evaluation happens before deployment; monitoring happens after it. Evaluation asks whether a candidate meets the success bar under controlled testing. Monitoring asks whether the deployed system remains healthy under changing production conditions.

![Four stage pairs are separated by looking, fixing, learning, and their position around deployment.](visuals/visual-02.svg)

*The commonly confused stages differ by action, output, or position relative to deployment.*

Suppose a model performs poorly during its pre-launch test. That is an evaluation result, so the team returns to model development. If poor performance appears only after deployment, “evaluate the model” is incomplete: the symptom belongs to monitoring, and its cause may be changing production data.

This is the wrong-stage distractor pattern. The proposed activity may be useful and accurately described yet still be wrong because it belongs elsewhere. Locate the stage before choosing the fix.

## A real pipeline contains two feedback loops

The lifecycle is not a one-way journey. It contains two important loops, divided by deployment.

The first begins when evaluation shows that a candidate has missed its success metric. The process returns to model development. The team might revise features, adjust hyperparameters, improve training, or reconsider the data. This loop occurs before release.

The second begins when monitoring detects a production problem. One important trigger is data drift: the distribution of live inputs has shifted away from the training data. The response returns to data preparation so the model can be retrained using current conditions.

![Failed evaluation loops to development, while production drift loops from monitoring to data preparation.](visuals/visual-03.svg)

*Evaluation repairs candidates before launch; monitoring refreshes systems after production changes.*

Think of these as two alarms. The first says, “This candidate is not ready.” The second says, “The deployed system no longer matches its environment.” Treating them as the same alarm leads to the wrong intervention.

Drift has a recognizable evidence pattern: the code and deployed model are unchanged, error grows over time, and the input distribution has shifted. Those facts point away from a release defect or a model that was wrong from the beginning.

For example, imagine a forecasting model that initially performs well but develops rising error after the available product range changes. The model artifact has not changed; the world supplying its inputs has. The evidence supports returning to the data and retraining, not automatically replacing the algorithm.

This separates drift from overfitting. An overfit model performs well on training data but poorly on live data from the start. A drifting model performs well initially and then degrades. Bad from launch suggests a development problem; decay after launch suggests changing data.

## Model sourcing, serving, and services are separate decisions

Model sourcing asks where a model comes from. Serving asks how users or systems access it. AIF-C01 service questions add a third decision: which AWS service supports the relevant lifecycle stage.

There are three broad sourcing choices. An open-source pre-trained model is fastest to adopt when it already performs the task. Adapting a pre-trained model fits cases where it is close but needs domain-specific behavior or vocabulary. Custom training offers the most control and specificity, but it is justified only when existing models do not fit and the team has suitable labeled data and training skills.

![Use a fitting pre-trained model, adapt a close one, or train custom only with data and skills.](visuals/visual-04.svg)

*Model sourcing trades faster adoption for greater control and specificity.*

The common distractor is custom training selected merely because it sounds more capable. The scenario must establish the need and the resources.

Serving presents a managed-versus-self-hosted choice. A managed API reduces responsibility for infrastructure, scaling, and patching but provides less runtime control. Self-hosting provides more control over placement and model versions while transferring every operational responsibility to the team.

The deciding axis is operational burden versus control. A small team without ML operations staff points toward a managed API. A binding requirement that model weights remain on controlled infrastructure points toward self-hosting. Wanting control is not enough; the scenario should state a regulatory, residency, or contractual constraint.

For AIF-C01, attach named services to stages rather than memorizing them in isolation. Amazon S3 and AWS Lake Formation support storing and cataloging data. AWS Glue DataBrew supports no-code cleaning and normalization during pre-processing. Amazon SageMaker AI supports training and deploying a team’s own model, while SageMaker JumpStart supplies pre-built models that can be adapted.

Amazon Bedrock provides access to foundation models and can serve them through an API. Amazon Q and Kiro assist the developers building the pipeline; they do not transform pipeline data. Amazon Quick supports business-facing analysis and reporting. SageMaker Model Monitor and Amazon CloudWatch provide monitoring and alerting signals.

For example, Amazon Quick may genuinely build the dashboard a business reads, but that does not make it a data pre-processing service. A correct service description attached to the wrong stage remains a wrong answer.

## MLOps turns a successful experiment into a maintained system

A working model answers, “Can this task be performed?” MLOps answers three harder questions: Can the result be reproduced? Can the system be redeployed reliably? Will someone know when it stops working?

MLOps adds seven core capabilities. Experimentation records variants and results so they can be compared and recovered. Repeatable processes let the same inputs produce the same model without remembered manual steps. Scalable systems let training and serving grow with data and traffic.

Managing technical debt controls accumulated glue code, obsolete features, and untracked datasets. Production readiness establishes testing, rollback, monitoring, ownership, and operational preparation before launch. Model monitoring watches live quality, not merely service availability. Model retraining defines the trigger and process for refreshing a model.

![Experimentation, repeatable processes, monitoring, and retraining keep a deployed model maintainable.](visuals/visual-05.svg)

*MLOps connects reproducible development to reliable operation and model renewal.*

For example, a team might possess a high-scoring model file but no record of which dataset, features, settings, or code version produced it. The model works, yet it cannot be reproduced. That is an MLOps failure because reliable retraining and deployment depend on traceable inputs and processes.

Monitoring also needs a response. An alert without an owner or retraining process merely announces failure. MLOps closes the loop by defining the trigger, owner, replacement test, and rollback path.

## Exam questions become easier when you diagnose before choosing

AIF-C01 lifecycle questions are often symptom-shaped. First locate the symptom: data preparation, development, pre-launch evaluation, deployment, or live monitoring.

Next, read its time signature. Immediate failure suggests data, features, training, tuning, or evaluation. A model that worked and later degraded suggests a production change, especially drift.

Then identify what changed. Changed code suggests a release issue. A changed model artifact suggests deployment or versioning. Unchanged code and model, combined with shifted inputs and rising error, point to drift.

Finally, name the feedback loop and action. A failed success metric before launch returns to model development. Drift after launch returns to data preparation and retraining.

![Diagnosis moves from symptom and stage through timing and changes to the correct feedback loop.](visuals/visual-06.svg)

*A stage-first diagnosis narrows the cause before selecting a lifecycle action.*

Metrics follow the same discipline. Accuracy suits balanced classes but can conceal failure when one class dominates. Precision matters when false positives are costly; recall matters when false negatives are dangerous; F1 addresses both concerns for imbalanced classes.

These model metrics do not answer whether the project was worth building. That requires business measures such as cost, customer feedback, or return. A valid model metric is still a distractor when the question asks about business value.

## Key takeaways

- Learn each lifecycle stage by its output, not merely its activity.
- EDA looks; pre-processing changes; feature engineering creates useful inputs.
- Training learns parameters, while tuning selects settings governing learning.
- Evaluation occurs before deployment; monitoring observes the live system afterward.
- Failed evaluation loops to development; production drift loops to data preparation and retraining.
- Match AWS services to their stages before assessing their capabilities.
- Custom training requires a real need plus labeled data and skills.
- Managed and self-hosted serving trade operational burden against control.
- MLOps adds experimentation, repeatability, scalability, debt management, production readiness, monitoring, and retraining.
- Diagnose the lifecycle stage before accepting an otherwise plausible AIF-C01 answer.

This framework settles where lifecycle activities and stage-specific services belong, and what MLOps adds after a model first works. It does not determine the right data, architecture, metric threshold, or operating constraint for every system; those choices still depend on the task and the cost of being wrong.