Examworthyexamworthy.comGoogle Cloud Professional Machine Learning Engineer cheat sheet
Google Cloud
Free to share. Examworthy is not affiliated with or endorsed by Google Cloud; PMLE and related marks belong to their respective owners.
At a glance
Format: Multiple choice and multiple select, online- or onsite-proctored
Domain weight map
Heaviest first - spend your time hereHow this exam thinks
PMLE is a pick-the-right-approach exam across the whole ML lifecycle: nearly every question is a scenario with cost, latency, skill, and scale constraints, and the right answer is the Google Cloud service or setting that fits them, usually the most managed option that meets the requirement.
Spot the trap
Tempting wrong answers, and why they failCommon misconception
That an LLM's fluent explanation counts as a genuine feature attribution. A generated narrative can state reasons the scoring model never actually used.
Scaling Prototypes Into ML Models
Common misconception
That adding client-side retries fixes request timeouts. Retries provision no extra capacity and can add load during an already-saturating scale-out.
Serving and Scaling Models
Common misconception
That retraining every night guarantees a fresh model. It burns compute on runs where nothing has actually degraded.
Automating and Orchestrating ML Pipelines
Common misconception
That a lower training perplexity proves generated summaries are relevant and faithful. Perplexity measures token-prediction fit, not whether the output stays on topic or true to the source.
Collaborating Within and Across Teams to Manage Data and Models
Common misconception
That a single hand-written regex blocking a known attack phrase is sufficient defence against prompt injection. Attackers simply rephrase the prompt to slip past it.
Monitoring AI Solutions
Common misconception
That a huge context window can replace retrieval by holding the whole document set in every prompt. It still exceeds practical limits and wastes tokens on irrelevant text.
Architecting Low-Code AI Solutions
Common misconception
That building a chat assistant always needs labelled data and a trained classifier. A grounded pretrained model can answer free text with no labels at all.
Scaling Prototypes Into ML Models
Common misconception
That increasing batch size lowers tail latency by raising throughput. Larger batches add queuing wait and more per-batch compute time instead.
Serving and Scaling Models
Key terms
Exam-day rules
- Read the scenario for its constraint first. The cost, latency, scale, team-skill, or operational-overhead limit named in the question is what picks the answer, so find it before you judge the options.
- When two approaches both work, default to the most managed one. Google prefers managed services, so BigQuery ML for a SQL team, AutoML over a hand-built network, a tuned foundation model over training from scratch; reach lower only when the scenario names a reason.
- Treat a SQL-fluent team whose data is already in BigQuery as a strong signal. It usually points to BigQuery ML, including fine-tuning a Gemini remote model and serving with ML.GENERATE_TEXT, over an exported custom training job.
- Decide online versus batch from the latency requirement. A periodic bulk scoring job with no per-row latency need is a distributed batch prediction job; low-latency single requests need an online endpoint, never the reverse.
- On the parallelism question, ask whether the model fits on one device. If it does not fit even at batch size one, it is model parallelism; if it fits but training is slow, it is data parallelism.
Revision schedule
- Day 1Map the blueprint and book a date
- Week 1Build the lifecycle decision map
- Weeks 1 to 3Go deep on scaling and serving (Domains 3 and 4)
- Weeks 3 to 4Lock pipelines and collaboration (Domains 5 and 2)
- Week 4Cover low-code and monitoring (Domains 1 and 6)