Home / artificial-intelligence-machine-learning / Google Cloud Professional Machine Learning Engineer / Cheat Sheet
Google Cloud Professional Machine Learning Engineer

GCP PMLE Cheat Sheet

PMLE Tests the Least-Effort Path from Data to Monitored Model — Not Algorithm Trivia

For engineers who ship and run ML on Google Cloud, using the June 2026 guide's Agent Platform names. The shift: honour every stated constraint (skills, latency, explainability, budget) before reaching for custom training or more hardware.

Check Your Readiness →
Among the harder certs
Avg: Not published by Google
Pass: 750 / 1000
Most candidates understand Google Cloud Professional Machine Learning Engineer concepts — and still fail. This exam tests how you apply knowledge under pressure.

Professional ML Engineer Section Map (June 2026 guide)

Scenarios give a goal plus constraints, and several options would technically work. The scored answer meets every constraint with the most managed, lowest-effort service. Agent Platform was formerly Vertex AI and the Airflow service was formerly Cloud Composer. Published weights round to 101%.

  1. 01
    Scaling prototypes into ML models (~21%) — model choice under constraints, custom training, Bayesian tuning, LoRA vs. prompting, CPU/GPU/TPU and parallelism
  2. 02
    Serving and scaling models (~20%) — batch vs. online, prebuilt vs. custom containers, traffic splits, private endpoints, minimum replicas
  3. 03
    Automating ML pipelines (~18%) — Agent Platform Pipelines vs. Managed Service for Apache Airflow vs. Ray, validation and evaluation gates
  4. 04
    Collaborating on data and models (~16%) — BigQuery vs. Dataflow vs. Dataproc, Feature Store point-in-time joins, Workbench vs. Colab Enterprise, Experiments
  5. 05
    Architecting low-code AI (~13%) — BigQuery ML, AutoML, Document AI and task APIs, Gemini size, context caching, provisioned throughput
  6. 06
    Monitoring AI solutions (~13%) — skew vs. drift, Model Armor, safety filters, Explainable AI methods, bias monitoring

Wrong instinct vs correct approach

An insurer must pull policy number, claim date and amount from thousands of scanned forms within two weeks
✕ Wrong instinct

Vision API text detection or training an AutoML model

✓ Correct approach

A Document AI processor returns structured key-value fields rather than raw OCR text and needs no ML expertise. Prebuilt processors and task APIs come before AutoML, which still requires labelled training data.

Prompt examples still give inconsistent JSON formatting; the team holds 3,000 high-quality example pairs
✕ Wrong instinct

Switch to the largest Gemini model and lengthen the prompt

✓ Correct approach

Prompt design has been tried, so supervised fine-tuning, preferably parameter-efficient LoRA, is the next step for fixed format and tone. Tuning changes behaviour; it should never be used to inject frequently changing facts such as catalogues.

A nightly job must score a 50-million-row BigQuery table with no user waiting
✕ Wrong instinct

Deploy an online endpoint and call it in a loop

✓ Correct approach

Batch prediction reads from BigQuery or Cloud Storage and writes results back with no always-on endpoint billing. Online endpoints suit real-time requests, where minimum replicas prevent cold starts during predictable peaks.

Regulators require explanations for a boosted-tree credit model's individual decisions
✕ Wrong instinct

Use integrated gradients feature attributions

✓ Correct approach

Integrated gradients need a differentiable model such as a neural network. Sampled Shapley suits tree ensembles, and example-based explanations surface similar training cases to spot mislabelled or missing data.

Know these cold

  • ▸ Prebuilt API or Document AI, then BigQuery ML or AutoML, then custom training
  • ▸ Choose the smallest Gemini model that meets quality; cache long shared context; batch offline work
  • ▸ Provisioned throughput suits steady critical Gemini traffic, never small spiky workloads
  • ▸ Data parallelism when the model fits one device; model parallelism when it does not
  • ▸ TPUs for large dense XLA-compatible models; GPUs for custom CUDA ops; CPUs for trees
  • ▸ Feature Store point-in-time retrieval prevents future values leaking into training labels
  • ▸ Agent Platform Pipelines for ML workflows; Managed Service for Apache Airflow for cross-system scheduling
  • ▸ Ray scales compute inside a step; it is not a workflow scheduler
  • ▸ One endpoint with a traffic split for canaries; never a new endpoint per version
  • ▸ Accuracy misleads on rare classes; use precision, recall or PR AUC for fraud

Can you answer these without checking your notes?

In this scenario: "An insurer must pull policy number, claim date and amount from thousands of scanned forms within two weeks" — what should you do first?
A Document AI processor returns structured key-value fields rather than raw OCR text and needs no ML expertise. Prebuilt processors and task APIs come before AutoML, which still requires labelled training data.
In this scenario: "Prompt examples still give inconsistent JSON formatting; the team holds 3,000 high-quality example pairs" — what should you do first?
Prompt design has been tried, so supervised fine-tuning, preferably parameter-efficient LoRA, is the next step for fixed format and tone. Tuning changes behaviour; it should never be used to inject frequently changing facts such as catalogues.
In this scenario: "A nightly job must score a 50-million-row BigQuery table with no user waiting" — what should you do first?
Batch prediction reads from BigQuery or Cloud Storage and writes results back with no always-on endpoint billing. Online endpoints suit real-time requests, where minimum replicas prevent cold starts during predictable peaks.

Common Exam Mistakes — What candidates get wrong

Exporting BigQuery tables to Cloud Storage to train a custom model

When data already sits in BigQuery and the team writes SQL, BigQuery ML trains in place with CREATE MODEL and ML.PREDICT. Its TRANSFORM clause keeps preprocessing identical at prediction time, and ARIMA_PLUS handles many time series.

Adding GPUs to a training job that is starved by input reading

Low accelerator utilisation with a busy CPU means the input pipeline is the bottleneck. Fix it with sharded files, parallel reads and prefetching first; extra GPUs would sit idle. OOM errors need a smaller batch, not a bigger one.

Auto-deploying every retrained model straight from the pipeline

Continuous training can produce a worse model. Add data validation before training and an evaluation gate that compares the candidate with production, then register the version in Model Registry and release it through a canary traffic split.

Retraining to fix what is actually training-serving skew

Skew right after launch is usually a preprocessing mismatch between training and serving code; retraining will not fix it. Data drift compares recent serving windows, while concept drift needs ground-truth labels because inputs may look unchanged.

Relying on Gemini safety filters to stop prompt injection and data leaks

Safety filters block harmful content categories. Model Armor screens prompts and responses for injection, jailbreaks and sensitive data such as account numbers, and VPC Service Controls limit exfiltration, which encryption keys alone cannot prevent.

Resources to help you pass Google Cloud Professional ML Engineer on your first attempt

See whether you pick the managed ML option that meets every constraint in each PMLE scenario.