Amazon MLS-C01: Time Series & Forecasting — Study Guide

By Laurynas Brazys · 25 July 2026 · #amazon #mls-c01 #certification #exam-prep #study-guide

Part of the AWS Machine Learning Specialty MLS-C01 — Study Guide. Practice with verified answers in the Amazon exam hub, or take timed practice tests on ExamRoll.io.

Algorithm selection and when to use each approach

Choosing the right forecasting model begins with the data shape and the objective. Classical univariate approaches such as ARIMA/SARIMA remain the right fit when you have a single, well-behaved series with long history and interpretable seasonal terms; you can implement these in a SageMaker training script using statsmodels or run experiments interactively in SageMaker Studio. Prophet-style decomposable models are valuable when business-driven holiday effects and multiple seasonalities (daily/weekly/annual) must be modeled explicitly and interpreted; these are often prototyped in notebooks and can be productionized in SageMaker. For probabilistic, multi-series forecasting at scale, use DeepAR (SageMaker built-in algorithm or Amazon Forecast’s DeepAR+) which learns across related time series and produces quantile forecasts. Important configuration choices include setting time_freq, prediction_length and context_length (context_length should typically be >= prediction_length), choosing an appropriate likelihood (studentT for heavy tails, negative-binomial for counts/intermittent demand), and enabling use_feat_dynamic_real or use_feat_static_cat for covariates. Use classical models when interpretability and single-series diagnostics are required; prefer DeepAR/Amazon Forecast when you have many related series and need calibrated probabilistic outputs and built-in scaling.

Data preparation: seasonality, covariates, and missing values

Good forecasts require careful alignment of timestamps, frequency, and covariates. Always normalize timestamps to a consistent timezone and frequency (set time_freq for models). Capture known seasonality and business events by adding holiday indicators and special-event features as static or dynamic covariates; include price promotions, store openings, or campaign flags as dynamic features. Missing values must be handled thoughtfully: for short gaps use interpolation or forward/backward fill; for longer gaps use imputation with model-based approaches or mask them when the algorithm supports missingness (DeepAR accepts masked dynamic features). For intermittent demand with many zeros or over-dispersed counts, use negative-binomial likelihood, experiment with aggregation (e.g., weekly) to reduce sparsity, or apply Croston-based preprocessing when classical methods are appropriate. Avoid leaking future information in covariates—dynamic features must be known or forecastable for the prediction horizon. Store metadata (item_id, category, store_id) as static categorical features to let multi-series models share strength across items.

Evaluation: probabilistic metrics, backtesting, and calibration

Probabilistic forecasting requires different evaluation criteria than point forecasts. Use quantile loss (pinball loss) and continuous ranked probability score (CRPS) to evaluate distributional quality, and report coverage for key quantiles (e.g., P50, P90) to verify interval calibration. Avoid relying solely on MAPE for series with zeros or intermittent demand; use Mean Absolute Scaled Error (MASE) for scale-invariant comparison or weighted quantile losses to prioritize high-revenue SKUs. Implement rolling-origin (time series) cross-validation with multiple backtest windows to capture temporal instability and seasonality, ensuring each window respects seasonality cycles so holdouts contain full seasonal periods. Check calibration with prediction interval hit rates and PIT-like histograms; if intervals are too narrow, consider increasing num_eval_samples in DeepAR or adjusting likelihood assumptions. Common pitfalls include using future-known covariates that won’t be available at inference, aggregating away critical seasonality, and evaluating on a single static holdout that misses regime changes. Aggregate per-series metrics by business importance rather than simple averages to reflect decision impact.

Scaling, deployment patterns, and decision criteria

Scaling forecasting to thousands or millions of series and deploying forecasts into production has architectural trade-offs. For a managed, scale-first solution, Amazon Forecast handles dataset groups (target time series, related time series, item metadata), automated feature engineering, built-in backtesting, and elastic hosted predictors for batch or exportable forecasts; it’s well suited when you want a service that handles many series without bespoke model training. For custom modeling needs, use SageMaker with DeepAR (or custom PyTorch/TF models) where you control hyperparameters, likelihood choices, and feature engineering; train on GPU instances for speed and use SageMaker Batch Transform for bulk inference or real-time endpoints for low-latency serving. For cost efficiency with many model versions, consider multi-model endpoints or asynchronous batch pipelines triggered by S3 events or Step Functions. Decision criteria include whether you need custom architectures (choose SageMaker), whether you need cross-series learning with minimal ops (choose Forecast), and whether low-latency single-series predictions are required (favor SageMaker real-time endpoints). Common traps: under-provisioning context_length, misconfiguring quantile outputs, and not weighting evaluation by business impact.

Practical Problem: Use-Case Scenario

Scenario: Acme Retail operates 5,000 stores and maintains daily sales and promotion logs in Amazon S3. They use SageMaker Studio for data science and need scalable production forecasts to drive inventory and promotions.

Challenge: Produce calibrated 30-day probabilistic demand forecasts per SKU-store pair that account for holidays and promotions, handle intermittent zero sales for many SKUs, and scale to nightly batch production.

Recommended Approach:

1. Configure data pipelines: ingest daily sales and promotions into S3, catalog with AWS Glue and expose via Athena; create dataset files with timestamp, item_id, store_id, target_value, and dynamic features.
2. Prototype models in SageMaker Studio: try Prophet-style decomposition for a few representative SKUs, then train SageMaker DeepAR (set time_freq=‘D’, prediction_length=30, context_length=30–90, likelihood=‘negative-binomial’ for counts, num_eval_samples=100).
3. For scale and production: schedule nightly batch training or incremental retraining in SageMaker (or optionally use Amazon Forecast with dataset groups and predictors if you prefer managed forecasts), and use SageMaker Batch Transform or Forecast batch export for nightly bulk inference.
4. Evaluate with rolling-origin backtests using quantile loss and coverage metrics (P50/P90), and monitor live calibration; if intervals under-cover, tune likelihood or increase num_eval_samples.

Rationale: Using Glue/Athena and S3 standardizes data access, DeepAR (or Forecast) natively models many related series and produces quantiles needed for inventory decisions, negative-binomial handles intermittent counts, and batch transform enables cost-effective nightly scaling.

← Natural Language Processing · All domains · Training →

Practice these questions → · Timed practice on ExamRoll.io →

Browse Amazon →