AWS Certified Machine Learning Engineer – Associate (MLA-C02) Study Guide

AWS Certified Machine Learning Engineer – Associate (MLA-C02) Study Guide

Issuing body: Amazon Web Services (AWS) Jurisdiction: Global (vendor certification — not a legal license to practice) Level: Associate Prerequisites: Recommended 1+ year of ML experience on AWS; AI Practitioner suggested as warm-up. (Source: catalogue record data-ai-ml-cert-001.) Renewal: 3 years.

1. What this exam is

MLA-C02 is the current-generation AWS ML engineering credential. Important version note (from the catalogue, verified against the AWS Training & Certification blog "Certification updates: September 2026"): the beta exam (ME1-C02/MLA-C02) launched 2026-09-29; MLA-C01's last day in English was 2026-09-28; MLA-C02 general availability is expected early 2027, with full MLA-C01 retirement on 2027-01-14. If you're scheduling now, confirm whether you're taking the beta or GA version — beta exams have limited study materials and no published passing score. This guide targets the MLA-C02 blueprint while noting where beta-version details are unverifiable.

The exam tests the engineering of ML on AWS, not ML theory in the abstract: data preparation, model development, deployment, and MLOps on SageMaker and friends, plus the responsible-AI and security practices around them.

2. Pathway and exam format

• Typical path: AWS AI Practitioner (AIF-C01, the conceptual warm-up) → 1+ year hands-on ML on AWS (SageMaker Studio, data pipelines) → MLA-C02.
• Format (GA expectations; beta may differ — marked unverifiable where noted): ~65 questions, ~130 minutes, multiple-choice/multiple-response, scored 100–1000 with 720 pass (the DEA-C01 pattern; unverifiable for MLA-C02 beta specifically — confirm on aws.amazon.com/certification when scheduling). Fee expected ~$150 USD (Associate tier; unconfirmed for beta).
• The questions are scenario-driven: "a team needs to train a model on 50 TB with minimal cost," "predictions must return in <100 ms," "the model must be auditable for bias." The skill is matching workload requirements to SageMaker capabilities and knowing the MLOps lifecycle.

3. Knowledge domains (with theory)

Public blueprint domains (approximate): Data Preparation for ML (~28%), ML Model Development (~26%), Deployment and Orchestration (~22%), Monitoring, Maintenance, and Security (~24%). Approximate; the beta blueprint may shift — verify against the official exam guide.

Data preparation: the unglamorous 80%

The theory: garbage in, garbage out is a data-engineering problem. Model performance is bounded by data quality long before architecture choice matters. Key concepts:

• Feature stores (SageMaker Feature Store): centralized, versioned, point-in-time-correct features serving both training and inference — the fix for training/serving skew. Two stores: offline (S3, for training) and online (low-latency, for inference). Point-in-time correctness is the exam's favorite phrase: features as-of the event timestamp, never leaking future data.
• Data labeling: SageMaker Ground Truth (human + automated labeling, active learning to label only uncertain samples). Know when synthetic/augmented data helps (class imbalance) and when it lies (augmentation that breaks label semantics).
• Handling imbalance: class weights, SMOTE/oversampling, focal loss, threshold tuning — and the metric consequences (accuracy lies on imbalanced data; use precision/recall/F1/AUC-PR).
• Data versioning and lineage: SageMaker Lineage Tracking, dataset versioning in S3 — reproducibility requires versioned data + code + environment, not just code.
• Bias detection (SageMaker Clarify): pre-training (data bias: class imbalance, label disparity — e.g., DPL, difference in positive proportions) and post-training (prediction bias: DPPL, disparate impact). Know the metric families exist and what stage each applies to.

Bias-variance decomposition (the theory the exam assumes): Expected error = bias² + variance + irreducible noise. High bias = underfit (too simple, training error high) → add capacity/features, reduce regularization. High variance = overfit (training error low, validation high) → more data, regularization, simpler model, cross-validation. Learning curves diagnose which: converging high error = bias; gap between train/validation = variance.

Model development: training on SageMaker

• Built-in algorithms vs custom: SageMaker built-ins (XGBoost, BlazingText, DeepAR, KNN, linear learner...) for speed; SageMaker Training jobs with custom containers / Script mode for control. Spot training (managed spot, up to ~70% off, checkpointing to S3) for cost.
• Distributed training: data parallelism (SageMaker's distributed data-parallel library — near-linear scaling for CNNs) vs model parallelism (SMP library — for models too big for one GPU). Know when each: data-parallel is the default; model-parallel when the model doesn't fit in GPU memory.
• Hyperparameter optimization: SageMaker Automatic Model Tuning (Bayesian optimization — models the objective function, picks promising configs; vs grid/random search). Know the search strategies and that tuning jobs have warm-start options.
• Experiment tracking: SageMaker Experiments (trials, lineage) — the reproducibility answer.
• Evaluation metrics (memorize with formulas):
  • Classification: accuracy = (TP+TN)/(all); precision = TP/(TP+FP); recall = TP/(TP+FN); F1 = 2PR/(P+R); AUC-ROC (ranking quality); AUC-PR (better for imbalanced).
  • Regression: MAE = mean|y−ŷ|; RMSE = √(mean(y−ŷ)²) (penalizes large errors); R² = 1 − SS_res/SS_tot.
  • When each: precision when false positives are expensive (spam filters, fraud flags); recall when false negatives are expensive (disease screening, defect detection); RMSE when large errors are disproportionately bad.
• Regularization: L1 (Lasso — sparsity, feature selection), L2 (Ridge — shrinks weights), dropout, early stopping, data augmentation. The assumption: regularization trades a little bias for a lot less variance.

Deployment and orchestration

• Inference options: real-time endpoints (SageMaker hosting, <100 ms–seconds latency, autoscaling), serverless inference (spiky, cold-start tolerant), asynchronous inference (large payloads, long processing, SQS-queued), batch transform (offline bulk scoring — cheapest per prediction). The decision axis: latency requirement × traffic pattern × payload size.
• Multi-model endpoints (many models, one endpoint — cost sharing when models are small/infrequent) vs multi-container endpoints (ensemble/direct-invocation pipelines).
• Deployment guardrails: SageMaker Inference Pipelines (pre/post-processing chained), shadow deployments (new variant gets live traffic copies, responses discarded — safe validation), blue/green via endpoint variants with canary traffic shifting.
• Model Registry: versioned, approved/rejected stages — the governance gate between training and production.
• Edge: SageMaker Neo (compile for edge hardware), Edge Manager (fleet management).
• Orchestration: Step Functions + Lambda for inference workflows; EventBridge scheduling for batch.

Monitoring, maintenance, security

• SageMaker Model Monitor: data quality (drift in feature distributions — e.g., PSI/K-S distance), model quality (ground-truth labels compared to predictions), bias drift, feature attribution drift. Concept drift vs data drift: data drift = input distribution changed; concept drift = the relationship changed (P(y|X) shifted) — concept drift needs retraining, data drift might need re-feeding.
• Retraining triggers: schedule-based, performance-degradation-based, data-volume-based. The exam's mature answer: automated retraining pipelines (Pipelines + Model Monitor alarms), not manual notebooks.
• Security: IAM roles for training/inference (never hardcode credentials), KMS encryption for training data/models/artifacts, VPC config for training jobs and endpoints (no internet), private ECR, network isolation (EnableNetworkIsolation). Model artifacts in S3 encrypted with CMEK.
• Responsible AI: Clarify for bias, Model Cards (documentation: intended use, metrics, limitations), human-in-the-loop (Augmented AI) for high-stakes decisions.

4. Key formulas

• Bias-variance: E[(ŷ−y)²] = bias² + variance + σ².
• Precision/recall/F1 (above). RMSE penalizes outliers quadratically vs MAE linearly — choose by error cost.
• AUC-PR baseline = positive rate (unlike ROC's 0.5) — interpret accordingly on imbalanced data.
• Learning-rate scheduling: too high → divergence; too low → slow/stuck. Warmup + cosine decay is the modern default.
• Cost math: training cost = instance-hours × price; spot saves ~70% but needs checkpointing (checkpoint every N steps; resume cost < restart cost).
• Inference cost: endpoint-hours × price + invocations; batch transform has no endpoint-hours — the cheapest for offline scoring.

5. Worked examples

Example 1 — Fraud detection with imbalance. Scenario: 0.1% fraud rate; false negatives cost 100× false positives; need <200 ms scoring. Solution: XGBoost on SageMaker (built-in, handles imbalance via scale_pos_weight); optimize for recall at fixed precision (or F-beta with beta>1), not accuracy; threshold tuning on the PR curve (accuracy-optimal threshold is wrong here); real-time endpoint with autoscaling; Model Monitor on prediction distribution (fraud patterns drift); Clarify to check the model doesn't discriminate by protected attributes. Batch transform for nightly backfill scoring.

Example 2 — Training/serving skew. Scenario: Model performs well offline but degrades in production within days. Solution: Classic skew: training features computed in batch (e.g., 7-day aggregates) but serving uses real-time approximations. Fix: Feature Store with online/offline consistency (same transformation code, point-in-time correct offline); add Model Monitor data-quality checks comparing training baseline vs live feature distributions; shadow-deploy the fixed pipeline before promoting. Lesson: skew is a pipeline bug, not a model bug.

Example 3 — Cost-optimized large training. Scenario: Train a 10B-parameter model; budget-constrained; can tolerate preemption. Solution: SageMaker distributed training with model parallelism (SMP — doesn't fit on one GPU); managed spot training with checkpointing to S3 every ~15 min (spot ~70% cheaper; checkpoint cost << restart cost); mixed precision (fp16 — 2× throughput, minimal accuracy loss); gradient accumulation if batch-size constrained. Estimate: on-demand cost × 0.3 (spot) × 0.6 (mixed precision + parallelism efficiency) — show the math in design docs.

Example 4 — Auditable hiring model. Scenario: Resume-screening model; legal requires bias audit and human oversight. Solution: Clarify pre-training (check label/positive-rate disparity across groups) and post-training (disparate impact metrics); Model Cards documenting intended use + limitations; Augmented AI human review for borderline scores; Model Monitor bias-drift alarms in production; KMS-encrypted artifacts + access logging for the audit trail. This is the EU AI Act / Colorado AI Act pattern (see regulations section).

Example 5 — Multi-model cost problem. Scenario: 200 small classification models, each invoked a few times per hour. Real-time endpoints would cost 200 × 24 h × price. Solution: Multi-model endpoint (one endpoint, models loaded on demand from S3 — pay per endpoint, not per model) or serverless inference per model (scale-to-zero). Batch transform if latency allows. The trap: one endpoint per model — 200 endpoints of idle spend.

6. Standards and regulations cross-reference

• EU AI Act — the exam-relevant regulation: risk-based tiers (unacceptable → high-risk → limited → minimal); high-risk systems need conformity assessment, data governance, human oversight, logging. Architecturally: Model Cards + Clarify + lineage + human-in-the-loop map directly to Act requirements. Know the tier structure and that GPAI/foundation models have separate obligations.
• ISO/IEC 42001:2023 — AI management system (the 27001-style wrapper for AI): policies, risk assessment, lifecycle controls. The organizational answer to "we do responsible AI."
• ISO/IEC 23894:2023 — AI risk management guidance (the 27005-style companion): risk identification across the AI lifecycle.
• NIST AI RMF 1.0 — Govern/Map/Measure/Manage functions; the US-framework vocabulary (trustworthy AI characteristics: valid, safe, secure, accountable, explainable, privacy-enhanced, fair).
• Colorado SB 26-189 / California SB 53 — US state AI laws: algorithmic discrimination duties (Colorado, deployer/developer obligations for consequential decisions), frontier-model transparency (California). Know they exist and that consequential-decision systems (hiring, lending) carry documentation/audit duties.
• GDPR — training-data lawful basis, data-subject rights vs trained models (erasure vs model retraining — the hard problem; know it's unresolved and document your approach), DPIAs for high-risk ML.
• SR 11-7 / OCC 2011-12 — model risk management for banks: model validation (independent), documentation, ongoing monitoring. If you do ML in finance, this is the governing regime — validation must be independent of development.

7. Pitfalls, traps, and exam strategy

Trap patterns:

1. The accuracy trap: imbalanced data + "which metric" → never accuracy. Precision/recall/F1/AUC-PR.
2. The real-time trap: batch-scorable workload → batch transform (cheapest). Real-time endpoints only when latency demands.
3. The skew trap: offline/online performance gap → feature pipeline inconsistency, not model architecture.
4. The spot trap: spot training without checkpointing — preemption loses everything. Checkpointing is the enabling detail.
5. The bias-stage trap: Clarify pre-training = data bias; post-training = model bias. Match the metric family to the stage.
6. The beta trap (version-specific): don't memorize third-party MLA-C01 materials as MLA-C02 truth — the blueprint changed. Verify against the official exam guide.

Strategy: the exam rewards lifecycle thinking: every scenario spans data → train → deploy → monitor. When stuck, ask "which lifecycle stage is broken?" Memorize: the four inference options and their decision criteria, evaluation metric formulas and when each applies, bias-variance diagnosis from learning curves, and the SageMaker service map (Feature Store, Clarify, Model Monitor, Pipelines, Registry, Neo). Derive the rest from ML fundamentals.

8. Practice problems

P1. A churn model has 95% accuracy but the business says it's useless. The positive (churn) rate is 4%. Explain and propose the right evaluation. Answer: 95% accuracy ≈ always predicting "no churn" (96% majority baseline). Accuracy is dominated by the majority class. Evaluate with AUC-PR (baseline 0.04), F1, or recall@precision-k; tune the decision threshold on the PR curve for the business cost ratio (retention offer cost vs lost customer). Report the confusion matrix, not accuracy.

P2. Training a model on p4d.24xlarge spot instances. List the three cost/reliability mechanisms and the failure mode if you skip each. Answer: (1) Managed spot training (~70% off; skip → pay on-demand). (2) Checkpointing to S3 (skip → preemption restarts from zero). (3) Mixed precision + distributed data-parallel (skip → 2–4× longer training). Also: use checkpoint resume in the training script — SageMaker restores the checkpoint automatically only if the code loads it.

P3. Model Monitor fires data-drift alarms weekly, but model quality (against ground truth) is stable. Diagnose and fix. Answer: Data drift without quality impact = the drifted features aren't driving predictions (or the drift is benign, e.g., a feature's scale changed but ranking preserved). Fix: check feature-attribution drift (are the important features drifting?), tighten baselines/constraints to the predictive features, and consider whether the alarm threshold is too sensitive. Don't retrain on benign drift — retraining on noise degrades the model.

P4. Design inference for: 10M images/day, latency-tolerant (results needed within 6 hours), cost-minimal. Answer: Batch transform: no endpoint-hours, scales workers to the backlog, cheapest per prediction. Schedule nightly via EventBridge; input in S3, output to S3; use multi-instance batch with mini-batch tuning. Real-time/serverless would idle-spend; async inference is for large-payload near-real-time, not bulk.

P5. A loan-approval model must satisfy the Colorado AI Act's algorithmic-discrimination duties. Name the concrete ML-engineering artifacts. Answer: (1) Pre-training bias audit (Clarify: DPL, CDDPL on historical data). (2) Post-training disparate-impact metrics across protected groups. (3) Model Card documenting intended use, performance by group, limitations. (4) Annual impact assessment + deployer notification artifacts. (5) Production bias-drift monitoring with alerts. (6) Human-review path for adverse decisions. The Act turns "responsible AI" from values into deliverables.

P6. Your endpoint's p99 latency doubled after a model update, though the model is smaller. Give two likely causes and how to confirm each. Answer: (1) Cold-start/scale-from-zero: new variant triggered autoscaling from zero — confirm via invocation metrics vs instance count timeline. (2) Pre/post-processing regression: the inference pipeline's Python transforms got slower (bigger tokenizer, extra validation) — confirm by profiling pipeline stages separately (SageMaker inference pipeline logs per-container latency). Model size isn't the only latency term — measure the pipeline, not the artifact.

Original ETS reference writing, verified against public sources on 2026-09-30. Thin sourcing is flagged inline. Not legal advice — confirm current editions with the issuing body.