ML 開發生命週期

The ML development lifecycle is the nine-phase, end-to-end process that turns a business problem into a production machine-learning system that keeps earning its keep. For AIF-C01 candidates, mastering the ML development lifecycle vocabulary is the linchpin of Domain 1 task statement 1.3, and it quietly underpins questions in every other domain because every Amazon SageMaker service, every Bedrock fine-tuning decision, and every responsible AI control plugs into some phase of the ML development lifecycle.

This guide walks through every stage of the ML development lifecycle — business framing, data collection, data preparation, feature engineering, model training, evaluation, deployment, monitoring, and re-training — contrasts the ML development lifecycle with the traditional software development lifecycle (SDLC), explains the MLOps principles that automate the ML development lifecycle at scale, maps each phase to the correct AWS service, and shows where responsible AI checkpoints belong. By the end you will read any AIF-C01 ML development lifecycle question and immediately identify the phase the scenario is targeting.

What Is the ML Development Lifecycle?

The ML development lifecycle is the structured sequence of phases an organization follows to design, build, validate, deploy, operate, and maintain a machine-learning model. Unlike a one-off data-science notebook experiment, the ML development lifecycle treats models as long-lived production assets that must be versioned, monitored, retrained, and eventually retired. Amazon SageMaker documentation and the AWS Machine Learning Lens formalize the ML development lifecycle into phases that are directly examinable on AIF-C01.

At the most abstract level the ML development lifecycle rests on three recurring ideas:

1. Data-first — a model is only as good as the data that trained it, so four of the nine ML development lifecycle phases revolve around data.
2. Evaluation gates — every phase of the ML development lifecycle ends in a decision (ship / rework / abandon), not a handoff.
3. Closed loop — production monitoring feeds back into re-training, making the ML development lifecycle a loop rather than a waterfall.

Understanding the ML development lifecycle means being able to map any real-world scenario ("model accuracy dropped last week") to the correct phase ("monitoring detected drift — trigger re-training"). The AIF-C01 exam rarely asks for abstract definitions in isolation; instead it presents a symptom and asks which ML development lifecycle phase owns the fix.

Why the AIF-C01 Exam Cares About This Topic

AIF-C01 is a foundational AI certification, but Domain 1 allocates 20% of the exam to ML and AI fundamentals, and task statement 1.3 ("Describe the ML development lifecycle") is one of three pillars inside that domain. Expect 4 to 6 questions in the 65-question AIF-C01 exam to hinge directly on ML development lifecycle phase identification. Candidates who memorize the exact phase names avoid the most common trap: choosing a plausible but non-canonical phrase like "data validation" when AWS calls the phase "data preparation."

How This Topic Connects to the Rest of AIF-C01

The ML development lifecycle conversation does not live in isolation. It is the conceptual root of:

• Amazon SageMaker platform knowledge (every SageMaker capability maps to one or more phases)
• Foundation model evaluation (the evaluation phase specialized to FMs)
• Responsible AI tools (Clarify, Model Monitor, A2I slot into specific phases)
• Fine-tuning vs in-context learning (fine-tuning is a specialized re-training loop)

ML Development Lifecycle vs Software Development Lifecycle (SDLC)

Traditional software has a single artifact — code — and a linear change cycle driven by human requirements. The ML development lifecycle has three entangled artifacts — code, data, and the trained model — and its change cycle can be triggered by data shifts the team never wrote code for. AIF-C01 frequently tests this distinction because candidates from a software-engineering background often misapply SDLC intuition.

Three Artifacts, Not One

In the SDLC the only versioned artifact is source code. In the ML development lifecycle three artifacts must be versioned together:

• Code (training scripts, feature pipelines, inference logic)
• Data (training dataset, validation dataset, label definitions)
• Model (trained weights, hyperparameters, evaluation metrics)

A reproducible training run requires all three at the same revision. The SageMaker Model Registry and SageMaker ML Lineage Tracking exist specifically to close this gap.

Non-Deterministic Outputs

Traditional software produces the same output for the same input. The ML development lifecycle produces probabilistic outputs: the same model given the same user query may answer differently after re-training, even if the code did not change. Testing in the ML development lifecycle is therefore statistical (accuracy thresholds, confusion matrices) rather than pass/fail unit tests.

Decay Over Time

Software does not rot when the world changes; a deployed ML model does. The ML development lifecycle must monitor for data drift and model drift — phenomena with no analogue in SDLC. Re-training is not an enhancement; it is preventive maintenance.

Data Dependency

SDLC deployments require binaries and config. ML development lifecycle deployments require a training dataset's integrity, labeling quality, and privacy compliance all to be provable months after the model shipped. Data lineage is therefore a first-class concern in the ML development lifecycle, unlike in SDLC.

白話文解釋 ML Development Lifecycle

The ML development lifecycle becomes obvious when you stop thinking about gradient descent and start thinking about everyday processes. Four distinct analogies make the phases of the ML development lifecycle unforgettable.

The Restaurant Kitchen Analogy

Opening a restaurant is not cooking a single dish. It is a lifecycle: decide on the concept (business framing), source ingredients from suppliers (data collection), wash and chop the produce (data preparation), combine ingredients into a recipe (feature engineering), cook the dish (model training), taste it before plating (evaluation), serve it to customers (deployment), watch reviews and health inspections (monitoring), and adjust the menu when local tastes change or ingredients go out of season (re-training). Every phase of the ML development lifecycle has a direct counterpart in the restaurant kitchen analogy. Skip the tasting step and the diners discover the salt; skip the health inspection and the restaurant closes. The ML development lifecycle is the same: skip evaluation and the model embarrasses you in production, skip monitoring and the model silently rots.

The Library Cataloguing Analogy

A public library does not just buy books — it runs a continuous cycle. Librarians decide which subjects to acquire (business framing), buy books from publishers (data collection), inspect, clean, and repair bindings (data preparation), add metadata like genre tags and Dewey decimal codes (feature engineering), train catalog staff on the new collection (model training), check that searches actually return relevant results (evaluation), open the shelves to patrons (deployment), track which books get returned damaged or go missing (monitoring), and re-order replacement copies and retire obsolete editions (re-training). The ML development lifecycle is the library cycle applied to predictions instead of books.

The Car Manufacturing Plus Maintenance Analogy

Building a car is only half the ML development lifecycle. The full lifecycle also includes decades of maintenance. Engineers define a target market (business framing), procure steel and parts (data collection), inspect for defects (data preparation), assemble subsystems (feature engineering), roll the car off the line (model training), crash-test it (evaluation), ship it to dealerships (deployment), monitor recalls and real-world failures (monitoring), and issue firmware updates or hardware refreshes (re-training). The ML development lifecycle phase of "monitoring and re-training" is the reason cars do not ship once and stay perfect; the same is true of models.

Which Analogy to Use on Exam Day

All three analogies describe the same ML development lifecycle from different angles. Pick the one that resonates with the scenario wording:

• Scenario about recipe experimentation, iteration, tasting before shipping → restaurant kitchen analogy
• Scenario about cataloguing, labels, organization of raw inputs → library cataloguing analogy
• Scenario about long-term maintenance, drift, recall, retraining → car manufacturing analogy

Core Working Principles: The Nine Phases of the ML Development Lifecycle

The ML development lifecycle is canonically expressed as a sequence of nine phases in the SageMaker documentation and AWS Machine Learning Lens. AIF-C01 questions quote these phase names almost verbatim, so learning the exact wording is the highest-leverage study task.

Phase 1: Business Problem Framing

The ML development lifecycle starts with a business problem, not a dataset. Before writing any code, the team must decide whether ML is even the right tool. Key questions: What decision is being made? What is the cost of a wrong prediction versus a missed prediction? Is the ground truth observable? Is there enough historical data? Many ML development lifecycle failures trace back to skipping this phase and starting from data that happened to be available.

Deliverables of phase 1 include the problem type (classification, regression, clustering, generation), a success metric aligned with the business outcome (e.g., "reduce customer churn by 5 percentage points"), and explicit non-goals.

Phase 2: Data Collection

Once the problem is framed, the ML development lifecycle moves to acquiring the raw material: data. Sources include transactional databases, application logs, third-party data feeds, human-labeled datasets, and publicly available corpora. For supervised learning, the collection phase must include labels; for unsupervised learning, raw data is enough; for generative AI, domain documents for RAG grounding or fine-tuning pairs for instruction tuning.

AWS services in play: Amazon S3 as the canonical data lake, AWS Glue for ingestion, Amazon SageMaker Ground Truth for managed data labeling (human and ML-assisted), and Amazon Kinesis / Amazon MSK for streaming data.

Phase 3: Data Preparation (Cleaning and Transformation)

Raw data is dirty. The data preparation phase of the ML development lifecycle cleans missing values, removes duplicates, normalizes units, standardizes formats, balances class distributions, and splits the dataset into training, validation, and test subsets. This phase typically consumes 60-80% of a data scientist's time and is the most-tested phase on AIF-C01 because every trap question about "the model performs worse on one demographic" traces back to a data-preparation failure.

AWS services in play: Amazon SageMaker Data Wrangler (low-code data preparation with 300+ built-in transformations), AWS Glue DataBrew (visual data cleaning), and Amazon Athena for SQL-based exploration.

Phase 4: Feature Engineering

Feature engineering is the creative art of turning raw data into informative inputs. A timestamp becomes day-of-week plus hour-of-day plus is-holiday. A free-text address becomes ZIP code plus city tier plus distance-to-nearest-store. A user's purchase history becomes a rolling 30-day average basket size. In the ML development lifecycle, feature engineering often has more impact on final accuracy than the choice of algorithm.

AWS services in play: Amazon SageMaker Feature Store (centralized, versioned feature repository shared between training and inference), SageMaker Data Wrangler (ships its engineered features directly to Feature Store), and AWS Lambda for real-time feature computation.

Phase 5: Model Training

With prepared features in hand, the ML development lifecycle enters model training. The team chooses an algorithm or foundation model, selects hyperparameters, allocates compute (CPU, GPU, or AWS Trainium), and runs training jobs. Training may iterate dozens of times as hyperparameters are tuned. For foundation models, this phase includes pre-training, continued pre-training, fine-tuning, or RLHF (reinforcement learning from human feedback).

AWS services in play: Amazon SageMaker Training Jobs (managed distributed training), SageMaker JumpStart (pre-trained models and solution templates), SageMaker Automatic Model Tuning (Bayesian hyperparameter search), SageMaker Experiments (track every training run's parameters and metrics), and Amazon Bedrock fine-tuning for supported foundation models.

Phase 6: Model Evaluation

Training produces weights; the ML development lifecycle does not trust those weights until they are evaluated on held-out data. Evaluation metrics depend on the task: accuracy, precision, recall, F1, AUC-ROC for classification; MAE, RMSE, R² for regression; ROUGE, BLEU, BERTScore, perplexity for text generation; inception score and FID for image generation. Evaluation also includes fairness metrics across demographic groups — a responsible AI checkpoint.

AWS services in play: Amazon SageMaker Clarify (bias detection and explainability), Amazon Bedrock Model Evaluation (automated and human evaluation jobs for FMs), and SageMaker Experiments for comparing runs.

Phase 7: Deployment

A validated model must reach users. The ML development lifecycle deployment phase covers packaging, hosting, exposing an inference API, and routing traffic. Deployment patterns include real-time endpoints (low latency, always on), batch transform (scheduled scoring of large datasets), serverless inference (for spiky low-volume workloads), and asynchronous inference (for long-running predictions up to 1 GB payloads).

Progressive rollout strategies guard against bad deploys: canary (route 5% of traffic to the new model, watch metrics, then expand), blue-green (stand up the new version alongside the old, flip all traffic atomically), and shadow deployment (mirror traffic to the new model but return the old model's answers to users while comparing).

AWS services in play: Amazon SageMaker Endpoints (real-time, serverless, async, batch), Amazon Bedrock for managed FM inference, SageMaker Model Registry (approve and track deployable model versions), and AWS CodePipeline for deployment automation.

Phase 8: Monitoring

Once a model is live, the ML development lifecycle enters continuous monitoring. The model is watched for four distinct failure modes:

• Data quality drift — input distributions shift away from the training baseline
• Model quality drift — prediction accuracy degrades against a feedback signal
• Bias drift — fairness metrics diverge across demographic groups
• Feature attribution drift — explanations shift, suggesting the model has learned new patterns that may be spurious

Monitoring is not optional — it is the phase that converts the ML development lifecycle from a waterfall into a loop.

AWS services in play: Amazon SageMaker Model Monitor (the canonical service, with four monitor types matching the four drift categories), Amazon CloudWatch for operational metrics (latency, error rate, invocations), and AWS Lambda for custom monitoring logic.

Phase 9: Re-Training

When monitoring signals that a model has drifted beyond tolerance, the ML development lifecycle loops back. Re-training may be triggered on a schedule (monthly, quarterly), on drift thresholds (accuracy drops 2 points), or on concept changes (a new product category launches). Re-training is not a one-off event; in mature MLOps shops it is a fully automated pipeline that re-executes every phase of the ML development lifecycle on fresh data.

AWS services in play: Amazon SageMaker Pipelines (the canonical orchestration service for automated re-training workflows), AWS Step Functions for custom orchestration, and Amazon EventBridge for event-driven retraining triggers.

How the Nine Phases Group into Three Clusters

It helps to cluster the nine phases of the ML development lifecycle into three meta-stages for memorization:

• Data cluster: phases 1-4 (business framing, collection, preparation, feature engineering)
• Model cluster: phases 5-6 (training, evaluation)
• Operations cluster: phases 7-9 (deployment, monitoring, re-training)

AIF-C01 rarely tests transitions within a cluster; it heavily tests transitions between clusters (especially data-to-model and evaluation-to-deployment).

MLOps: Operationalizing the ML Development Lifecycle

MLOps is the discipline of automating the ML development lifecycle so that re-training, re-evaluation, and re-deployment happen reliably at the speed the business needs. AIF-C01 expects conceptual familiarity with MLOps principles even though the deep implementation questions belong to AIP-C01.

CI/CD for Models — Not Just for Code

In traditional software CI/CD, a code commit triggers unit tests, build, and deploy. In MLOps, a code commit, a data-version change, or a drift alert can trigger the same pipeline. The pipeline re-runs the ML development lifecycle phases — data prep, training, evaluation, deployment — end to end. Amazon SageMaker Pipelines is the AWS-native service built around this idea, with each pipeline step producing tracked artifacts (dataset version, model version, evaluation report).

Versioning Everything

MLOps mandates that every artifact in the ML development lifecycle be versioned together:

• Source code → Git (AWS CodeCommit, GitHub)
• Training datasets → S3 versioning, Feature Store versions, LakeFS, or DVC
• Trained models → SageMaker Model Registry (with semantic versions, approval states, and lineage)
• Configurations → code-as-infrastructure (AWS CDK, Terraform, CloudFormation)

Without synchronized versioning across all three artifacts, reproducing a production incident becomes impossible.

Reproducibility

A reproducible ML development lifecycle pipeline means the same code + data + hyperparameters + random seed produces the same model weights and the same evaluation metrics, months later. Reproducibility is non-negotiable for regulated industries (finance, healthcare) where audits demand re-running historical training jobs. SageMaker ML Lineage Tracking captures the DAG of data, code, training jobs, and model artifacts for later replay.

Automation and Orchestration

Manual steps are the enemy of the ML development lifecycle. MLOps replaces manual steps with:

• Orchestration (SageMaker Pipelines, Step Functions, Airflow on EC2) to chain phases
• Scheduled triggers (EventBridge cron) to retrain on cadence
• Drift-based triggers (Model Monitor → EventBridge → Pipeline execution) to retrain on signal
• Approval gates (Model Registry approval workflows) where human oversight is required

Continuous Training (CT) vs Continuous Integration (CI) vs Continuous Deployment (CD)

MLOps adds a new C to the DevOps vocabulary:

• CI — tests the code (as in traditional DevOps)
• CD — automates the deployment (as in traditional DevOps)
• CT — continuous training: automated re-training as part of the ML development lifecycle loop

AWS Services Mapped to Each Phase of the ML Development Lifecycle

AIF-C01 tests service-to-phase mapping frequently. Memorize the canonical tool for each phase of the ML development lifecycle and the common distractors.

Data Collection Phase Services

• Amazon S3 — raw storage
• AWS Glue — ETL jobs and data cataloguing
• Amazon SageMaker Ground Truth — managed human labeling (SageMaker Ground Truth Plus is the fully-managed variant)
• Amazon Kinesis / Amazon MSK — streaming ingestion
• Amazon AppFlow — SaaS-to-AWS data transfer (Salesforce, ServiceNow)

Data Preparation Phase Services

• Amazon SageMaker Data Wrangler — the canonical low-code data-prep tool; 300+ built-in transforms
• AWS Glue DataBrew — visual data cleaning for business analysts
• Amazon Athena — serverless SQL for exploration
• Amazon EMR — Spark/Hadoop at scale

Feature Engineering Phase Services

• Amazon SageMaker Feature Store — centralized feature repository, online and offline stores
• SageMaker Data Wrangler — exports engineered features to Feature Store
• AWS Lambda — real-time feature computation at inference time

Training Phase Services

• Amazon SageMaker Training Jobs — managed distributed training on CPU, GPU, Trainium
• SageMaker JumpStart — pre-trained models and solution templates; the entry point for foundation-model fine-tuning
• SageMaker Automatic Model Tuning (Hyperparameter Tuning) — Bayesian search for best hyperparameters
• SageMaker Experiments — tracks runs, parameters, metrics, artifacts
• SageMaker Studio — the IDE where training is authored and debugged
• SageMaker Canvas — no-code AutoML for business users
• Amazon Bedrock fine-tuning — managed fine-tuning for supported foundation models

Evaluation Phase Services

• Amazon SageMaker Clarify — bias detection (pre-training and post-training) and SHAP-based explainability
• Amazon Bedrock Model Evaluation — automated and human evaluation jobs for FMs
• SageMaker Experiments — compare metrics across runs

Deployment Phase Services

• Amazon SageMaker Endpoints — real-time, serverless, async, and batch transform inference
• Amazon SageMaker Model Registry — approval gate; stores deployable model versions with lineage
• Amazon Bedrock — managed inference for foundation models (no endpoint management)
• Amazon SageMaker Multi-Model Endpoints — host many models behind one endpoint for cost efficiency

Monitoring Phase Services

• Amazon SageMaker Model Monitor — four monitor types: data quality, model quality, bias drift, feature attribution drift
• Amazon CloudWatch — operational metrics (latency, error rate, throttles)
• AWS CloudTrail — API call audit trail for governance

Re-Training Phase Services

• Amazon SageMaker Pipelines — the canonical orchestration service; DAG of steps across the ML development lifecycle
• Amazon EventBridge — drift-triggered or schedule-triggered retraining events
• AWS Step Functions — custom orchestration beyond SageMaker Pipelines

Model Drift and Data Drift Detection

The ML development lifecycle is a loop specifically because models decay. Two distinct decay phenomena get tested on AIF-C01, and candidates routinely confuse them.

Data Drift (Covariate Shift)

Data drift occurs when the distribution of the INPUT features changes over time. The model still predicts well on data that looks like training data; the problem is that production inputs no longer look like training data. Example: a credit-scoring model trained pre-2020 now sees applicants whose remote-work income patterns differ from branch-office salary patterns.

Data drift is measurable WITHOUT ground-truth labels — you just compare input distributions. Amazon SageMaker Model Monitor's "data quality" monitor handles this by comparing live input statistics to a training-time baseline.

Model Drift (Concept Drift)

Model drift occurs when the RELATIONSHIP between features and the label changes. Inputs may look identical to training data, but the correct answer is different now. Example: a fraud-detection model sees the same transaction patterns, but the definition of "fraudulent" has evolved as fraudsters adapt.

Model drift is measurable only WITH ground-truth labels from production (feedback loops, human review, or delayed ground truth). SageMaker Model Monitor's "model quality" monitor handles this.

Bias Drift and Feature Attribution Drift

Two subtler drift categories round out the ML development lifecycle monitoring story:

• Bias drift — fairness metrics diverge across demographic groups post-deployment (measured by SageMaker Model Monitor's bias monitor, backed by Clarify)
• Feature attribution drift — the features the model relies on most have shifted, suggesting it has learned spurious new patterns (measured by Model Monitor's explainability monitor, also backed by Clarify)

Memorize the Four Drift Types

Detection Cadence and Re-Training Trigger Design

Not every drift event should trigger retraining. The ML development lifecycle design decision is the tolerance threshold:

• Too sensitive → constant retraining, compute cost explodes, production models flap
• Too loose → user experience degrades before the team reacts

Mature MLOps pipelines set different thresholds for different drift types (e.g., accuracy drop of >2 points triggers retraining; data drift alone triggers investigation).

Responsible AI Checkpoints Along the ML Development Lifecycle

Responsible AI is not a separate lifecycle; it is a set of checkpoints woven into the ML development lifecycle. AIF-C01 Domain 4 tests candidates on where those checkpoints belong.

Checkpoint 1: Business Framing — Harm Analysis

Before any data is collected, the business-framing phase of the ML development lifecycle must answer: who could be harmed by a wrong prediction? Is the use case high-risk under the EU AI Act? Does the decision affect access to credit, housing, employment, or healthcare? The output is a risk tier that governs downstream rigor.

Checkpoint 2: Data Collection — Consent, Provenance, and PII

The data-collection phase must verify consent for personal data, document provenance (where did each dataset come from, under what license), and detect PII. Amazon Macie scans S3 for PII before the data feeds training. Amazon Comprehend detects PII inside free-text documents.

Checkpoint 3: Data Preparation — Representation Audits

Before training, the ML development lifecycle must audit the dataset for under-represented groups. SageMaker Clarify's pre-training bias report computes metrics like class imbalance, Kullback-Leibler divergence between demographic groups, and label imbalance. Catching bias here is orders of magnitude cheaper than catching it after deployment.

Checkpoint 4: Model Training — Instruction Tuning and RLHF

For foundation models, the training phase of the ML development lifecycle includes alignment: instruction tuning teaches the model to follow instructions, and RLHF (reinforcement learning from human feedback) aligns it with human preferences. Both are responsible-AI controls embedded in the model itself.

Checkpoint 5: Evaluation — Fairness Metrics and Model Cards

Pre-deployment evaluation must compute fairness metrics alongside accuracy. SageMaker Clarify's post-training bias report computes disparate impact, equal opportunity, and demographic parity. SageMaker Model Cards produce a structured document capturing intended use, training data, evaluation results, and known limitations — the audit artifact for the ML development lifecycle.

Checkpoint 6: Deployment — Guardrails and Human-in-the-Loop

For generative AI, Amazon Bedrock Guardrails sit at deployment, filtering content, redacting PII, denying blocked topics, and running grounding checks. For any high-stakes inference, Amazon A2I (Augmented AI) routes low-confidence predictions to human reviewers — a responsible-AI checkpoint baked into the deployment phase of the ML development lifecycle.

Checkpoint 7: Monitoring — Bias Drift and Explainability Drift

Two of the four Model Monitor types are explicitly responsible-AI checkpoints running through the monitoring phase of the ML development lifecycle. Bias drift detection ensures fairness holds after deployment; feature attribution drift detection flags when the model starts relying on unexpected features (a potential sign of learned shortcuts or proxy discrimination).

Checkpoint 8: Re-Training — Approval Gates

The re-training phase of the ML development lifecycle must not auto-promote a model that passes accuracy checks but fails fairness checks. The SageMaker Model Registry supports approval workflows where a retrained model is "pending approval" until a responsible-AI reviewer signs off. This is the governance-layer gate of the ML development lifecycle.

Key Numbers and Limits to Memorize

AIF-C01 rewards candidates who memorize a handful of canonical numbers about the ML development lifecycle and its AWS tooling. The numbers below come directly from AWS documentation and the certification page.

Common Exam Traps for the ML Development Lifecycle

Several trap patterns appear consistently in AIF-C01 community exam reports. Each one concerns subtle wording in ML development lifecycle questions.

Other Frequently Missed Trap Patterns

• "Skipping the evaluation phase" is a classic AIF-C01 question framing. The answer is never "deploy faster without evaluation" — evaluation is a non-negotiable phase of the ML development lifecycle.
• "Feature Store ≠ Data Lake" — the Feature Store holds engineered features ready to serve; S3 holds raw data. Storing raw CSVs in Feature Store is an anti-pattern.
• "Ground Truth ≠ ground-truth labels" — Amazon SageMaker Ground Truth is the labeling service; "ground truth" lowercase means the true labels in any dataset. Read carefully.
• "Model Registry ≠ Model Monitor" — Registry is where approved model versions live; Monitor is the runtime drift detector.

ML Development Lifecycle vs Traditional Analytics Pipelines

A direct comparison clarifies what the ML development lifecycle replaces in organizations that previously relied on BI dashboards and SQL reports.

Output Type Comparison

Tooling Comparison

When Analytics Still Wins

The ML development lifecycle is heavier than traditional analytics. For questions that a well-indexed SQL query can answer on historical data, running an ML model is expensive overkill. The ML development lifecycle is justified when the decision must be made on new unseen data (predict churn before it happens, not measure it after) or when the rule is too complex to hand-author.

Question Links: AIF-C01 Task 1.3 Practice Pointers

AIF-C01 task statement 1.3 "Describe the ML development lifecycle" is most frequently exercised through phase-identification and service-mapping questions. The practice-question templates below represent the most common shapes. Detailed practice questions with full explanations appear in the ExamHub question bank.

Template A: Phase Identification from Symptom

A deployed model's accuracy has dropped 6 percentage points over the past month even though the code has not changed. Which phase of the ML development lifecycle owns the response? Expected answer: monitoring (detection) and re-training (response). Distractors typically include "model training" (wrong because training is where you go AFTER monitoring has confirmed drift) and "deployment" (wrong because the deployment is already live).

Template B: Service-to-Phase Matching

A team wants to label 100,000 images with bounding boxes for object detection. Which AWS service belongs to this phase of the ML development lifecycle? Expected answer: Amazon SageMaker Ground Truth (data collection / labeling). This question tests whether candidates confuse Ground Truth with Rekognition (which infers, not labels).

Template C: Drift Type Identification

A fraud-detection model's precision has dropped while the input transaction distributions look identical to training. Which drift type has likely occurred? Expected answer: model drift (concept drift) — the relationship between inputs and the fraud label has changed. Data drift is the common distractor.

Template D: MLOps Automation Scenario

A company wants every new commit to the training repository to automatically trigger data preparation, training, evaluation, and conditional deployment. Which AWS service orchestrates this? Expected answer: Amazon SageMaker Pipelines. AWS Step Functions is a valid but less specific distractor; Jenkins or CodePipeline are general-purpose alternatives without ML-native steps.

Template E: Responsible AI Checkpoint Placement

A regulated industry requires fairness to be verified before a model reaches production. Which phase of the ML development lifecycle owns this check, and which AWS service performs it? Expected answer: model evaluation phase, using Amazon SageMaker Clarify (post-training bias report). Extra credit: pre-training bias should ALSO be checked in the data preparation phase.

ML Development Lifecycle Frequently Asked Questions (FAQ)

What are the phases of the ML development lifecycle on AIF-C01?

The ML development lifecycle for AIF-C01 consists of nine canonical phases documented in the AWS Machine Learning Lens and SageMaker developer guide: business problem framing, data collection, data preparation, feature engineering, model training, model evaluation, deployment, monitoring, and re-training. AIF-C01 task statement 1.3 tests your ability to match symptoms and AWS services to these nine phases of the ML development lifecycle.

How is the ML development lifecycle different from the software development lifecycle?

The ML development lifecycle differs from the SDLC in three critical ways: it versions three artifacts (code + data + model), it produces probabilistic outputs rather than deterministic ones, and it decays over time due to data drift and concept drift. The ML development lifecycle is therefore a closed loop with monitoring and re-training phases that have no analogue in the SDLC.

How many phases are in the ML development lifecycle?

Nine. The canonical ML development lifecycle phases are framing, collection, preparation, feature engineering, training, evaluation, deployment, monitoring, and re-training. Some AWS documents compress these into fewer stages for brevity, but AIF-C01 exam questions align with the nine-phase decomposition from the SageMaker developer guide.

What is the difference between data drift and model drift?

Data drift (covariate shift) is a change in the distribution of input features over time; the relationship between inputs and labels may still be valid. Model drift (concept drift) is a change in the relationship between inputs and the target label; inputs may look identical to training data but the correct answer has changed. Both are monitored separately in the monitoring phase of the ML development lifecycle — data drift via SageMaker Model Monitor's data quality monitor (no labels required), model drift via the model quality monitor (labels required).

Do I need hands-on ML experience to pass AIF-C01 ML development lifecycle questions?

No. AIF-C01 is a foundational AI certification aimed at candidates with up to six months of AWS AI exposure, including non-engineering roles. The ML development lifecycle questions test conceptual vocabulary and service-to-phase mapping, not implementation depth. That said, running a free-tier SageMaker Studio notebook to train a built-in algorithm end-to-end strongly cements the lifecycle's shape in memory and is highly recommended.

How does MLOps relate to the ML development lifecycle?

MLOps is the automation layer that operationalizes the ML development lifecycle. Where the ML development lifecycle describes WHAT must happen (the nine phases), MLOps describes HOW to make those phases repeatable, reproducible, and automatable via CI/CD/CT pipelines, versioning of code + data + model, and drift-to-retrain closed loops. Amazon SageMaker Pipelines is the AWS-native MLOps orchestrator built around the ML development lifecycle.

Which SageMaker service goes with each phase of the ML development lifecycle?

A compact mapping: data collection → SageMaker Ground Truth; data preparation → SageMaker Data Wrangler; feature engineering → SageMaker Feature Store; training → SageMaker Training Jobs + JumpStart + Automatic Model Tuning; evaluation → SageMaker Clarify + Experiments (plus Bedrock Model Evaluation for FMs); deployment → SageMaker Endpoints + Model Registry; monitoring → SageMaker Model Monitor; re-training orchestration → SageMaker Pipelines. Memorizing this one-to-one mapping answers the majority of service-selection questions on AIF-C01.

Where do responsible AI checks fit in the ML development lifecycle?

Responsible AI is distributed across the ML development lifecycle as eight checkpoints rather than a single phase. Key checkpoints include: harm analysis in business framing, PII detection in data collection (Macie, Comprehend), pre-training bias in data preparation (Clarify), fairness metrics plus Model Cards in evaluation (Clarify), Guardrails plus A2I in deployment, and bias-drift monitoring in the monitoring phase (Model Monitor). The AIF-C01 exam heuristic is: catch responsible-AI issues as early in the ML development lifecycle as possible, because fixing them post-deployment is orders of magnitude more expensive.

How often should a model be re-trained?

There is no universal answer. The re-training phase of the ML development lifecycle is triggered by one of three signals: time (scheduled cadence like monthly or quarterly), drift (Model Monitor detects data or model quality degradation), or concept change (a new product launches, a regulation takes effect, seasonality shifts). Mature MLOps pipelines combine all three triggers via Amazon EventBridge rules routed to SageMaker Pipelines executions.

Further Reading

• Amazon SageMaker — Machine Learning Lifecycle Concepts: https://docs.aws.amazon.com/sagemaker/latest/dg/how-it-works-mlconcepts.html
• AWS Well-Architected Framework — Machine Learning Lens: https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/machine-learning-lens.html
• MLOps: Emerging Trends in Data, Code, and Infrastructure (AWS Whitepaper): https://docs.aws.amazon.com/whitepapers/latest/mlops-framework-to-operationalize-ml/mlops-framework-to-operationalize-ml.html
• Amazon SageMaker Pipelines: https://docs.aws.amazon.com/sagemaker/latest/dg/pipelines.html
• Amazon SageMaker Model Monitor: https://docs.aws.amazon.com/sagemaker/latest/dg/model-monitor.html
• Amazon SageMaker Clarify: https://docs.aws.amazon.com/sagemaker/latest/dg/clarify-fairness-and-explainability.html
• Amazon SageMaker Data Wrangler: https://docs.aws.amazon.com/sagemaker/latest/dg/data-wrangler.html
• Amazon SageMaker Feature Store: https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store.html
• Amazon SageMaker Ground Truth: https://docs.aws.amazon.com/sagemaker/latest/dg/sms.html
• Amazon SageMaker Model Registry: https://docs.aws.amazon.com/sagemaker/latest/dg/model-registry.html
• AWS AIF-C01 Certification Page: https://aws.amazon.com/certification/certified-ai-practitioner/

Related ExamHub topics: AI and ML Core Concepts, Supervised, Unsupervised, and Reinforcement Learning, Amazon SageMaker Platform, Foundation Model Evaluation.