Certablo
← Knowledge Base

Machine Learning Lifecycle & MLOps

From framing a measurable problem through data preparation, training, evaluation, deployment, monitoring, feedback, and retraining—with the controls needed to make ML repeatable in production.

AIF-C01AIP-C01MLA-C01

Visual overview

AI / ML STACKChoose the highest-level capability that still gives the control the workload needs
AI SERVICESReady-made capabilityUse a managed API for an established task
GENERATIVE AIFoundation modelsPrompt · retrieve · guard · evaluate
CUSTOM MLModel lifecyclePrepare · train · deploy · monitor
AI architecture is not only model choice: data, evaluation, security, latency, cost, and governance shape the complete production system.
AWS SERVICE MAPA production ML loop

S3 persists datasets and artifacts, SageMaker AI executes ML lifecycle workloads, and CloudWatch supports operational observability.

Amazon S3Versioned data and model artifacts
Amazon SageMaker AIPrepare, train, and deploy
Amazon CloudWatchMetrics, logs, and alarms
EXAM-RELEVANT MECHANICS

Technical reference

Exact service features evolve, but the separation of data, training, evaluation, deployment, and monitoring remains stable.

Train setFit model parameters

The learner repeatedly uses training examples to optimize its objective.

Validation setChoose configuration

Supports hyperparameter, threshold, and model-selection decisions without consuming the final test evidence.

Test setFinal held-out estimate

Evaluate after model choices; repeated tuning against the test set turns it into another validation set.

DriftChange in data or model relationship

Input distribution drift and concept/target relationship change are different phenomena and need different evidence.

DeploymentReal-time / batch / async / serverless

Supported options and constraints vary by SageMaker capability; select from latency, payload, throughput, and utilization needs.

Service limits and capabilities can change. Values shown here reflect the current AWS documentation; use the linked official sources below as the source of truth.

Start with the decision and the data, not model training

A production ML lifecycle begins by defining the business decision, target output, acceptable error, constraints, and a measurable success criterion. Only then should a team collect and inspect representative data. Data preparation can include cleaning inconsistent values, handling missing information, transforming features, labeling examples, and separating data for training, validation, and final testing. Leakage—allowing information unavailable at real inference time into training—can create deceptively strong offline results.

Training fits model parameters; validation supports model and hyperparameter choices; a held-out test set provides a less biased final estimate after choices have been made. The exact split strategy depends on the problem. Random splits can be inappropriate for time-series data or entities whose repeated records would leak across partitions. Data provenance, schema, labeling rules, and dataset versions are therefore part of the model artifact's reproducibility story.

Deployment changes the question from accuracy to a system SLO

A model that performs well offline still needs an inference pattern that matches the application. Real-time endpoints are suited to low-latency request/response use, batch inference is suited to large offline datasets, and asynchronous or serverless patterns can fit other traffic profiles when supported. The production design must also account for request validation, feature availability, scaling, failure handling, model versions, rollback, and the cost of inference capacity.

MLOps applies software-engineering discipline to this lifecycle: reproducible processing and training, versioned artifacts, automated checks, deployment workflows, approvals, and observability. A pipeline is valuable not merely because it automates steps, but because it makes the same inputs and definitions produce traceable outputs. SageMaker AI supplies managed building blocks for processing, training, deployment and pipelines; other AWS services can provide storage, events, identity, logging, and monitoring around them.

Monitor inputs, outputs, infrastructure, and business outcomes

Production monitoring should distinguish operational health from model quality. Infrastructure metrics reveal latency, errors, throughput, and resource pressure. Data monitoring can detect feature distribution changes; model-quality monitoring requires ground-truth labels when available; business metrics reveal whether predictions still create value. Data drift does not necessarily imply model failure, and stable data does not guarantee that the relationship between inputs and targets has remained stable.

Monitoring leads to a feedback decision: investigate, recalibrate a threshold, update features, retrain, or replace the model. AWS documentation currently notes that SageMaker Model Monitor stopped accepting new customers on July 30, 2026, while existing customers can continue using it. That makes the architectural principle more durable than one feature name: define measurable signals and automate observation using capabilities available to your account, including service metrics and CloudWatch where applicable.

Key takeaways

  1. 01

    Define a measurable business objective and error costs before selecting an algorithm.

  2. 02

    Keep training, validation, and final testing roles conceptually separate and prevent data leakage.

  3. 03

    Choose an inference pattern from latency, traffic shape, payload, and cost requirements.

  4. 04

    MLOps emphasizes reproducibility, versioning, automation, approvals, observability, and safe iteration.

  5. 05

    Monitor system health, data behavior, model quality, and business outcomes as different signals.

Official AWS sources

Use these primary AWS resources for the source material behind this article and for deeper reference.