Overview
Scaling prototypes into ML models has three official objectives. Task 3.1 covers building a model for a task while weighing cost, complexity, latency and scalability: choosing a model type such as ARIMA, a DNN or an LLM, a product such as AutoML, BigQuery ML or Pipelines, a deployment strategy, and techniques that meet interpretability needs. Task 3.2 covers organizing and ingesting training data, training with custom jobs, Kubeflow on GKE, AutoML or Tabular Workflows, troubleshooting failures, tuning hyperparameters and fine-tuning foundation models. Task 3.3 covers CPU, GPU and TPU choices and data or model parallelism.
At about 21% of the exam, this is the heaviest section, so expect ten or more questions. It assumes you can move from a notebook result to a production-grade training job.
How it's tested
Domain 3 scenarios give a model goal plus constraints such as a budget, a latency target, an explainability rule or a training time limit. You choose a model type, a training product, a tuning method or hardware. Several answers often work; the right one meets every stated constraint at the least cost.
-
Model and product fit
A problem and constraints are described and you choose the model family and the Google Cloud product to train it.
-
Fix the training job
A job is slow, runs out of memory or fails, and you identify the cause such as an input bottleneck or an oversized batch.
-
Accelerator and strategy
Model size and framework are stated, and you choose CPU, GPU or TPU and data or model parallelism.
A team trains a large TensorFlow image model on GPUs, but utilization sits at 30% while the CPU is busy decoding images. Adding more GPUs would raise cost without fixing the bottleneck. Switching to TPUs has the same problem. Using tf.data with parallel reads, prefetching and data stored as TFRecord files removes the input bottleneck, so optimizing the input pipeline is the expected answer.
Objectives 3
Official objectives from the Google Cloud outline, in outline order.
3.1 Building models given the task considering cost, complexity, latency, and scalabilityChoosing a model type, a product, a deployment strategy and techniques that meet interpretability needs.
- What it means
- This task asks you to design the model before training it. You choose a model type such as ARIMA, a deep neural network or an LLM, a product such as AutoML, BigQuery ML or Pipelines, a deployment strategy, and modeling techniques that satisfy interpretability requirements, all while balancing cost, complexity, latency and scalability.
- What to understand
- Simple models are cheaper to train, faster to serve and easier to explain, so start there and add complexity only when metrics demand it. ARIMA-style models suit time series with clear seasonality; tree ensembles are strong on tabular data; DNNs handle images, audio and text; LLMs handle open-ended language tasks and can often be used through prompting or retrieval rather than training. When regulators or users need to understand decisions, prefer inherently interpretable models or add feature attributions. Latency targets push toward smaller models, distillation or batch scoring instead of online calls.
- How it shows up
- Constraints like a strict latency budget or an explainability rule are given, and you pick the model and product that satisfy all of them.
- Common confusion
- Assuming the most accurate model is always correct when the scenario prioritizes explainability or latency.
3.2 Training modelsOrganizing and ingesting training data, training SDKs and services, troubleshooting, hyperparameter tuning and foundation model fine-tuning.
- What it means
- This task covers running training at production scale. You organize tabular, text, speech, image and video data in Cloud Storage or BigQuery, ingest structured and unstructured sources into training pipelines, train with custom training, Kubeflow on GKE, AutoML or Tabular Workflows, troubleshoot failures, tune hyperparameters, and fine-tune foundation models from Agent Platform and Model Garden while judging whether tuning is warranted.
- What to understand
- Custom training runs your code in a prebuilt or custom container, with logs in Cloud Logging. Store large unstructured data in Cloud Storage in sharded formats such as TFRecord, and read tabular data directly from BigQuery. Hyperparameter tuning on Agent Platform uses Bayesian optimization to search ranges you define against a metric. Common failures include out-of-memory errors from large batches, NaN losses from high learning rates and slow jobs from input bottlenecks. Fine-tune a foundation model with supervised tuning or parameter-efficient methods such as LoRA only when prompting and retrieval-augmented generation cannot reach the needed quality, style or format.
- How it shows up
- A training job, data layout or quality gap is described and you choose the training service, the fix or whether fine-tuning is justified.
- Common confusion
- Fine-tuning to add fresh or frequently changing facts, which retrieval handles better and more cheaply.
3.3 Choosing appropriate hardware for trainingCPU, GPU and TPU options and distributed training with data and model parallelism.
- What it means
- This task covers matching compute to the training workload. You evaluate CPUs, GPUs and TPUs, and understand how distributed training on GPUs and TPUs uses data parallelism or model parallelism to handle more data or larger models.
- What to understand
- CPUs suit small models, tree-based methods and preprocessing. GPUs are flexible accelerators for deep learning across frameworks, including PyTorch with custom operations. TPUs are Google's matrix-math accelerators, strongest for large dense models built with JAX, TensorFlow or PyTorch/XLA, and are used in multi-host pods for very large training runs. Data parallelism copies the model to each device and splits the batch, which scales well when the model fits on one device. Model parallelism splits the model itself across devices when it is too large for one. Spot VMs lower cost for jobs that checkpoint and can restart.
- How it shows up
- Model size, framework and budget are stated, and you choose the accelerator and parallelism strategy that fit.
- Common confusion
- Choosing model parallelism when the model fits on one device and the real need is more throughput.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Custom training job
Runs your training code in a container on Agent Platform.
- Remember
- Prebuilt containers for common frameworks; custom ones for anything else.
- Tested as
- Training service questions.
- Trap
- Running long training on a notebook VM.
-
Tabular Workflows
Managed, configurable pipelines for tabular AutoML-style training.
- Remember
- More control than plain AutoML.
- Tested as
- Tabular training scenarios.
- Trap
- Assuming AutoML is the only managed tabular choice.
-
Hyperparameter tuning
Agent Platform service that searches parameter ranges.
- Remember
- Bayesian search toward a chosen metric.
- Tested as
- Optimization questions.
- Trap
- Tuning without a clear target metric.
-
Early stopping
Ending training when validation metrics stop improving.
- Remember
- Saves cost and reduces overfitting.
- Tested as
- Training efficiency questions.
- Trap
- Training for a fixed large number of epochs.
-
Overfitting remedies
Regularization, dropout, more data and simpler models.
- Remember
- Gap between training and validation metrics is the sign.
- Tested as
- Troubleshooting questions.
- Trap
- Adding layers when validation loss is rising.
-
Input pipeline optimization
Parallel reads, prefetching and sharded files.
- Remember
- Fixes low accelerator utilization.
- Tested as
- Slow training questions.
- Trap
- Buying more accelerators first.
-
Supervised fine-tuning
Tuning a foundation model on labeled prompt-response pairs.
- Remember
- Changes style, format or task behavior.
- Tested as
- Gen AI customization questions.
- Trap
- Using it to inject changing facts.
-
Parameter-efficient tuning (LoRA)
Trains small adapter weights instead of the whole model.
- Remember
- Lower cost and storage than full tuning.
- Tested as
- Open model tuning scenarios.
- Trap
- Assuming full fine-tuning is always better.
-
GPU
General-purpose deep learning accelerator.
- Remember
- Broad framework and custom-op support.
- Tested as
- Hardware questions.
- Trap
- Choosing it for a tree model that runs fine on CPUs.
-
TPU
Google accelerator for large matrix workloads.
- Remember
- Best for big dense models with XLA-compatible code.
- Tested as
- Hardware questions.
- Trap
- Picking it for code with unsupported custom ops.
-
Data parallelism
Same model on each device, different slices of each batch.
- Remember
- Scales throughput when the model fits on one device.
- Tested as
- Distributed training questions.
- Trap
- Confusing it with model parallelism.
-
Model parallelism
Splits a model's layers or tensors across devices.
- Remember
- Needed when the model exceeds one device's memory.
- Tested as
- Large model questions.
- Trap
- Using it for small models.
-
Interpretability vs accuracy
Simpler models are easier to explain.
- Remember
- Regulated decisions may require explainable models.
- Tested as
- Model choice questions.
- Trap
- Ignoring a stated explainability requirement.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Training hardware
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| CPU | General-purpose processors. | Cheapest for small, tree-based or preprocessing-heavy work. | Using them for large deep networks. |
| GPU | Parallel accelerators across frameworks. | Flexible, supports custom operations. | Leaving them idle behind a slow input pipeline. |
| TPU | Matrix-focused Google accelerators. | Highest scale for large dense models. | Choosing them for unsupported ops or tiny jobs. |
Distributed training strategies
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Data parallelism | Replicate the model, split the data. | Model must fit on each device. | Applying it to a model too big for one device. |
| Model parallelism | Split the model across devices. | Handles models larger than one device. | Adding communication overhead without need. |
Ways to customize a foundation model
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Prompt design | Instructions and examples in the prompt. | No training cost; fast to change. | Skipping it before tuning. |
| Retrieval-augmented generation | Adds retrieved documents to the prompt. | Keeps answers current and grounded. | Confusing it with tuning. |
| Supervised or LoRA tuning | Adjusts weights on labeled examples. | Changes behavior, style or output format. | Using it to teach fast-changing facts. |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
More GPUs for a slow job
- What candidates pick
- Add GPUs to the training cluster
- Why it looks right
- More compute sounds faster.
- Why it's wrong
- If utilization is low because of input reading, extra GPUs sit idle; fix the data pipeline first.
Clue to watch for Low accelerator utilization or a busy CPU.
-
Tune to add knowledge
- What candidates pick
- Fine-tune Gemini on the latest product catalog
- Why it looks right
- Tuning seems to teach the model new content.
- Why it's wrong
- Catalogs change often and tuning bakes in stale facts; retrieval keeps answers current at lower cost.
Clue to watch for Information updates daily or weekly.
-
Deep model for regulators
- What candidates pick
- A deep neural network for loan approvals
- Why it looks right
- It may give the best accuracy.
- Why it's wrong
- The scenario requires decisions to be explained, so an interpretable model or one with clear attributions is preferred.
Clue to watch for Regulatory or customer explanation requirement.
-
TPU for everything
- What candidates pick
- Move a PyTorch model with custom CUDA kernels to TPUs
- Why it looks right
- TPUs are Google's fastest training hardware.
- Why it's wrong
- Custom CUDA operations do not run on TPUs, so GPUs are the practical choice.
Clue to watch for Custom operations or CUDA-specific code.
-
Larger batch to fix OOM
- What candidates pick
- Raise batch size to speed up training
- Why it looks right
- Bigger batches improve throughput.
- Why it's wrong
- Out-of-memory errors call for a smaller batch, gradient accumulation or more device memory, not a bigger batch.
Clue to watch for An out-of-memory error in the logs.
-
Grid search everywhere
- What candidates pick
- Exhaustive grid search over many parameters
- Why it looks right
- It feels thorough.
- Why it's wrong
- Grid search grows exponentially with parameters; Bayesian tuning on Agent Platform finds good values with fewer trials.
Clue to watch for Many hyperparameters and a limited budget.
Answer framework
Follow these steps to move from a prototype to a production training setup that meets every constraint.
- List the constraints in the scenario, such as explainability, latency, budget and training deadline, before looking at the answer choices.
- Pick the simplest model type that can meet the quality target, and for language tasks try prompting or retrieval before any tuning.
- Choose the training product: BigQuery ML or AutoML for standard problems, custom training or Kubeflow on GKE when you need full control.
- Size the hardware: CPUs for small or tree models, GPUs for flexible deep learning, TPUs for large dense models, with matching parallelism.
- Tune and troubleshoot with Bayesian hyperparameter search, early stopping, and logs that reveal memory errors, unstable loss or input bottlenecks.
Practice question
Want more like this? The GCP PMLE practice test has questions for every domain.
Checklist
0 of 12
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Give this section the most time, since it carries about 21% of the exam. Begin with model selection: build a table of problem types with a default model, a stronger option and the trade-off between them, and add a column for interpretability. Then run one custom training job on Agent Platform with a prebuilt container, read its logs, and attach a hyperparameter tuning job with two parameters.
For gen AI, read the Agent Platform pages on supervised tuning and on when to tune, and write your own rule for choosing between prompting, retrieval and fine-tuning. Practice with three example use cases, such as a tone change, a daily price list and a domain-specific format.
For hardware, summarize CPU, GPU and TPU strengths in a few lines each, and draw data and model parallelism side by side. Finish with troubleshooting drills: for each symptom, such as low GPU utilization, rising validation loss or NaN loss, write the most likely cause and fix. Revisit those drills before your mock exam.
FAQ
How much of the GCP PMLE exam is Scaling prototypes into ML models?
Scaling prototypes into ML models is about 21% of the exam, the largest of the six sections, so plan for roughly 11 to 13 questions on it.
When should I fine-tune a foundation model?
After prompt design and retrieval have been tried, when you need consistent behavior, style or output format and have quality labeled examples.
When are TPUs better than GPUs?
For large dense models using JAX, TensorFlow or PyTorch/XLA without custom CUDA operations, especially at multi-host scale.
What is the difference between data and model parallelism?
Data parallelism splits the batch across copies of the model; model parallelism splits the model itself because it does not fit on one device.
What search method does Agent Platform hyperparameter tuning use?
It uses Bayesian optimization by default, with grid and random search also available, to find good values in fewer trials.
What are Tabular Workflows?
Managed, configurable training pipelines for tabular data on Agent Platform that give more control over the AutoML process.
Will the exam ask me to write training code?
No. It may show short Python snippets, but questions test design and troubleshooting decisions rather than coding.
Other Artificial Intelligence & Machine Learning certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 3 knowledge
You have studied model choice, training services, tuning and accelerator selection. Check how well you trade off cost, latency and accuracy in exam-style scenarios.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the GCP PMLE AI tutor Get any concept explained your way