3.1 Choosing the Model Type: ARIMA, DNN, LLM and Classical Baselines

Google Cloud Professional Machine Learning Engineer Exam

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

0.1 Exam Overview, Blueprint & Certification Logistics 0.2 Study Strategy, Scenario Mechanics & 8-Week Roadmap

2 Section 1: Architecting Low-Code AI Solutions (~13%)

1.1 BigQuery ML: Model Types, SQL Syntax and In-Database Evaluation 1.2 Feature Engineering and Feature Selection in BigQuery ML 1.3 Generating Predictions with BigQuery ML 1.4 AutoML on Agent Platform: Tabular, Image, Text and Video Training 1.5 Fine-Tuning Gemini Models from BigQuery 1.6 Model Garden: Evaluating and Selecting the Right Model 1.7 Industry-Specific AI APIs: Document AI, Vision, Translate and Speech 1.8 Generative Media and Models as a Service: Gemini, Imagen and Veo 1.9 Optimizing Gemini Applications for Cost, Latency and Availability

3 Section 2: Collaborating Within and Across Teams to Manage Data and Models (~16%)

2.1 Organizing and Exploring Tabular, Text, Image and Video Data 2.2 Choosing the Preprocessing Tool: BigQuery, Dataflow, Spark and In-Memory Python 2.3 Creating and Consolidating Features in Agent Platform Feature Store 2.4 Data Privacy, PII Handling and Sensitive Information 2.5 Notebook Environments: Collaboration and Security Best Practices 2.6 Prototyping in Workbench and Colab Enterprise with PyTorch, scikit-learn and JAX 2.7 Prototyping with Model Garden Foundational and Open Models in Notebooks 2.8 Choosing the Development and Experimentation Environment 2.9 Evaluating Generative Solutions: LLM-as-a-Judge and RAG Evaluation 2.10 Experiment Tracking, Artifact Lineage and Model Registry Governance

4 Section 3: Scaling Prototypes into ML Models (~21%)

3.1 Choosing the Model Type: ARIMA, DNN, LLM and Classical Baselines 3.2 Choosing the Product: AutoML, BigQuery ML, Custom Training and Pipelines 3.3 Choosing the Deployment Strategy at Design Time 3.4 Modeling Techniques for Interpretability Requirements 3.5 Organizing Training Data on Cloud Storage and BigQuery 3.6 Ingesting Structured and Unstructured Data into Training Pipelines 3.7 Training SDKs and Services: Custom Training, Kubeflow on GKE, AutoML and Tabular Workflows 3.8 Troubleshooting ML Model Training Failures 3.9 Hyperparameter Tuning, Bayesian Optimization and Vizier 3.10 Model Evaluation Metrics, Transfer Learning and Fine-Tuning 3.11 Evaluating Compute and Accelerator Options: CPU, GPU and TPU 3.12 Distributed Training Strategies, Hardware Acceleration and Performance Optimization

5 Section 4: Serving and Scaling Models (~20%)

4.1 Batch and Online Inference: Agent Platform, Model Garden, Cloud Run and GKE 4.2 Rollout Strategies: Canary, Traffic Splitting, Shadow and Blue-Green 4.3 Tuning Models for Production: Vector Search and Model Compression 4.4 Deploying Models to Public and Private Endpoints 4.5 Choosing Serving Hardware: CPU, GPU, TPU and Edge 4.6 Scaling the Serving Backend for Throughput

6 Section 5: Automating and Orchestrating ML Pipelines (~18%)

5.1 Validating Data and Models Inside Pipelines 5.2 Agent Platform Pipelines: Kubeflow Pipelines (KFP) and TFX Architecture 5.3 Reusable Pipeline Components, Artifacts and ML Metadata Lineage 5.4 Ray on Agent Platform for Distributed Python Workloads 5.5 MLOps CI/CD Automation, Retraining Triggers and Skew Prevention

7 Section 6: Monitoring AI Solutions (~13%)

6.1 Securing AI Systems: Exfiltration, Malicious Prompting and Model Armor 6.2 Responsible AI, Explainable AI, Fairness Metrics and Model Governance 6.3 Model Monitoring: Feature Skew and Drift Detection 6.4 Operational Troubleshooting, Performance Profiling and Cost Optimization 6.5 Monitoring, Testing and Evaluating Generative AI in Production

3.1 Choosing the Model Type: ARIMA, DNN, LLM and Classical Baselines

Key Takeaways Explain This Topic AI

Model type follows the data shape and the requirement: gradient boosting for tabular, ARIMA_PLUS for univariate seasonal time series, DNNs for high-dimensional unstructured data, LLMs for language tasks.

ARIMA_PLUS handles trend, multiple seasonalities, holidays, and anomaly cleaning automatically; ARIMA_PLUS_XREG adds external regressors such as price or promotion flags.

Deep neural networks rarely beat gradient boosting on tabular data of moderate size and cost far more to train, serve, and explain.

An LLM is the right model type for open-ended language work but the wrong one for a high-volume, low-latency, fixed-taxonomy classification that a small supervised model handles for a fraction of the cost.

Always establish a simple baseline first — the naive forecast, the majority class, or a logistic regression — because it defines what "better" means.

Last updated: September 2026

• 3.1 Choosing the Model Type: ARIMA, DNN, LLM and Classical Baselines
• Blueprint reference: Section 3.1, "Choosing the model type (e.g., ARIMA, DNN, and LLM)."

Google names three examples in that bullet and they are deliberately far apart: a statistical time-series model, a neural network, and a large language model. The exam wants to see that you pick by problem shape rather than by fashion.

The Decision, in One Table

Data shape and task First choice Why

Tabular, mixed types, thousands to millions of rows Gradient boosting (XGBoost, BOOSTED_TREE_*) Consistently the strongest tabular family; handles missing values and mixed types natively

Tabular, need a transparent linear model Linear / logistic regression Coefficients are directly interpretable; L1 gives feature selection

Univariate or grouped time series with seasonality ARIMA_PLUS Automatic trend, seasonality, holiday, and anomaly handling

Time series driven by known external factors ARIMA_PLUS_XREG Accepts exogenous regressors such as price, weather, promotions

Images, audio, video, dense embeddings DNN / CNN / transformer Learns representations from raw high-dimensional input

Sequential dependencies, long horizons, many covariates Deep forecasting or transformer models Captures cross-series and non-linear interactions ARIMA cannot

Open-ended language: summarize, extract, converse, reason LLM Handles unbounded output space and unseen phrasing

Fixed-taxonomy, high-volume text classification Small supervised classifier or AutoML Orders of magnitude cheaper and faster than an LLM at the same accuracy

Recommendation from interaction history Matrix factorization or two-tower retrieval Purpose-built for collaborative signal

• Grouping without labels k-means, DBSCAN, PCA, autoencoder Unsupervised structure discovery
• ARIMA_PLUS in Detail

Forecasting questions are common and ARIMA_PLUS is Google Cloud's default answer for classical time series. What it does automatically is the point:

Trend and seasonality decomposition , including multiple seasonal periods (daily, weekly, yearly).

Holiday effects , when a region is specified.

Anomaly detection and cleaning on the input series, so a one-off spike does not distort the fit.

Automatic hyperparameter search over the ARIMA order.

Prediction intervals at a requested confidence level.

Grouped forecasting — many series (per store, per SKU) in a single CREATE MODEL using time_series_id_col . CREATE OR REPLACE MODEL `analytics.sku_forecast`

• OPTIONS (
• model_type = 'ARIMA_PLUS',
• time_series_timestamp_col = 'sale_date',
• time_series_data_col = 'units',
• time_series_id_col = 'sku_id',
• holiday_region = 'US',
• auto_arima = TRUE
• ) AS SELECT sale_date, units, sku_id FROM `analytics.daily_sales`;

Choose ARIMA_PLUS_XREG instead when the series is genuinely driven by measurable external variables you will know at forecast time — price, promotion flag, temperature. If you will not know the regressor's future value, it cannot be used as a regressor.

Move beyond ARIMA when there are many interacting series, rich covariates, or non-linear regime behaviour; that is where deep forecasting models or AutoML forecasting earn their extra cost.

When a DNN Is Justified — and When It Is Not

Deep networks earn their keep when the input is high-dimensional and the useful features are not hand-engineerable: pixels, waveforms, token sequences, graphs. On tabular data of moderate size, gradient boosting usually wins , trains in minutes on CPU, and is far easier to explain and serve.

The costs a DNN adds are real and testable: accelerator hours for training, a larger serving footprint, more hyperparameters to tune, more ways to fail to converge, and weaker out-of-the-box interpretability. A scenario that stresses limited budget, a small team, tabular data, or a requirement to explain individual decisions is steering away from a DNN.

Where DNNs do belong on tabular data: very large datasets with high-cardinality categorical features that benefit from learned embeddings, or when the tabular data must be fused with text or images in one model.

When an LLM Is the Wrong Answer

LLMs are the correct model type for open-ended language work — summarization, extraction from unseen document layouts, conversational interfaces, reasoning over text. They are the wrong model type for:

High-volume, fixed-taxonomy classification. Routing ten million tickets a day into twelve categories is a supervised classification problem. A small fine-tuned classifier or AutoML text model costs a fraction of per-token inference and answers in milliseconds.

Numeric prediction from tabular features. An LLM asked to predict a churn probability from structured fields is strictly worse than a model trained for it.

Anything with a hard sub-100 ms latency budget and high QPS , unless a small model tier has been measured to fit.

The reverse trap also appears: a scenario with an unbounded output space, novel document layouts, or a requirement to handle phrasings never seen in training is not solvable by a fixed-class classifier, and choosing AutoML there is the wrong answer.

Cost, Complexity, Latency, Scalability

The blueprint bullet names four axes. Apply them explicitly:

Axis Question to ask

Cost Training cost plus inference cost at production volume. A model that is cheap to train and expensive per call can be the more expensive choice overall.

Complexity Can this team maintain, debug, retrain, and explain it? A model nobody understands is an operational liability.

Latency What is the p95 budget at the required QPS, including preprocessing and feature lookup?

Scalability Does the approach hold at 100× the current volume, or does it require a rearchitecture?

Always Start with a Baseline

Before any of this, establish what "better" means:

Forecasting: the naive forecast (tomorrow equals today) or a seasonal naive.

Classification: the majority class , then a logistic regression.

Regression: predicting the mean, then a linear model.

Recommendation: most-popular items .

A surprising number of production models fail to beat these. Reporting a model's metric without a baseline is uninterpretable, and the exam rewards candidates who recognize that.

Exam Traps

A deep network for a mid-sized tabular problem. Boosted trees, almost always.

An LLM for fixed-class, high-volume classification. Cost and latency disqualify it.

ARIMA when the driver is a known external variable. Use ARIMA_PLUS_XREG.

A regressor whose future values are unknown. It cannot be used for forecasting.

Reporting a metric with no baseline. Nothing is established.