For ML and MLOps engineers, data engineers moving into ML, and backend or DevOps engineers who operationalize models. MLA-C01 validates that you can take a machine learning model from raw data to a monitored, secured, production-grade deployment on AWS.
Unlike the retired Specialty exam (MLS-C01), which leaned heavily on ML theory and algorithm math, MLA-C01 is an engineering exam: it assumes you already know what a model is and instead tests whether you can build the pipelines, endpoints, CI/CD workflows, monitoring, and guardrails around it — mostly with Amazon SageMaker AI at the center.
AWS recommends at least one year of experience with SageMaker and related AWS services, but a disciplined candidate with strong general AWS knowledge (an Associate-level cert helps) and hands-on SageMaker practice can pass. Expect scenario questions of the form "a company needs X under constraint Y — which approach?" where two answers are plausible and the constraint (cost, latency, compliance, operational overhead) decides the winner.
| Exam Fact | Detail |
|---|---|
| Exam code | MLA-C01 |
| Questions | 65 total (50 scored + 15 unscored pretest) |
| Duration | 130 minutes |
| Passing score | 720 / 1000 (~72%), compensatory scoring across domains |
| Cost | $150 USD (as of July 2026) |
| Question formats | Multiple choice (1 of 4), multiple response (2+ of 5+), ordering, matching, case study |
| Validity | 3 years |
| Delivery | Pearson VUE — testing center or online proctored |
MLA-C01 introduced new question types to AWS exams: ordering (arrange steps in the correct sequence), matching (pair items from two lists), and case studies (one scenario feeding several independent questions). Ordering questions love pipeline sequences — ingest → transform → train → register → deploy → monitor — so know the canonical ML lifecycle order cold.
The guide is organized into four parts that mirror the official exam domains exactly, in official order and weight. Study Parts 1 and 4 hardest — together Data Preparation (28%) and Monitoring/Security (24%) are more than half the exam, and they are the areas SageMaker-focused courses cover most thinly.
Callouts flag material worth extra attention:
Work through each part, then use the Exam-Day Checklist as a rapid-review sheet in your final 48 hours.
This is the heaviest domain. It covers ingesting, storing, transforming, labeling, validating, and protecting data before it ever reaches a training job.
ML pipelines on AWS revolve around six formats, and the exam expects you to pick the right one from a scenario:
| Format | Type | Best for | Key property |
|---|---|---|---|
| CSV | Row-based text | Small tabular data, human inspection, broad tool support | No schema, no compression by default, parses slowly at scale |
| JSON / JSON Lines | Row-based text | Semi-structured/nested data, API payloads, streaming records | Self-describing but verbose; JSONL is the streaming-friendly variant |
| Parquet | Columnar binary | Analytics and feature selection over wide tables (Athena, Glue, EMR) | Column pruning + compression = read only the columns you need |
| ORC | Columnar binary | Hive/EMR-centric analytics workloads | Similar benefits to Parquet; strongest in the Hadoop ecosystem |
| Avro | Row-based binary | Streaming and record-at-a-time ingestion (Kafka pipelines) | Embedded schema with strong schema-evolution support |
| RecordIO (protobuf) | Row-based binary | SageMaker built-in algorithms in Pipe mode | SageMaker's optimized training format; streams data instead of copying it |
Decision logic: columnar (Parquet/ORC) for analytical reads that touch few columns of many rows; row-based (Avro/JSONL/RecordIO) for write-heavy streaming or sequential full-record reads. Converting CSV data lakes to Parquet routinely cuts Athena/Glue scan costs by 80%+ because queries scan only referenced columns.
If a question mentions SageMaker Pipe mode (streaming training data from S3 rather than downloading it first to speed job startup and cut EBS needs), the paired format is RecordIO-protobuf. If it mentions reducing Athena query cost on a large tabular dataset, the answer is almost always "convert to Parquet with compression."
Training jobs need to read data from somewhere, and the exam tests the trade-offs:
| Storage | Access model | Latency/throughput profile | Typical ML use |
|---|---|---|---|
| Amazon S3 | Object API (also File mode, Fast File mode, Pipe mode into SageMaker) | High throughput, higher per-request latency; effectively unlimited scale, cheapest | Default for datasets, model artifacts, feature files |
| Amazon EFS | POSIX file system, NFS, multi-AZ, elastic | Moderate throughput, shared concurrent access | SageMaker Studio home directories; shared notebooks and code across users |
| Amazon FSx for Lustre | POSIX high-performance parallel file system, links to an S3 bucket | Sub-millisecond latency, hundreds of GB/s | Repeated-epoch training on massive datasets; distributed GPU training that would otherwise wait on S3 downloads |
FSx for Lustre can be linked to an S3 bucket and lazily loads objects on first read, so you keep S3 as the system of record while training reads at file-system speed. Use it when the same large dataset is read repeatedly (many epochs, many experiments) and S3 File mode download time dominates job duration. For most workloads, S3 with Fast File mode (on-demand streaming with file-system semantics, no full download) is the cost-effective middle ground.
S3 is the default answer; FSx for Lustre is the answer when the scenario stresses "shortest training startup" or "highest throughput for repeated distributed training"; EFS is the answer when multiple users or instances need shared POSIX access to the same files.
For real-time data flowing into ML systems, know the division of labor:
A canonical exam pattern: clickstream events → Kinesis Data Streams → Managed Flink computes rolling features → writes to SageMaker Feature Store for low-latency inference lookup, while Firehose archives raw events to S3 for training.
Data Wrangler is the low-code data prep UI inside SageMaker Studio: connect to S3, Athena, Redshift, Snowflake and others; profile the data; apply 300+ built-in transforms (plus custom PySpark/pandas); check for target leakage and bias; then export the flow as a SageMaker Processing job, a Pipelines step, or directly into Feature Store. It is the "prepare data visually without writing ETL code" answer.
SageMaker Feature Store solves feature consistency between training and inference. Each feature group has two stores:
GetRecord lookups for real-time inference.Ingestion paths: PutRecord API for streaming writes (which can sync to both stores), batch ingestion from Data Wrangler or Spark, and the offline store filling asynchronously from online writes.
"Training/serving skew because the training pipeline and the inference service compute the same feature differently" — the fix is Feature Store: compute the feature once, serve it to training from the offline store and to inference from the online store.
Three tools, three personas — the exam tests which fits a scenario:
Outliers. Detect with z-scores (|z| > 3 under roughly normal data), IQR fences (below Q1 − 1.5·IQR or above Q3 + 1.5·IQR), or model-based detection (Random Cut Forest — available as a SageMaker built-in algorithm and inside Managed Flink for streaming anomaly detection). Treat by removing (if erroneous), capping/winsorizing (if legitimate but extreme), or applying transforms that compress the tail.
Missing values (imputation). Dropping rows is acceptable only when missingness is rare and random. Otherwise impute: mean/median for numeric (median when skewed), mode for categorical, or model-based approaches (k-NN imputation, MICE) when relationships between features matter. Adding a "was missing" indicator column preserves the signal that a value was absent — sometimes missingness itself is predictive.
Deduplication. Exact duplicates inflate the apparent size of the dataset and, worse, can leak across the train/test split so the model is graded on rows it memorized. Fuzzy duplicates (same entity, slightly different strings) call for AWS Glue FindMatches, an ML transform built for entity resolution/record linkage.
Tree-based models (XGBoost, Random Forest) are scale-invariant — they split on thresholds — so scaling is unnecessary for them. Distance- and gradient-based models need it.
"Trees don't care about scale; distances and gradients do." If the model is XGBoost, skip the standardization step; if it's k-means, k-NN, SVM, or a neural network, scale first.
Classic distractor pair: one-hot vs. label encoding. "Color = {red, green, blue} for a linear model" → one-hot. "Shirt size = {S, M, L, XL}" → ordinal/label encoding. High-cardinality "merchant ID with 50,000 values" → embeddings, hashing, or binary encoding — not one-hot.
SageMaker Ground Truth manages labeling jobs end to end: built-in task templates (image classification, object detection/bounding boxes, semantic segmentation, text classification, NER) plus custom templates. Workforce options, in rising privacy order: Amazon Mechanical Turk (public crowd — cheapest, never for confidential data), vendor workforces via AWS Marketplace, and a private workforce of your own employees (required for confidential, PII, or medical data). Its killer cost feature is automated data labeling (active learning): Ground Truth trains a model on early human labels and auto-labels high-confidence items, routing only ambiguous ones to humans — cutting labeling costs by up to ~70% on large datasets. Ground Truth Plus is the turnkey variant where AWS manages the workforce and workflow for you.
SageMaker Clarify computes pre-training bias metrics on the dataset (before any model exists). The two named in the exam guide:
Mitigation options: resampling (oversample the minority facet/class, e.g., SMOTE-style synthetic minority oversampling, or undersample the majority), generating synthetic data to fill under-represented segments, reweighting examples, or gathering more representative data. Clarify runs as a processing job, integrates with Data Wrangler's bias report, and (as you'll see in Parts 2 and 4) also handles post-training bias and explainability.
CI asks "is the group under-represented in the data?" DPL asks "does the group get favorable labels at a different rate?" A dataset can pass CI and still fail DPL — balanced representation with biased outcomes.
Validate before training: Glue Data Quality (rule-based DQDL checks on tables/pipelines) or Data Wrangler's Data Quality and Insights Report (missingness, cardinality, class imbalance, target leakage, duplicate rows). Catching a leaky feature here is far cheaper than after deployment.
Splitting: the standard is train/validation/test (e.g., 70/15/15 or 80/10/10) — validation for tuning decisions, test touched exactly once for the final unbiased estimate. Shuffle before splitting so ordered data (sorted by date or class) doesn't produce unrepresentative splits — but never shuffle time-series; split those chronologically (train on the past, validate on the future) to avoid lookahead leakage. Use stratified splitting for imbalanced classes so each split preserves class proportions, and k-fold cross-validation when data is scarce.
Augmentation expands training data without new collection: for images — flips, rotations, crops, color jitter; for text — synonym replacement, back-translation; for tabular imbalance — SMOTE. Augmentation is a regularizer (Part 2) and a bias-mitigation tool (fill under-represented facets) in one.
"Model performs great in validation but poorly in production, and the dataset was sorted by date before a random split" — the flaw is temporal leakage. Time-series must be split chronologically, never randomly shuffled.
This domain covers choosing a modeling approach, training and tuning it, and analyzing whether it's any good.
The exam's most repeatable decision rule: use a pre-trained AWS AI service when one matches the problem; build with SageMaker only when you need customization the service can't provide. Map problems to services instantly:
Between Bedrock and SageMaker JumpStart for foundation models: Bedrock = fully managed, pay-per-token, no infrastructure, fastest path, model choice limited to Bedrock's catalog. JumpStart = one-click deploy of open-weight models onto SageMaker endpoints in your account, giving full control over the model artifacts, instance types, network isolation, and deep fine-tuning — at the cost of managing (and paying for) the endpoint yourself.
Least operational overhead for a standard capability → AI service or Bedrock. Full control, custom/open-weight models, or strict "model must run inside our VPC on our instances" requirements → SageMaker (JumpStart or custom training).
Selection is a trade-off triangle: performance, interpretability, cost. Regulated use cases (credit decisions, healthcare) may require explainable models — linear/logistic regression and shallow decision trees are intrinsically interpretable; deep networks and large ensembles need post-hoc explanation (SHAP via Clarify). Cost-wise, a smaller classical model (XGBoost on CPU) that meets the accuracy bar beats a GPU-hungry deep model; foundation-model choices weigh per-token pricing (Bedrock) against endpoint-hours (JumpStart). When a question says "must explain individual decisions to a regulator," favor the interpretable model or add Clarify SHAP explanations — don't pick the black box on accuracy alone.
Know the flagship built-ins and their problem types:
Built-ins need no training code — point them at data with hyperparameters. SageMaker Autopilot / AutoML goes further: give it a tabular dataset and target, and it explores candidates and produces a leaderboard with explainability — the "no ML expertise on the team" answer.
An epoch is one full pass over the training set; a step (iteration) is one gradient update on one batch; batch size is examples per step. Their interplay is tested: steps per epoch = dataset size / batch size. Larger batches train faster per epoch and stabilize gradient estimates but can generalize worse and demand more accelerator memory (out-of-memory on GPU → reduce batch size, use gradient accumulation, or get a bigger instance). Learning rate is the most important hyperparameter overall, and larger batch sizes typically pair with larger learning rates.
Spot training questions hinge on one word: checkpoints. Any answer combining Managed Spot Training with checkpointing to S3 (checkpoint_s3_uri) beats an answer using Spot without checkpoints.
Overfitting: low training error, high validation error — the model memorized noise. Fixes: more data, augmentation, regularization, early stopping, simpler model, dropout, ensembling. Underfitting: high error on both — the model is too simple or under-trained. Fixes: more capacity, more features, longer training, less regularization. Regularization tools:
Catastrophic forgetting is the fine-tuning failure mode: continued training on a narrow new dataset overwrites the pre-trained model's general capabilities. Mitigate with lower learning rates, freezing early layers, mixing in original-domain data (rehearsal), parameter-efficient fine-tuning (adapters/LoRA — train small added weights, leave base weights frozen), or elastic weight consolidation.
"L1 = Lean (sparse, zeroes out features); L2 = Little (everything gets smaller, nothing hits zero)."
SageMaker Automatic Model Tuning (AMT) runs many training jobs over defined hyperparameter ranges to optimize a target metric. Strategies: grid search (exhaustive, only viable for tiny discrete spaces), random search (parallelizes perfectly, surprisingly strong baseline, wastes some budget), Bayesian optimization (builds a surrogate model of metric-vs-hyperparameters and picks the next promising configuration — fewer total jobs, but sequential by nature), and Hyperband (allocates budget dynamically, stopping poor configurations early — great for deep learning where partial training reveals a lot). AMT supports early stopping of underperforming jobs and warm start from previous tuning jobs.
from sagemaker.tuner import HyperparameterTuner, ContinuousParameter, IntegerParameter
tuner = HyperparameterTuner(
estimator=xgb_estimator,
objective_metric_name="validation:auc",
objective_type="Maximize",
hyperparameter_ranges={
"eta": ContinuousParameter(0.01, 0.3, scaling_type="Logarithmic"),
"max_depth": IntegerParameter(3, 10),
},
strategy="Bayesian",
max_jobs=30,
max_parallel_jobs=3,
early_stopping_type="Auto",
)
tuner.fit({"train": train_input, "validation": val_input})
"Minimize the total number of training jobs to reach a good result" → Bayesian. "Run everything in parallel, simple and scalable" → Random. "Cheaply eliminate bad configs early during long deep-learning training" → Hyperband.
SageMaker training climbs a ladder of customization:
train.py for a framework (TensorFlow, PyTorch, scikit-learn, XGBoost, Hugging Face); SageMaker supplies the managed framework container, injects hyperparameters as arguments, mounts channels at /opt/ml/input/data/<channel>, and expects the model saved to /opt/ml/model. This is the standard path for custom model code.Integrating externally built models: a model trained outside SageMaker (on-prem, another cloud, a laptop) deploys by packaging artifacts as a model.tar.gz in S3 with an inference container image (framework-provided or custom, with your inference.py handler), creating a SageMaker Model, and registering it in the Model Registry like any other. You do not need to retrain in SageMaker to host in SageMaker.
Fine-tuning (transfer learning) adapts a pre-trained model to your domain with far less data and compute than training from scratch. Practices the exam rewards: start from a JumpStart/Bedrock/Hugging Face pre-trained model; use a small learning rate (you're nudging, not re-learning); freeze early layers and retrain later/head layers for small datasets; watch validation metrics for both overfitting and catastrophic forgetting; consider parameter-efficient methods (LoRA/adapters) for large models. Bedrock supports managed fine-tuning (provide labeled examples, AWS handles the training) when you'd rather not run training infrastructure at all; contrast with continued pre-training (unlabeled domain text) and with RAG, which injects knowledge at query time without changing weights and is the right answer when the knowledge changes frequently.
For edge devices or latency/cost targets: pruning removes near-zero weights or whole channels; quantization stores weights in lower precision (FP32 → FP16/INT8) shrinking size ~2–4× with minimal accuracy loss; knowledge distillation trains a small "student" to mimic a large "teacher." SageMaker Neo compiles a trained model for a specific target (Inferentia, ARM, NVIDIA, edge devices), optimizing the graph for up to significantly faster inference with no accuracy loss — the exam's go-to for "optimize this model for edge hardware."
The Model Registry organizes models into Model Package Groups; each registered version carries its artifacts, container, metrics, and lineage, plus an approval status (PendingManualApproval → Approved / Rejected). Approval-status changes emit EventBridge events, which is precisely how CI/CD pipelines auto-deploy a model the moment a reviewer approves it (Part 3). Registry + SageMaker Lineage gives auditability: which data, which training job, which container produced the model now in production.
Classification metrics start with the confusion matrix (TP, FP, TN, FN):
| Metric | Formula | Optimize when |
|---|---|---|
| Accuracy | (TP+TN)/all | Classes balanced and errors cost the same |
| Precision | TP/(TP+FP) | False positives are costly (spam filter flagging real mail) |
| Recall | TP/(TP+FN) | False negatives are costly (missing fraud, missing cancer) |
| F1 | harmonic mean of P and R | Need balance of both under class imbalance |
| ROC AUC | area under TPR-vs-FPR curve | Threshold-independent ranking quality; misleading under extreme imbalance (prefer PR AUC there) |
| RMSE | √(mean squared error) | Regression; penalizes large errors quadratically (MAE treats all errors linearly) |
Accuracy is a trap under imbalance: a 99%-negative dataset gives a do-nothing model 99% accuracy. Establish a baseline before celebrating any model — majority-class or random baseline for classification, naive last-value/moving-average for forecasting, or a simple linear/heuristic model. A model that can't beat the baseline isn't worth deploying, and Model Monitor (Part 4) later uses a baseline in a second sense: a statistical snapshot of training data/quality to compare production against.
Map the scenario's expensive mistake to the metric: "cannot afford to miss a fraudulent transaction" → recall; "cannot afford to falsely accuse customers" → precision; "imbalanced classes, want one number" → F1; "regression, big errors are disproportionately bad" → RMSE.
Before full production traffic hits a new model, SageMaker supports a shadow variant: the endpoint copies live requests to the new model, whose responses are logged but never returned to callers. You compare metrics risk-free, then promote. Contrast with production variants (real A/B traffic splitting by weight, where users do see the challenger's responses — covered with monitoring in Part 4).
Two analysis tools round out development:
Debugger watches the training process; Clarify explains the model's predictions and bias; Model Monitor (Part 4) watches the deployed model over time. Match the tool to the lifecycle phase.
This domain is where ML meets DevOps: getting models into production repeatably, scalably, and safely.
The single most tested table in this exam:
| Option | Latency profile | Payload / time limits | Scales to zero? | Choose when |
|---|---|---|---|---|
| Real-time endpoint | Low ms, sustained | 6 MB payload, 60 s timeout | No — always-on instances | Steady or predictable traffic needing consistent low latency |
| Serverless Inference | Low ms after warm; cold starts possible | 4 MB payload, 60 s timeout | Yes — pay per request | Intermittent/spiky traffic with idle periods; tolerate cold starts; no GPU |
| Asynchronous Inference | Seconds–minutes, queued | Up to 1 GB payload, up to ~1 h processing | Yes — scale to zero when queue empties | Large payloads or long-running inference; near-real-time not required; SNS notification on completion |
| Batch Transform | Offline job | Entire datasets in S3 | N/A — no persistent endpoint | Periodic scoring of whole datasets; no endpoint needed at all |
Decision flow: no need for a persistent endpoint → Batch Transform. Large payloads (medical images, video) or minutes-long inference → Asynchronous. Idle-most-of-the-time traffic → Serverless. Continuous low-latency traffic → Real-time (with auto scaling).
Numbers to memorize: real-time = 6 MB / 60 s; serverless = 4 MB / 60 s / no GPUs; async = 1 GB / ~1 hour / queues requests and scales to zero. A "100 MB pathology image" instantly eliminates real-time and serverless.
Training deep networks → GPU instances (P-family for heavy training, G-family for cost-effective training/inference) or AWS Trainium (Trn1) for price-performance. Classical ML (XGBoost, linear models) trains happily on compute-optimized CPUs (C-family, M-family). Inference: many models serve fine on CPU; deep models needing acceleration use G-family GPUs or AWS Inferentia (Inf1/Inf2) for the best inference price-performance — pair with SageMaker Neo compilation. Rule of thumb the exam rewards: don't put a GPU behind an XGBoost endpoint, and don't train a large transformer on CPUs.
Every SageMaker training job and endpoint runs a container from Amazon ECR. Three tiers:
FROM the AWS image, RUN pip install extras. Choose when you need a few additional libraries./invocations (inference) and /ping (health) endpoints, and respond to docker run image serve.SageMaker Neo (from Part 2) fits here as the compile step before deploying to edge targets or Inferentia.
Many models, same framework, cost-sensitive → multi-model endpoint. Few models, different frameworks or a preprocessing chain → multi-container / inference pipeline.
Models can also serve from: AWS Lambda (package model in the function or a container image ≤10 GB — great for small models with sporadic traffic and native event integration), ECS/EKS (teams standardized on containers/Kubernetes who want cluster-level control; EKS for Kubernetes-native shops, ECS for simpler AWS-native orchestration), or edge devices (compile with Neo). SageMaker endpoints remain the default because they bundle auto scaling, variants, shadow tests, and Model Monitor for free; choosing K8s means rebuilding those capabilities yourself — a trade-off exam scenarios probe.
Real-time endpoints scale via Application Auto Scaling:
SageMakerVariantInvocationsPerInstance — at a target value; capacity follows traffic.Set sensible min (availability) and max (cost cap) instance counts, and remember scale-in is deliberately conservative to avoid flapping. Serverless and async options manage their own scaling (async can scale to zero by targeting the queue backlog).
import boto3
client = boto3.client("application-autoscaling")
client.register_scalable_target(
ServiceNamespace="sagemaker",
ResourceId="endpoint/my-endpoint/variant/AllTraffic",
ScalableDimension="sagemaker:variant:DesiredInstanceCount",
MinCapacity=2, MaxCapacity=10,
)
client.put_scaling_policy(
PolicyName="invocations-target",
ServiceNamespace="sagemaker",
ResourceId="endpoint/my-endpoint/variant/AllTraffic",
ScalableDimension="sagemaker:variant:DesiredInstanceCount",
PolicyType="TargetTrackingScaling",
TargetTrackingScalingPolicyConfiguration={
"TargetValue": 1000.0,
"PredefinedMetricSpecification": {
"PredefinedMetricType": "SageMakerVariantInvocationsPerInstance"
},
},
)
from sagemaker.workflow.pipeline import Pipeline
from sagemaker.workflow.steps import ProcessingStep, TrainingStep
pipeline = Pipeline(
name="churn-training-pipeline",
steps=[preprocess_step, train_step, eval_step, condition_register_step],
)
pipeline.upsert(role_arn=role)
pipeline.start()
Reproducible ML infrastructure means no console clicking: CloudFormation declares resources in YAML/JSON templates (endpoints, endpoint configs, models, pipelines are all supported resource types); the AWS CDK generates CloudFormation from real programming languages (Python/TypeScript), giving loops, conditionals, and reusable constructs — preferred by developer-centric teams. IaC benefits the exam expects you to articulate: identical dev/staging/prod environments, code-reviewed infrastructure changes, drift detection, and one-command rollback of infrastructure state. SageMaker Projects packages IaC + CI/CD into MLOps templates.
Resources:
ChurnEndpointConfig:
Type: AWS::SageMaker::EndpointConfig
Properties:
ProductionVariants:
- ModelName: !Ref ChurnModel
VariantName: AllTraffic
InstanceType: ml.m5.large
InitialInstanceCount: 2
ChurnEndpoint:
Type: AWS::SageMaker::Endpoint
Properties:
EndpointConfigName: !Ref ChurnEndpointConfig
Production ML traffic should not traverse the public internet. Interface VPC endpoints (AWS PrivateLink) for sagemaker.api and sagemaker.runtime let clients in a VPC invoke endpoints privately; a gateway endpoint covers S3. Training and processing jobs launched with a VPC configuration (subnets + security groups) plus EnableNetworkIsolation=True cannot reach the internet at all — the regulated-industry pattern. (IAM aspects continue in Part 4.)
The AWS-native chain: CodePipeline orchestrates stages; CodeBuild runs builds and tests (build the container, push to ECR, run unit tests, trigger the SageMaker pipeline); CodeDeploy manages progressive deployment with automatic rollback on alarms (for Lambda-based inference it shifts traffic canary/linear-style; SageMaker endpoints have native blue/green guardrails). Source stages hook GitHub or CodeConnections.
Git workflows: Gitflow (long-lived develop + release/hotfix branches — suits scheduled, versioned releases), GitHub Flow (short-lived feature branches merged to main behind PRs, deploy from main — suits continuous delivery, the common MLOps choice), and trunk-based development (tiny branches, very frequent merges — pairs with mature CI). For ML specifically: version code in Git, data and artifacts in S3 (with versioning), models in the Model Registry — Git alone can't hold 10 GB datasets.
Test layers in ML CI/CD: unit tests (transform functions, feature code, inference handler logic), integration tests (pipeline steps against real-ish services in staging; can the endpoint container serve a sample payload?), and end-to-end tests (run the whole pipeline on a data sample; validate the deployed staging endpoint's predictions and latency before production promotion). Add model-quality gates: block promotion if evaluation metrics fall below thresholds.
| Strategy | Mechanics | Strength | Cost/risk profile |
|---|---|---|---|
| Blue/green (all-at-once) | Stand up the new (green) fleet alongside old (blue); flip traffic; keep blue for instant rollback | Instant, clean rollback | Double capacity during the switch; all users exposed at once |
| Canary | Shift a small slice (e.g., 10%) to green, bake with alarms, then shift the rest | Limits blast radius to the canary slice | Slightly slower; needs good alarms to be meaningful |
| Linear | Shift traffic in equal steps (e.g., 10% every 5 minutes) with alarm checks between steps | Gradual, predictable exposure | Slowest; most alarm evaluations |
SageMaker's native deployment guardrails implement all three modes on endpoint updates (all-at-once, canary, linear traffic shifting) with auto-rollback on CloudWatch alarms. Remember the evaluation-vs-release distinction: shadow tests evaluate silently; canary/linear releases really expose users, gradually.
"Zero-downtime update with the fastest possible rollback" → blue/green. "Minimize the number of users affected if the new model is bad" → canary. "Shift gradually in fixed increments" → linear. If the scenario says users must never receive the new model's responses during evaluation, that's a shadow test, not a canary.
Amazon EventBridge is the glue: it can start a SageMaker Pipeline on a schedule (cron), when new data lands in S3 (via EventBridge-enabled bucket notifications), when a Model Monitor drift alarm fires, or when a Model Registry approval status changes (triggering the deployment pipeline). The full automated-retraining loop the exam wants you to assemble, in order:
Drift alarm → EventBridge → Pipelines → Registry → EventBridge → CodePipeline → guarded deployment. Ordering questions on MLA-C01 are built for this exact chain.
Models decay silently. This domain covers detecting that decay, running production ML economically, and securing the whole stack.
Model Monitor runs scheduled analyses against traffic captured from an endpoint (Data Capture logs request/response payloads to S3) and compares them to a baseline computed from the training set:
Violations are written to S3 and emitted as CloudWatch metrics → alarms → EventBridge → retraining pipeline (the Part 3 loop).
from sagemaker.model_monitor import DefaultModelMonitor, CronExpressionGenerator
monitor = DefaultModelMonitor(role=role, instance_count=1, instance_type="ml.m5.xlarge")
monitor.suggest_baseline(
baseline_dataset="s3://bucket/train.csv",
dataset_format={"csv": {"header": True}},
output_s3_uri="s3://bucket/baseline",
)
monitor.create_monitoring_schedule(
endpoint_input=endpoint_name,
schedule_cron_expression=CronExpressionGenerator.hourly(),
output_s3_uri="s3://bucket/monitor-reports",
)
Ground truth is the discriminator: Data Quality monitoring needs no labels (it compares input distributions), while Model Quality monitoring requires ground-truth labels merged with captured predictions. If the scenario says labels arrive weeks later, real-time accuracy monitoring is impossible — monitor data drift and attribution drift as leading indicators instead.
A SageMaker endpoint can host multiple production variants, splitting live traffic by weight (e.g., 90% champion / 10% challenger) — a true A/B test where users receive the challenger's responses (unlike shadow tests). Compare per-variant CloudWatch metrics and business KPIs, then shift weights gradually via UpdateEndpointWeightsAndCapacities without redeploying. Each variant can even run on different instance types, which doubles as a hardware A/B test.
For catching oddities beyond scheduled monitors: CloudWatch anomaly detection bands on any metric (invocations, latency) alarm on deviation from learned patterns without hand-set thresholds; Random Cut Forest (SageMaker built-in or in Managed Flink) scores streaming records for anomalies in-flight; Amazon Lookout for Metrics-style detection has largely folded into CloudWatch capabilities. The pattern to recognize: "alert when a metric deviates from its normal daily cycle, without defining a static threshold" → CloudWatch anomaly detection.
Endpoint health rests on CloudWatch metrics in two groups: invocation metrics (Invocations, InvocationsPerInstance, ModelLatency — time inside the container, OverheadLatency — SageMaker routing time, Invocation4XXErrors/5XXErrors) and instance metrics (CPUUtilization, MemoryUtilization, GPUUtilization, GPUMemoryUtilization, DiskUtilization). The observability toolkit:
"Trail = who, Watch = what." CloudTrail records who called which API; CloudWatch records what the system's metrics and logs are doing. Latency breakdown across microservice hops is X-Ray.
ModelLatency → optimize the model (Neo, quantization), move to a faster instance/GPU, or scale out; high OverheadLatency → payload size and request handling; serverless cold starts → provisioned concurrency for Serverless Inference (keeps instances warm) just as Lambda's provisioned concurrency fixes Lambda cold starts; throttling/ThrottlingException → check and request service-quota increases (endpoint instance counts, TPS limits) in Service Quotas; also verify auto scaling min capacity isn't too low for traffic spikes (scale-out takes minutes — pre-warm with scheduled scaling for known peaks).Tools first: Cost Explorer (visualize/analyze historical spend, filter by service/tag, view amortized costs and rightsizing suggestions), AWS Budgets (proactive alerts when actual/forecast spend crosses thresholds — can trigger actions), Cost and Usage Report for granular line items, and Trusted Advisor (checks spanning cost optimization — idle resources, underutilized instances — plus security, fault tolerance, quotas). Tagging is the foundation of cost governance: enforce cost-allocation tags (team, project, environment) on SageMaker resources so Cost Explorer can attribute spend; use tag policies/SCPs to require them.
Purchasing options:
| Option | Discount | Commitment | Best ML fit |
|---|---|---|---|
| On-Demand | — | None | Unpredictable, short-lived workloads; default |
| Spot | Up to ~90% | None, but interruptible | Managed Spot Training with checkpointing; never for production endpoints |
| SageMaker Savings Plans | Up to ~64% | 1 or 3 years, $/hr commit | Steady, predictable endpoint + notebook + processing usage |
| Reserved capacity / EC2 RIs & Savings Plans | Up to ~72% | 1 or 3 years | Steady EC2-hosted (ECS/EKS) inference fleets |
Everyday cost hygiene the exam rewards: stop idle Studio notebooks (lifecycle configurations to auto-shutdown), use Serverless/Async inference for intermittent traffic instead of always-on endpoints, use multi-model endpoints to consolidate, batch-transform instead of persistent endpoints for offline scoring, and Spot for training.
Spot is for training, never for production endpoints — endpoints must not vanish on a two-minute interruption notice. Steady inference fleets get SageMaker Savings Plans; interruptible training gets Managed Spot + checkpoints.
SageMaker actions run under two identity layers: the user's IAM identity (who may call CreateTrainingJob) and the execution role SageMaker assumes to touch S3/ECR/CloudWatch on the job's behalf. Least privilege means scoping both: resource-level ARNs instead of *, condition keys (e.g., restrict sagemaker:InstanceTypes, require VPC config), and separate roles per pipeline stage (a training role that can read the training bucket cannot delete endpoints). SageMaker Role Manager generates least-privilege execution roles from personas (data scientist, MLOps engineer, compute roles) and ML activities — the fast, correct answer to "create appropriately scoped SageMaker roles without hand-writing policies." Related governance: Model Cards (document intended use, risk rating) and Model Dashboard (fleet-wide view of models and monitor status).
{
"Effect": "Allow",
"Action": ["s3:GetObject"],
"Resource": "arn:aws:s3:::ml-training-data/curated/*",
"Condition": {"StringEquals": {"aws:ResourceTag/project": "churn"}}
}
The hardened SageMaker pattern: launch Studio, training jobs, and endpoints into your VPC (specify subnets + security groups); use VPC-only mode for Studio; reach AWS services via interface VPC endpoints (SageMaker API/runtime, CloudWatch, ECR, STS) and an S3 gateway endpoint so no traffic touches the internet; place resources in private subnets (no route to an internet gateway); use security groups as instance-level stateful firewalls (allow only required ports between components) and NACLs at the subnet boundary; set EnableNetworkIsolation=True on training/inference containers to block all outbound calls from the container itself (the container can't exfiltrate data even if compromised). Endpoint policies on the VPC endpoints add a further "only these principals to these resources through this endpoint" control.
CI/CD pipelines are privileged automation, so secure them like production: store credentials in Secrets Manager or SSM Parameter Store (never in buildspecs or repos); give CodeBuild/CodePipeline roles least-privilege, stage-scoped permissions; scan container images (ECR image scanning) and dependencies in the build stage; require PR reviews and branch protection on the repos that trigger deploys; add manual approval actions before production stages; and sign/verify artifacts between stages. Audit everything: CloudTrail for control-plane API history (who approved the model package, who updated the endpoint — retain logs in a locked S3 bucket, ideally in a separate security account), CloudWatch Logs for build and pipeline execution logs, AWS Config to record configuration changes and flag non-compliant resources (e.g., an endpoint created without KMS encryption), and SageMaker lineage + Model Registry history as the ML-specific audit trail from data to deployed model.
Security questions on this exam nearly always resolve to one of four moves: scope the IAM role down (least privilege / Role Manager), move traffic into the VPC (private subnets + VPC endpoints + network isolation), encrypt with customer managed KMS keys, or prove it with logs (CloudTrail + Config). Pick the move that matches the stated gap.
Domain 1 — Data Preparation (28%)
Domain 2 — Model Development (26%)
Domain 3 — Deployment & Orchestration (22%)
/invocations, /ping. Neo for edge/Inferentia.InvocationsPerInstance = default scaling; scheduled scaling for known peaks.Domain 4 — Monitoring, Maintenance & Security (24%)
EnableNetworkIsolation; KMS everywhere; Secrets Manager in CI/CD; Config for compliance drift.