PMLE study plan by domain: use your diagnostic results

Build a PMLE study plan by mapping diagnostic gaps to Google’s six exam domains, then alternating focused exercises with mixed review. Use the approximate domain weights to balance coverage, not to promise readiness by a fixed date.

Official Google PMLE certification page. Updated October 17, 2026.

This is an editorial preparation plan, not a Google-prescribed schedule. It follows the official PMLE guide as of June 1, 2026. The example tasks are original exercises, not recalled exam questions.

Start with a baseline you can use

Read the PMLE certification overview before picking a timetable. Google recommends 3+ years of industry experience, including at least one year designing and managing Google Cloud solutions, and states no prerequisites. A recommendation is not an eligibility rule, but it should make you cautious about copying the schedule of someone with a different background.

Take a diagnostic before studying every topic again. When you inspect the domain breakdown, make separate notes for three kinds of gap:

• Decision gap: you cannot explain why an approach fits the scenario.
• Platform gap: you understand the ML problem but do not know the relevant Google Cloud choices.
• Reading gap: you missed a constraint or answered a different question from the one asked.

These are working labels for this plan, not official exam categories. They help you choose the next action. A platform gap calls for documentation and a small implementation. A reading gap calls for careful scenario comparison, not another long service tutorial.

Do not treat a diagnostic's readiness label as Google's passing standard. A small practice sample is evidence about what to investigate, not proof that a whole domain is mastered.

Keep the official weights visible

Google's approximate weights add to 101%. Do not change them to manufacture an exact allocation. Use them to avoid neglecting a major area, then adjust the work to your actual gaps. The domain explanations give more context for the decisions behind each heading.

Low-code AI: make a choice before writing a pipeline

Work through a business task with structured prediction data, then a different task involving documents or generated output. For each, write the required input, output, customization need and operational constraints. Compare relevant choices rather than assuming that every AI application needs custom training.

The guide names BigQuery ML, Agent Platform AutoML, AI APIs and foundation models, including Model Garden selection. It also explicitly covers Gemini fine-tuning using BigQuery and cost, latency and availability for Gemini applications. Use those objectives as prompts for your decision note, not as a shopping list of every model available.

Completion check: explain your chosen approach and why a plausible alternative is unnecessary or unsuitable under the stated constraints. If you cannot identify what new requirement would change your choice, revisit the assumptions.

Collaboration: make the result reproducible by a teammate

Choose a small experiment and document its data source, transformations, model or prompt version and evaluation. Introduce a privacy requirement. Explain how it affects the workflow and access to sensitive information.

Study preprocessing tool choice by scale and complexity. Google's examples include BigQuery SQL, Dataflow, Apache Spark and in-memory Python frameworks. You do not need to turn each study session into a large production deployment; you do need to explain which requirement would make a local approach insufficient.

The same domain includes notebooks, experiment tracking, predictive and generative evaluation, and artifacts and lineage. For a generative task, write down what a useful evaluation would need to distinguish. Do not assume that a judge model's output removes the need to define the evaluation problem.

Completion check: a teammate could identify what changed between two runs and what evidence supports the comparison, without asking you to reconstruct it from memory.

Scaling prototypes: separate model selection from execution

Pick a prototype you understand. Write a short training plan containing the target, evaluation approach, candidate model family and application constraints. The guide explicitly links model decisions to cost, complexity, latency, scalability and interpretability.

Next, consider a training failure or a resource constraint. List what you would inspect before changing hardware. Review CPU, GPU and TPU choices and the distinction between data and model parallelism because both appear in the guide's training scope.

Include foundation-model tuning in your review, but begin with the reason to tune. A technique is not automatically appropriate simply because the platform exposes it. Keep the reasoning tied to the task and the evidence you would use to compare a candidate with its baseline.

Completion check: defend a model and training approach, describe an alternative, and explain how you would investigate a failed run. If your answer is only “use a larger accelerator,” the exercise is unfinished.

Serving: follow the prediction into the consuming system

Draw the path from application input to useful output. Include preprocessing, model execution, postprocessing, access boundaries and the consumer's timing requirement. Compare an overnight scoring task with an interactive request to make the batch-versus-online decision concrete.

Review model containers, Model Registry, rollout comparisons, feature serving and throughput-based scaling. These appear explicitly in section 4. Avoid memorizing a rollout traffic percentage. State what you want to learn, which signals matter and what would make you stop or reverse the change.

Completion check: explain how the consumer gets a compatible prediction and how you would introduce another model version without losing track of what ran. Tie the design to latency, throughput and exposure requirements rather than choosing a hosting product first.

Pipelines: make the failure path explicit

Turn your training exercise into a workflow sketch. Mark the steps that validate inputs and candidate models. Record what starts retraining and what permits deployment; they are different decisions.

Google's guide names managed and unmanaged orchestration, templates and custom solutions, training-serving preprocessing consistency, and CI/CD/CT. It gives Agent Platform Pipelines, Managed Service for Apache Airflow and Ray on Agent Platform as orchestration examples. Read the relevant documentation for the workflow you are comparing rather than inferring service behavior from the names alone.

Describe what happens when a check fails. The plan should not require every candidate to replace the current model merely because the training job completed.

Completion check: someone can locate the trigger, validation gates, artifacts and response to failure in your sketch. You can explain why the orchestration approach fits the dependencies and operational responsibility.

Monitoring: prepare an investigation, not just an alert

Write a monitoring note for your example system. Separate infrastructure availability from useful model behavior. Google's guide names training-serving skew, data drift, concept drift and feature attribution drift. For each, describe the evidence you would seek before choosing an intervention.

Then add a generative AI risk review. The guide explicitly includes malicious prompting, data exfiltration and sensitive information shared with LLMs, alongside safety filters and Model Armor. State what risk each proposed control addresses instead of attaching a product name to an unspecified “security problem.”

Completion check: your note identifies the signal, the reference or evaluation needed, an investigation owner and the next decision. Do not make automatic retraining the answer to every kind of change.

Plan your study sessions without inventing a deadline

Use a repeating sequence: review a weak objective, do a focused exercise, explain the decision without notes, then try mixed practice. End each session by recording an unresolved question and the source you will check next.

If you have limited time, reduce the size of the exercise rather than dropping evaluation or operations entirely. A written design comparison can expose a misunderstanding before you spend time implementing it. When you do use cloud resources, check the relevant pricing and clean up the resources you create; this plan does not assume that every exercise is free.

Compare later diagnostic results with your original notes, but do not chase a number by repeatedly memorizing the same items. Look for independent evidence: can you explain a new scenario, reject a plausible alternative and connect your answer to current documentation?

Recheck the guide and exam logistics before booking

Confirm that your notes use the current domain structure and that you can recognize older Vertex AI terminology when reading resources. The June 2026 guide changes are a useful final audit of stale headings. Check booking details in the PMLE exam format guide, then verify them on Google's page before paying.

Start your baseline with the free PMLE diagnostic. Use its domain breakdown to pick the next exercise, not as an exam-outcome guarantee.

Sources

• Official PMLE certification page
• Official PMLE exam guide