PMLE — Google Cloud Professional Machine Learning Engineer Cheat Sheet
Compact PMLE Cheat sheet for Google Cloud machine learning engineering: Vertex AI, data pipelines, MLOps, security, monitoring, and decision points.
Use the tables for a quick pre-exam check. Expand a topic’s notes for explanations, examples, and additional distinctions.
Exam-use mental model
This independent Cheat Sheet supports candidates preparing for Google Cloud Professional Machine Learning Engineer - 2026 Guide from Google Cloud, exam code PMLE. Use it to rehearse service selection, ML lifecycle decisions, and common exam traps.
For most PMLE scenarios, choose the answer that best satisfies:
- Business objective first: metric, latency, freshness, cost, risk, explainability.
- Managed Google Cloud service when practical: reduce custom infrastructure unless requirements demand it.
- Reproducible ML lifecycle: version data, code, parameters, artifacts, metrics, and deployments.
- Secure by design: least privilege, private data paths, encryption, auditability.
- Monitor after deployment: prediction quality, drift, skew, latency, errors, and retraining triggers.
flowchart LR
A[Problem framing] --> B[Data ingestion and validation]
B --> C[Feature engineering]
C --> D[Training or tuning]
D --> E[Evaluation and model registry]
E --> F[Deployment: online, batch, or embedded]
F --> G[Monitoring and explainability]
G --> H[Retraining pipeline]
H --> C
Notes and examples
The PMLE mental model
A strong PMLE answer usually follows the full ML lifecycle, not just model training.
| Lifecycle stage | What to decide | High-yield PMLE focus |
|---|---|---|
| Business framing | What outcome matters? | Translate business goals into measurable ML objectives and constraints. |
| Data sourcing | What data is available and trustworthy? | Use appropriate storage, pipelines, schemas, labels, and access controls. |
| Feature preparation | How will inputs be transformed? | Prevent leakage, handle missing values, manage categorical features, and preserve training-serving consistency. |
| Model selection | What approach is practical? | Choose AutoML, BigQuery ML, custom training, pretrained APIs, or foundation models based on requirements. |
| Training and tuning | How will the model improve? | Use correct split strategy, metrics, hyperparameter tuning, distributed training, and regularization. |
| Evaluation | Is the model good enough? | Validate on holdout data, slices, fairness dimensions, latency, cost, and business impact. |
| Deployment | How will predictions be served? | Choose batch, online, streaming, endpoint, container, or custom serving patterns. |
| Monitoring | How will issues be detected? | Track skew, drift, prediction quality, latency, errors, and retraining triggers. |
| Governance | Is it secure and responsible? | Use IAM, encryption, auditability, privacy controls, explainability, and human review where needed. |
Fast decision rule
When a question gives you multiple technically possible answers, prefer the one that is:
- Managed when requirements are standard.
- Reproducible when training or deployment must be repeatable.
- Least privilege when security is involved.
- Observable when production reliability matters.
- Cost-aware when scale, idle resources, or accelerators are mentioned.
- Aligned to the metric when model quality is the issue.
High-yield Google Cloud service selection
Core ML and MLOps services
| Requirement | Prefer | Use when | Avoid when |
|---|---|---|---|
| End-to-end managed ML lifecycle | Vertex AI | Need managed training, tuning, model registry, endpoints, pipelines, metadata, monitoring | You only need simple SQL analytics or non-ML batch processing |
| Low-code model building | Vertex AI AutoML | Tabular, image, text, or similar tasks with limited custom architecture needs | Need full model architecture control, custom loss, specialized training loop |
| Custom model training | Vertex AI custom training | Need custom code, framework, containers, distributed training, GPUs/TPUs | SQL-native ML or AutoML meets requirements |
| SQL-native ML in warehouse | BigQuery ML | Data already in BigQuery; analysts use SQL; batch scoring is acceptable | Complex custom deep learning pipeline or low-latency online serving is required |
| Pretrained perception or language API | Google Cloud AI APIs / Vertex AI foundation models | Need fast integration without training from scratch | Need domain-specific model behavior, private fine-tuning, or custom serving logic |
| Pipeline orchestration for ML | Vertex AI Pipelines | Need reproducible ML steps, artifacts, metadata, lineage, scheduled retraining | General non-ML workflow is primary concern |
| General workflow orchestration | Cloud Composer or Workflows | Need broad DAG orchestration across services | Need ML-native lineage, artifacts, experiments, and model metadata |
| Experiment tracking | Vertex AI Experiments / TensorBoard | Need compare runs, parameters, metrics, artifacts | One-off notebook work with no reproducibility requirement |
| Model catalog and promotion | Vertex AI Model Registry | Need approve, version, deploy, rollback models | Model is never reused or governed |
| Online prediction | Vertex AI endpoints | Need managed low-latency serving, scaling, traffic splitting | Scoring can be delayed or done in bulk |
| Batch prediction | Vertex AI batch prediction or BigQuery ML batch scoring | Need score large datasets asynchronously | Interactive user request needs immediate response |
| Containerized custom inference | Vertex AI custom prediction container, Cloud Run, or GKE | Need custom pre/post-processing or nonstandard serving stack | Standard Vertex AI serving container is enough |
Notes and examples
Data and analytics services for ML
| Requirement | Prefer | Why it fits |
|---|---|---|
| Large analytical warehouse, SQL features, BI, BQML | BigQuery | Serverless analytics, feature extraction, training data assembly, batch scoring |
| Object storage for raw data, images, model artifacts | Cloud Storage | Durable storage for datasets, exports, checkpoints, training packages |
| Stream ingestion | Pub/Sub | Decouples producers and consumers; supports event-driven pipelines |
| Stream/batch transformations | Dataflow | Managed Apache Beam for scalable ETL, windowing, streaming features |
| Existing Spark/Hadoop jobs | Dataproc | Managed Spark/Hadoop when reusing ecosystem code |
| Metadata, governance, discovery | Dataplex / Data Catalog capabilities | Helps classify, discover, and govern data assets |
| Secrets | Secret Manager | Avoid hardcoded credentials in notebooks, containers, or pipelines |
| Container images | Artifact Registry | Version custom training and serving containers |
| CI/CD | Cloud Build plus deployment tooling | Build, test, and promote ML code and containers |
Google Cloud service map for PMLE
| Need | Common Google Cloud fit | Watch for |
|---|---|---|
| End-to-end ML platform | Vertex AI | Training, pipelines, model registry, endpoints, batch prediction, experiments, monitoring. |
| SQL-based analytics and modeling | BigQuery and BigQuery ML | Good for large structured data already in BigQuery; not always best for complex custom deep learning. |
| Object storage for datasets and artifacts | Cloud Storage | Raw files, images, exports, model artifacts, staging data. |
| Batch and streaming data processing | Dataflow | Apache Beam pipelines, scalable ETL, streaming feature generation. |
| Spark or Hadoop workloads | Dataproc | Existing Spark jobs, migration of Hadoop/Spark pipelines, large-scale transformations. |
| Event ingestion | Pub/Sub | Decoupled streaming ingestion, event-driven ML pipelines. |
| Workflow orchestration | Vertex AI Pipelines, Cloud Composer, Workflows | Choose based on ML-native pipeline needs versus general orchestration. |
| Container build and artifact storage | Cloud Build and Artifact Registry | CI/CD, reproducible containers, secure image management. |
| Custom serving | Vertex AI endpoints, GKE, Cloud Run | Vertex AI for managed prediction; GKE/Cloud Run for custom app-level requirements. |
| Monitoring and logs | Cloud Monitoring and Cloud Logging | Latency, error rates, resource metrics, pipeline failures, service health. |
| Secrets and keys | Secret Manager and Cloud KMS | Avoid secrets in code, notebooks, containers, or environment files. |
| Identity and access | IAM and service accounts | Least privilege, separation of duties, workload-specific permissions. |
| Data protection | Sensitive Data Protection, VPC Service Controls, CMEK where required | Use when data sensitivity, boundaries, or encryption control are explicit requirements. |
PMLE decision tables
AutoML vs custom training vs BigQuery ML vs pretrained model
| Scenario clue | Best fit | Reasoning |
|---|---|---|
| “Fast baseline,” “limited ML expertise,” “standard tabular/image/text problem” | Vertex AI AutoML | Managed feature processing, training, tuning, and evaluation |
| “Custom loss,” “custom neural network,” “special preprocessing,” “research model” | Vertex AI custom training | Full code and framework control |
| “Data is in BigQuery,” “team uses SQL,” “batch predictions,” “no custom serving” | BigQuery ML | Keeps ML close to warehouse data and SQL workflows |
| “Need sentiment/OCR/speech/translation quickly” | Pretrained Google Cloud AI APIs | No training pipeline required |
| “Need private enterprise answers from documents” | Vertex AI foundation model with grounding/RAG | Injects current/private facts without training model from scratch |
| “Need specialized language/style/task adaptation” | Tuning on Vertex AI, when supported | Changes behavior more than prompting, less work than full custom training |
| “Strict control over weights, architecture, training data, serving” | Custom model on Vertex AI | Required when managed abstractions are insufficient |
Notes and examples
Online vs batch prediction
| Requirement | Choose | Watch for |
|---|---|---|
| User-facing request/response | Online prediction endpoint | Latency, autoscaling, model size, input validation |
| Millions of rows scored overnight | Batch prediction | Throughput, output location, idempotency |
| Scores joined with warehouse tables | BigQuery ML prediction or batch output to BigQuery | SQL governance and reproducibility |
| Event-driven near-real-time scoring | Pub/Sub + Dataflow + online endpoint or streaming architecture | Backpressure, retry behavior, duplicate handling |
| Very low latency with custom serving logic | Cloud Run or GKE may be considered | More operational responsibility than managed endpoint |
| Model embedded on device or edge | Exported model format if supported | Update strategy, device constraints, monitoring limitations |
Pipeline orchestration choice
| Need | Prefer | Exam distinction |
|---|---|---|
| ML steps with artifacts, metadata, lineage | Vertex AI Pipelines | PMLE default for reproducible MLOps |
| Airflow DAG already orchestrates enterprise data platform | Cloud Composer | Good for heterogeneous scheduled workflows |
| Simple service-to-service workflow | Workflows | Lightweight orchestration, not ML-specific |
| Pure ETL transform at scale | Dataflow | Data processing engine, not experiment tracker |
| CI/CD build-test-deploy | Cloud Build | Build automation, not training lineage by itself |
Data preparation and feature engineering
Data split patterns
| Data type | Recommended split | Common trap |
|---|---|---|
| Independent tabular rows | Random or hash-based split | Non-reproducible random split causing changing metrics |
| Time series | Time-based split: train on past, validate on future | Random split leaks future information |
| User behavior | Split by user/entity when leakage across rows is possible | Same user appears in train and test |
| Image/text duplicates | Deduplicate or group before split | Near-duplicates inflate evaluation |
| Imbalanced classification | Stratified split when appropriate | Minority class disappears from validation/test |
| Streaming data | Hold out later time windows | Offline test set does not match production freshness |
Notes and examples
Stable BigQuery split pattern:
SELECT
*,
CASE
WHEN MOD(ABS(FARM_FINGERPRINT(CAST(customer_id AS STRING))), 10) < 8 THEN 'TRAIN'
WHEN MOD(ABS(FARM_FINGERPRINT(CAST(customer_id AS STRING))), 10) = 8 THEN 'VALIDATE'
ELSE 'TEST'
END AS split
FROM `project.dataset.source_table`;
Feature transformation location
| Transform location | Use when | Risk |
|---|---|---|
| BigQuery SQL | Batch features, warehouse-native joins, aggregations | Training-serving skew if online path reimplements logic differently |
| Dataflow / Apache Beam | Streaming features, large-scale ETL, unified batch/stream processing | Operational complexity if simple SQL is enough |
tf.Transform-style pipeline step | Need identical training and serving transforms | More pipeline complexity |
| Model preprocessing layer | Transform must be packaged with model | Can increase serving latency |
| Feature store / online feature serving | Need consistent offline/online features and low-latency lookup | Requires governance around freshness and keys |
| Application code | Simple request formatting | High skew risk if business logic diverges from training |
Data quality checks to rehearse
| Check | Why it matters |
|---|---|
| Schema validation | Detects missing, renamed, or type-changed fields |
| Range checks | Finds impossible values, unit errors, and outliers |
| Null/missingness tracking | Missingness may be predictive or indicate broken ingestion |
| Label validation | Incorrect labels can cap model performance |
| Class distribution | Prevents misleading accuracy on imbalanced data |
| Train/serve feature parity | Reduces skew between offline training and online prediction |
| Duplicate detection | Prevents leakage and inflated metrics |
| Time-window correctness | Prevents future data from entering features |
| PII/sensitive data classification | Supports least privilege and privacy controls |
Data preparation and feature engineering
Good PMLE answers protect model quality before training begins.
| Topic | Review points | Candidate mistakes |
|---|---|---|
| Data quality | Validate schema, ranges, missingness, duplicates, outliers, label consistency. | Training on unvalidated data because the model “can learn around it.” |
| Data splits | Use train/validation/test; time-based splits for time-dependent data; group splits for related records. | Random split when users, devices, households, or future events leak across splits. |
| Label quality | Check labeling instructions, consensus, inter-rater agreement, delay between event and label. | Treating noisy labels as ground truth without validation. |
| Feature leakage | Exclude fields unavailable at prediction time or derived from the target. | Including post-event data, future aggregates, or target-encoded features incorrectly. |
| Missing values | Impute consistently; add missingness indicators when meaningful. | Using different missing-value logic in training and serving. |
| Categorical features | Use one-hot, embeddings, hashing, or native handling depending on model type and cardinality. | One-hot encoding extremely high-cardinality features without considering memory or generalization. |
| Numerical features | Scale when using distance-based models, linear models, neural networks, or gradient-sensitive methods. | Scaling unnecessarily for tree models, or fitting scalers on all data before splitting. |
| Text/image/audio | Use appropriate preprocessing, pretrained models, embeddings, or specialized architectures. | Building custom models when pretrained APIs or foundation models would meet requirements. |
| Feature reuse | Centralize transformations and feature definitions where possible. | Duplicating feature logic across training and serving code. |
Training-serving skew
Training-serving skew occurs when the model sees one feature distribution or transformation during training and a different one during prediction.
Common causes:
- Different preprocessing code paths for training and serving.
- Time-window aggregations computed differently offline and online.
- Missing values handled differently in production.
- Categorical vocabularies not frozen or versioned.
- Feature values available in batch training but unavailable at request time.
- Data schema changes not detected before prediction.
Best review answer: use shared transformation logic, versioned artifacts, schema validation, pipeline automation, and monitoring for skew or drift.
Modeling and evaluation reference
Metric selection
| Problem type | Prefer metrics | Use when | Trap |
|---|---|---|---|
| Balanced classification | Accuracy, log loss, AUC | Classes are roughly balanced and error costs similar | Accuracy hides minority-class failure |
| Imbalanced classification | Precision, recall, F1, PR AUC | Fraud, churn, abuse, rare disease, anomaly review queues | ROC AUC can look good while precision is poor |
| Ranking/recommendation | NDCG, MAP, precision@k, recall@k | Top results matter more than all predictions | Optimizing overall accuracy instead of ranked utility |
| Regression | RMSE, MAE, R-squared | Predict continuous values | RMSE over-penalizes large errors; MAE may hide severe outliers |
| Forecasting | MAE, RMSE, MAPE, weighted errors | Time-dependent demand or capacity | Random split and MAPE issues near zero values |
| Clustering | Silhouette, Davies-Bouldin, business validation | No labels available | Treating unsupervised score as proof of business value |
| Generative AI | Groundedness, factuality, safety, task success, human preference | Open-ended outputs | Evaluating only fluency and ignoring hallucination |
Notes and examples
For binary classification:
\[ \text{Precision}=\frac{TP}{TP+FP} \]\[ \text{Recall}=\frac{TP}{TP+FN} \]\[ F1=2\cdot\frac{\text{Precision}\cdot\text{Recall}}{\text{Precision}+\text{Recall}} \]\[ \text{Accuracy}=\frac{TP+TN}{TP+TN+FP+FN} \]Threshold and error-cost decisions
| Requirement | Decision |
|---|---|
| False positives are expensive | Increase precision; raise threshold |
| False negatives are expensive | Increase recall; lower threshold |
| Human review capacity is limited | Optimize precision@k or top-k workload |
| Regulatory or customer-impacting decision | Favor explainability, monitoring, audit logs, and human review |
| Need calibrated probabilities | Evaluate calibration, not just ranking |
| Class distribution shifts in production | Monitor prediction distribution and labels when available |
Model family shortcuts
| Model family | Strength | Weakness | Exam clue |
|---|---|---|---|
| Linear/logistic regression | Simple, interpretable, fast | Limited nonlinear patterns | Baseline, explainability |
| Tree-based models / boosted trees | Strong for tabular data, handles nonlinearities | Less ideal for raw images/text | Structured business data |
| Deep neural networks | Flexible, high capacity | Needs more data/tuning | Images, text, complex signals |
| CNNs | Spatial patterns | Image-specific architecture | Vision workloads |
| Transformers | Text, multimodal, generative tasks | Cost, latency, safety evaluation | NLP, LLM, embeddings |
| Matrix factorization / two-tower retrieval | Recommendations and retrieval | Cold-start handling needed | Users/items, candidate generation |
| Time-series models | Temporal structure | Must respect time ordering | Forecasting demand, capacity, traffic |
Generative AI and foundation-model decisions
| Requirement | Prefer | Why |
|---|---|---|
| Prototype text generation, summarization, extraction | Vertex AI foundation model prompting | Fastest path; no training data required |
| Need answers grounded in private documents | Retrieval-augmented generation | Keeps facts in external corpus and reduces stale knowledge risk |
| Need enterprise search over documents | Vertex AI Search / grounding-oriented architecture | Managed retrieval and relevance features |
| Need domain-specific style or task behavior | Model tuning, if supported for selected model | Adjusts behavior beyond prompt engineering |
| Need deterministic structured extraction | Prompt with schema, validation, and post-processing | LLM output should still be validated |
| Need safety controls | Safety settings, content filters, allowlists, human review | Do not rely only on prompt wording |
| Need evaluate generated answers | Human evaluation plus automated checks | Fluency is not enough |
Notes and examples
Common generative AI traps:
- Using fine-tuning to add frequently changing facts when RAG is more appropriate.
- Ignoring grounding, citation, and hallucination checks.
- Sending sensitive data to prompts without access control and logging review.
- Evaluating only on “good looking” outputs instead of task-specific test sets.
- Forgetting latency and token cost tradeoffs for long prompts and large contexts.
Generative AI and foundation model review
For 2026 PMLE preparation, treat generative AI as part of production ML engineering: data grounding, evaluation, safety, latency, cost, and governance matter more than prompt cleverness alone.
| Need | Review approach |
|---|---|
| Summarization or generation | Use a foundation model through a managed platform such as Vertex AI when appropriate. |
| Domain-specific Q&A | Consider retrieval-augmented generation using embeddings, vector search, and grounded context. |
| Semantic search | Generate embeddings and search by vector similarity. |
| Safer outputs | Use grounding, safety controls, content filtering, prompt constraints, and human review. |
| Better domain behavior | Compare prompt engineering, RAG, supervised tuning, or other adaptation methods based on data and risk. |
| Evaluation | Measure relevance, factuality, groundedness, toxicity/safety, latency, and user satisfaction. |
| Cost control | Cache where appropriate, reduce prompt size, choose model size carefully, batch offline jobs when possible. |
| Governance | Log prompts/responses carefully, protect sensitive data, and define retention policies. |
Generative AI traps
- Sending confidential data to a model without checking privacy and access requirements.
- Assuming generated text is factual without grounding or validation.
- Evaluating only with subjective examples instead of a repeatable test set.
- Using a large general model when embeddings, search, or a smaller model would solve the problem.
- Ignoring prompt injection, unsafe content, data leakage, or hallucination risk.
- Treating RAG as automatic truth rather than a system that needs retrieval quality, chunking strategy, and evaluation.
Vertex AI lifecycle checkpoints
| Lifecycle step | What to remember for PMLE |
|---|---|
| Dataset creation | Validate schema, labels, splits, and access permissions before training |
| Training | Choose AutoML, custom training, BigQuery ML, or foundation model approach based on constraints |
| Hyperparameter tuning | Use when model class is appropriate but performance depends on configuration |
| Experiments | Track parameters, metrics, source version, data version, and artifact location |
| Model Registry | Version and promote models through review stages |
| Deployment | Choose endpoint, batch prediction, or custom serving target based on latency and throughput |
| Traffic splitting | Use for canary, A/B test, or gradual rollout where supported |
| Monitoring | Track skew, drift, prediction distribution, latency, errors, and business KPIs |
| Retraining | Automate with pipeline triggers, validation gates, and rollback plan |
Notes and examples
Custom training pattern
Use custom training when you need control over model code, libraries, training loop, hardware, or distributed strategy.
High-yield components:
| Component | Purpose |
|---|---|
| Training container | Reproducible runtime with dependencies |
| Training service account | Reads training data, writes artifacts, logs metrics |
| Cloud Storage / Artifact Registry | Stores packages, containers, model artifacts |
| Vertex AI custom job | Runs managed training workload |
| Vertex AI hyperparameter tuning | Searches parameter space with managed trials |
| Vertex AI Experiments / Metadata | Tracks run lineage and metrics |
Minimal command-shape recognition:
gcloud ai custom-jobs create \
--region=REGION \
--display-name=JOB_NAME \
--worker-pool-spec=machine-type=MACHINE_TYPE,replica-count=1,container-image-uri=IMAGE_URI
Do not memorize flags as the main skill. For the exam, understand why a custom job is chosen and which service account, data path, artifact path, and region it uses.
BigQuery ML quick patterns
Use BigQuery ML when the training data is already in BigQuery and SQL-native training/scoring satisfies the requirement.
CREATE OR REPLACE MODEL `project.dataset.churn_model`
OPTIONS(
model_type = 'BOOSTED_TREE_CLASSIFIER',
input_label_cols = ['churned']
) AS
SELECT
* EXCEPT(customer_id, split)
FROM `project.dataset.training_features`
WHERE split = 'TRAIN';
SELECT
*
FROM ML.EVALUATE(
MODEL `project.dataset.churn_model`,
(
SELECT * EXCEPT(customer_id, split)
FROM `project.dataset.training_features`
WHERE split = 'TEST'
)
);
SELECT
customer_id,
predicted_churned,
predicted_churned_probs
FROM ML.PREDICT(
MODEL `project.dataset.churn_model`,
(
SELECT * EXCEPT(churned, split)
FROM `project.dataset.scoring_features`
)
);
BigQuery ML exam clues:
| Clue | Interpretation |
|---|---|
| Analysts prefer SQL | BigQuery ML is likely |
| Model training data is warehouse-native | Avoid unnecessary export |
| Need batch scoring into tables | BigQuery ML or Vertex AI batch prediction |
| Need low-latency endpoint | BigQuery ML alone is usually not the best fit |
| Need complex custom neural architecture | Use Vertex AI custom training instead |
MLOps, CI/CD, and reproducibility
What to version
| Asset | Why it matters |
|---|---|
| Source code | Reproduce training and serving behavior |
| Container image | Reproduce runtime dependencies |
| Data snapshot or query | Reproduce training set |
| Feature definitions | Prevent train/serve mismatch |
| Hyperparameters | Explain metric differences |
| Metrics and evaluation reports | Compare candidate models |
| Model artifact | Promote, rollback, and audit |
| Pipeline definition | Recreate workflow |
| Service account and IAM changes | Investigate access and security issues |
Notes and examples
Deployment patterns
| Pattern | Use when | Watch for |
|---|---|---|
| Manual deployment | Prototype only | Not reproducible or auditable |
| CI/CD to staging then production | Production ML service | Add evaluation and approval gates |
| Canary deployment | Validate new model on small traffic share | Monitor error rates and KPIs |
| A/B testing | Compare business impact | Requires experiment design and unbiased assignment |
| Shadow deployment | Observe new model without affecting users | Needs duplicate inference and log analysis |
| Blue/green | Fast rollback between versions | Requires parallel environment readiness |
| Batch replacement | Periodic scoring pipeline | Validate output schema and downstream consumers |
Pipeline validation gates
| Gate | Failure should block |
|---|---|
| Data schema check | Training with incompatible data |
| Data quality threshold | Training on corrupt or incomplete data |
| Minimum evaluation metric | Promoting weak model |
| Fairness/slice metric regression | Shipping model harmful to a segment |
| Latency/load test | Deploying model that cannot serve traffic |
| Security scan | Deploying vulnerable container or dependency |
| Explainability or review requirement | Releasing opaque high-risk model |
Deployment patterns
| Prediction need | Recommended pattern | Notes |
|---|---|---|
| Low-latency per-request predictions | Online prediction endpoint | Use managed Vertex AI endpoints when standard serving is sufficient. |
| Large scheduled scoring jobs | Batch prediction | Better for offline scoring, reports, recommendations, or periodic risk scoring. |
| Event-driven scoring | Pub/Sub with Dataflow, Cloud Run, or other processing | Useful for streaming use cases and decoupled ingestion. |
| Embedded app-specific inference | Cloud Run or GKE | Use when serving requires custom APIs, routing, or orchestration. |
| Heavy model with specialized hardware | Endpoint with appropriate accelerator | Validate latency, throughput, cost, and autoscaling behavior. |
| Edge or disconnected inference | Exported or optimized model | Consider model size, update mechanism, and device constraints. |
Deployment decision rules
- If the model is called synchronously by an application, think online prediction.
- If millions of records are scored overnight, think batch prediction.
- If events arrive continuously, think streaming pipeline.
- If the question emphasizes managed ML lifecycle, think Vertex AI.
- If the question emphasizes custom application serving, networking, or microservices, consider Cloud Run or GKE.
- If the question emphasizes rollback safety, choose canary, blue/green, or versioned endpoint deployment.
Security, IAM, and governance
Security controls matrix
| Concern | Google Cloud control pattern | PMLE decision point |
|---|---|---|
| Least privilege | Use service accounts with minimal roles | Avoid broad Owner/Editor grants |
| Human access | Grant developers only needed Vertex AI, BigQuery, Storage, and service account permissions | Separate human identity from runtime identity |
| Runtime identity | Dedicated service account for training, pipeline, and prediction | Do not run jobs with personal credentials |
| Sensitive data | BigQuery policy tags, row/column-level controls, DLP-style inspection where appropriate | Protect training data and features |
| Network boundary | Private access patterns, VPC controls where required | Avoid public exposure for sensitive workloads |
| Encryption control | Google-managed encryption by default; CMEK where required | Ensure services and artifacts support required key usage |
| Secrets | Secret Manager | Do not bake secrets into images, notebooks, or environment files |
| Auditability | Cloud Audit Logs, Cloud Logging | Needed for regulated or high-risk ML workflows |
| Container supply chain | Artifact Registry, build scanning, pinned dependencies | Reproducible and reviewable deployments |
| Data exfiltration risk | VPC Service Controls where appropriate | Especially relevant for managed service access to sensitive data |
Notes and examples
IAM role-shape reminders
| Principal | Needs | Avoid |
|---|---|---|
| Data scientist | Submit jobs, read approved datasets, view experiments | Broad project admin |
| Training job service account | Read training data, write model artifacts, write logs | Access to unrelated production data |
| Pipeline service account | Orchestrate pipeline components and pass approved runtime accounts | Ability to modify all IAM |
| Prediction service | Serve model and write logs/metrics | Access to raw training data unless required |
| CI/CD service account | Build containers, push artifacts, deploy approved models | Personal credentials or unrestricted production access |
| Monitoring operator | Read metrics/logs, acknowledge alerts | Ability to alter training data or models unnecessarily |
Monitoring and troubleshooting
Production ML monitoring signals
| Signal | What it detects |
|---|---|
| Prediction latency | Serving bottlenecks, oversized model, cold starts, downstream delays |
| Error rate | Bad inputs, container failures, dependency issues |
| Input feature distribution | Data drift, schema changes, source system changes |
| Training-serving skew | Different feature logic or data freshness between train and serve |
| Prediction distribution | Collapsed model, threshold issue, unexpected population shift |
| Ground-truth performance | Real model quality after labels arrive |
| Slice metrics | Degradation for specific user, region, product, or demographic segment |
| Resource utilization | Under/over-provisioning, accelerator bottlenecks |
| Business KPI | Whether ML improvement matters operationally |
Notes and examples
Troubleshooting runbook
| Symptom | Likely causes | First actions |
|---|---|---|
| Custom training job fails immediately | Bad container entrypoint, missing dependency, IAM denial, invalid path | Check logs, image URI, service account permissions, artifact locations |
| Training cannot read data | Runtime service account lacks BigQuery/Storage access | Grant least-privilege read to the training service account |
| Out-of-memory during training | Batch too large, model too large, inefficient input pipeline | Reduce batch size, use larger machine, optimize data loading |
| Training is slow | Input bottleneck, no accelerator use, poor sharding, cross-region data | Co-locate resources, optimize input pipeline, profile workload |
| Great validation, poor production | Leakage, skew, nonrepresentative split, stale features | Rebuild split, compare train/serve features, inspect production distribution |
| Accuracy high but business impact poor | Wrong metric, imbalance, bad threshold | Optimize metric aligned to cost and decision process |
| Endpoint latency high | Model size, inefficient preprocessing, no batching, scaling config | Profile preprocessing/model, use efficient serving container, tune scaling |
| Drift alert fires | Source distribution changed, upstream bug, seasonality | Validate data source, compare slices, retrain only after quality review |
| Pipeline not reproducible | Unversioned data/code/image, nondeterministic split | Pin versions, use stable split, log parameters and artifacts |
| Permission error in pipeline | Wrong runtime account or missing pass-through permission | Identify executing principal and grant minimal required role |
Responsible AI and explainability
| Topic | Exam-ready action |
|---|---|
| Fairness | Evaluate metrics by relevant slices, not only aggregate score |
| Explainability | Use feature attribution/explanations where supported and meaningful |
| Bias in labels | Inspect label source and sampling process |
| Privacy | Minimize sensitive features and control access to raw data |
| Human oversight | Add review for high-impact automated decisions |
| Model cards / documentation | Record intended use, limitations, metrics, training data summary |
| Safety for generative AI | Evaluate harmful content, hallucination, leakage, and prompt injection |
| Monitoring | Watch for drift and quality regressions after deployment |
| Feedback loops | Avoid model decisions contaminating future labels without controls |
Common trap: “The model has high AUC, so it is ready.” PMLE-style answers often require slice evaluation, threshold selection, explainability, security review, and production monitoring before release.
Notes and examples
Responsible AI and explainability
PMLE scenarios may ask for a technically sound model that is also safe, fair, interpretable, and governable.
| Concern | Practical response |
|---|---|
| Bias in training data | Analyze representativeness, label quality, and slice performance. |
| Unequal error rates | Evaluate metrics by subgroup; adjust data, thresholds, or model strategy. |
| Explainability requirement | Use interpretable models, feature attribution, example explanations, or documentation. |
| Human impact | Add human review for high-risk decisions. |
| Transparency | Document model purpose, limitations, data sources, and evaluation results. |
| Monitoring fairness | Track production performance across relevant slices when labels are available. |
| Feedback loops | Watch for models that influence future training data, such as recommendations or moderation systems. |
Architecture patterns to recognize
Managed tabular prediction
| Layer | Typical choice |
|---|---|
| Data | BigQuery |
| Training | Vertex AI AutoML or BigQuery ML |
| Pipeline | Vertex AI Pipelines |
| Registry | Vertex AI Model Registry |
| Serving | Vertex AI endpoint for online; BigQuery ML or batch prediction for offline |
| Monitoring | Vertex AI monitoring plus business KPI tracking |
Notes and examples
Choose this when the task is standard tabular ML and custom architecture is not required.
Streaming fraud or anomaly scoring
| Layer | Typical choice |
|---|---|
| Ingestion | Pub/Sub |
| Feature computation | Dataflow streaming |
| Storage | BigQuery for analytics; feature store/low-latency store if needed |
| Serving | Vertex AI endpoint or custom low-latency service |
| Monitoring | Latency, error rate, precision/recall after labels arrive |
Key traps: class imbalance, delayed labels, duplicate events, threshold tuning, false positive cost.
Batch forecasting
| Layer | Typical choice |
|---|---|
| Historical data | BigQuery or Cloud Storage |
| Feature creation | BigQuery SQL, Dataflow, or pipeline component |
| Training | BigQuery ML, AutoML, or custom training depending on complexity |
| Scoring | Scheduled batch prediction |
| Output | BigQuery table for downstream planning |
| Validation | Time-based backtesting |
Key trap: random split leaks future data.
Document-grounded generative AI
| Layer | Typical choice |
|---|---|
| Document ingestion | Controlled storage and indexing pipeline |
| Retrieval | Managed search/vector retrieval pattern |
| Generation | Vertex AI foundation model |
| Controls | Grounding, citations, safety settings, prompt injection defenses |
| Evaluation | Groundedness, factuality, task completion, human review |
Key trap: fine-tuning a model to memorize private documents when retrieval is the safer, fresher design.
Common PMLE traps
| Trap | Better answer |
|---|---|
| Choose custom Kubernetes for every ML workload | Prefer Vertex AI managed services unless requirements demand custom orchestration |
| Optimize accuracy on imbalanced data | Use precision, recall, F1, PR AUC, threshold tuning |
| Randomly split time-series data | Use time-based validation and backtesting |
| Ignore training-serving skew | Reuse transformation logic or centralize feature definitions |
| Train with personal credentials | Use dedicated service accounts |
| Store secrets in notebooks or containers | Use Secret Manager |
| Deploy model without monitoring | Add latency, errors, drift/skew, and quality monitoring |
| Fine-tune LLM to add changing facts | Use RAG/grounding for factual enterprise knowledge |
| Export BigQuery data unnecessarily | Use BigQuery ML or native integrations when suitable |
| Use online prediction for offline bulk scoring | Use batch prediction or warehouse scoring |
| Compare models on different data splits | Use consistent test data and logged experiments |
| Promote model based only on aggregate metric | Check slices, business cost, fairness, and operational constraints |
Notes and examples
Common PMLE scenario traps
| Trap | Better reasoning |
|---|---|
| Choosing the newest or most complex service | Prefer the simplest managed option that meets requirements. |
| Optimizing accuracy for imbalanced data | Use metrics aligned to positive-class and business costs. |
| Randomly splitting time-series data | Use time-based validation to avoid future leakage. |
| Training and serving with separate preprocessing logic | Share transformations and version preprocessing artifacts. |
| Deploying after validation only | Add monitoring, rollback, and production guardrails. |
| Using batch prediction for low-latency app calls | Use online prediction when synchronous latency matters. |
| Using online prediction for massive scheduled scoring | Use batch prediction to reduce operational overhead. |
| Scaling compute before fixing data pipeline bottlenecks | Check input pipeline, preprocessing, and storage throughput. |
| Retraining automatically on bad data | Validate data before training and gate deployment on evaluation. |
| Granting broad permissions to simplify setup | Use least privilege and service-account separation. |
| Ignoring labels that arrive late | Design delayed ground-truth evaluation and monitoring. |
| Assuming offline improvement guarantees business improvement | Use canary, A/B testing, or business KPI validation. |
| Not versioning datasets | Reproducibility requires dataset, code, config, and artifact versions. |
| Using foundation models without safety evaluation | Add groundedness, safety, privacy, and human-risk checks. |
Last-minute checklist
Before answering a PMLE scenario question, identify:
- Task: classification, regression, forecasting, ranking, generation, clustering, anomaly detection.
- Data location: BigQuery, Cloud Storage, streaming, external source.
- Latency: online request, near-real-time stream, scheduled batch.
- Control level: AutoML, BigQuery ML, custom training, foundation model, pretrained API.
- Metric: aligned to business cost and class balance.
- Split: leakage-resistant and time-aware if needed.
- Pipeline: reproducible, versioned, and automated.
- Security: service accounts, least privilege, sensitive data controls.
- Deployment: endpoint, batch job, warehouse scoring, or custom serving.
- Monitoring: drift, skew, latency, errors, ground-truth performance.
- Rollback: model versioning, canary/shadow/blue-green where appropriate.
PMLE Cheat Sheet focus
This Cheat Sheet is for candidates preparing for Google Cloud’s Professional Machine Learning Engineer (PMLE) exam. It is IT Mastery review support, not affiliated with Google Cloud, and is designed to help you quickly reinforce high-yield concepts before using topic drills, mock exams, and detailed explanations.
For PMLE, do not study machine learning as isolated algorithms only. The exam is usually most challenging when it asks you to choose a practical Google Cloud design that balances model quality, reliability, security, cost, monitoring, and operational maintainability.
Use this page to review:
- How to frame ML problems and choose evaluation metrics.
- When to use Vertex AI, BigQuery ML, Dataflow, Dataproc, Cloud Storage, Pub/Sub, GKE, Cloud Run, and related Google Cloud services.
- How to prepare data, avoid leakage, and reduce training-serving skew.
- How to deploy, monitor, retrain, and govern models in production.
- How to reason through scenario questions without memorizing product trivia.
Problem framing and metrics
PMLE scenarios often test whether you choose the right objective before choosing tools. A technically sophisticated model can still be wrong if it optimizes the wrong metric.
| Problem type | Useful metrics | Common traps |
|---|---|---|
| Binary classification | Precision, recall, F1, ROC AUC, PR AUC, log loss | Accuracy can be misleading with class imbalance. |
| Multiclass classification | Macro/micro F1, top-k accuracy, confusion matrix | Overall accuracy can hide poor minority-class performance. |
| Regression | MAE, RMSE, RMSLE, R-squared | RMSE over-penalizes large errors; MAE may be better when robustness matters. |
| Ranking/recommendation | NDCG, MAP, MRR, CTR, conversion rate | Offline ranking metrics may not match user behavior in production. |
| Forecasting | MAE, RMSE, MAPE, WAPE, MASE | Random splits can leak future information. |
| Anomaly detection | Precision, recall, PR AUC, false positive rate | Rare events make accuracy nearly useless. |
| Clustering | Silhouette score, Davies-Bouldin, business validation | Unsupervised metrics do not guarantee useful segments. |
| Generative AI output | Groundedness, factuality, safety, relevance, human preference | BLEU-like text metrics may not capture business risk or factual correctness. |
Notes and examples
Key classification formulas:
\[ \text{Precision} = \frac{\text{True Positives}}{\text{True Positives} + \text{False Positives}} \]\[ \text{Recall} = \frac{\text{True Positives}}{\text{True Positives} + \text{False Negatives}} \]\[ \text{F1} = 2 \times \frac{\text{Precision} \times \text{Recall}}{\text{Precision} + \text{Recall}} \]Metric decision rules
| If the scenario says… | Prioritize… |
|---|---|
| “False positives are expensive” | Precision or specificity. |
| “Missing a positive case is dangerous” | Recall or sensitivity. |
| “Classes are highly imbalanced” | PR AUC, F1, class-weighted metrics, stratified evaluation. |
| “Predicted probabilities are used for decisions” | Calibration and log loss, not just class labels. |
| “Large errors are especially bad” | RMSE or custom loss. |
| “Outliers should not dominate” | MAE or robust loss. |
| “Business cost differs by error type” | Custom cost function or threshold optimization. |
| “Model must rank best candidates first” | Ranking metrics such as NDCG or MAP. |
Threshold trap
Many candidates assume a classification threshold of 0.5. In production, the threshold should usually be selected based on business cost, precision-recall tradeoff, capacity constraints, or risk tolerance. Training a model and choosing an operating threshold are separate decisions.
Model selection: managed, custom, or foundation model?
PMLE questions often include clues about team skills, time constraints, explainability, customization, data volume, latency, and governance.
| Approach | Use when | Avoid when |
|---|---|---|
| Pretrained Google Cloud APIs | Standard tasks such as vision, speech, translation, document, or language extraction fit the use case. | You need deep customization, domain-specific labels, or strict control over model internals. |
| Vertex AI AutoML | You need strong baseline performance with limited ML engineering effort. | You require custom architecture, unusual loss functions, or specialized training loops. |
| BigQuery ML | Data is already in BigQuery and the model can be built using supported SQL-based workflows. | The workload requires complex custom deep learning or custom serving logic. |
| Custom training on Vertex AI | You need custom code, frameworks, tuning, distributed training, or specialized containers. | A managed AutoML or pretrained option satisfies requirements more simply. |
| Imported model on Vertex AI | You already have a trained model and want managed deployment/serving. | The model needs substantial retraining or incompatible serving dependencies. |
| GKE or Cloud Run custom serving | You need custom inference orchestration, special networking, or app-specific serving behavior. | A standard managed Vertex AI endpoint is sufficient. |
| Foundation model through Vertex AI | Use cases involve generation, summarization, chat, extraction, embeddings, or semantic search. | Deterministic, low-risk, fully explainable traditional ML is required and generation adds unnecessary risk. |
Notes and examples
AutoML versus custom training
Choose AutoML when the exam scenario emphasizes:
- Fast development.
- Limited ML expertise.
- Standard tabular, image, text, or video use cases.
- Managed training and tuning.
- A strong baseline without custom architecture.
Choose custom training when it emphasizes:
- Custom loss functions or metrics.
- Specialized model architectures.
- Complex preprocessing or training loops.
- Distributed training.
- Framework-specific requirements.
- Full control over dependencies and containers.
Training, tuning, and optimization
Overfitting versus underfitting
| Symptom | Likely issue | Practical fix |
|---|---|---|
| High training performance, poor validation performance | Overfitting | More data, regularization, dropout, simpler model, early stopping, augmentation. |
| Poor training and validation performance | Underfitting | More expressive model, better features, longer training, lower regularization. |
| Validation performance unstable | Small validation set or noisy labels | Better split, cross-validation, label review, more data. |
| Great offline metrics, poor production results | Skew, leakage, drift, or wrong metric | Validate feature availability, monitor production, reassess metric. |
| Model improves but latency is too high | Serving inefficiency | Optimize model, use batch prediction, quantization, distillation, accelerators, or simpler architecture. |
Notes and examples
Hyperparameter tuning review
High-yield hyperparameters:
- Learning rate.
- Batch size.
- Number of layers or trees.
- Regularization strength.
- Dropout rate.
- Maximum tree depth.
- Embedding dimension.
- Optimizer choice.
- Early stopping patience.
Common traps:
- Tuning on the test set.
- Reporting the best validation score as final test performance.
- Ignoring cost and time of large tuning jobs.
- Changing data preprocessing during tuning without versioning it.
- Optimizing a proxy metric that does not match the business objective.
Distributed training and accelerators
| Requirement | Review answer |
|---|---|
| Large neural network training | Consider GPU or TPU acceleration depending on framework and workload fit. |
| Training data too large for one worker | Use distributed training or data-parallel approaches. |
| CPU-bound preprocessing | Optimize input pipeline; accelerators do not fix slow data loading. |
| Low GPU utilization | Check batch size, input pipeline, data transfer, and model size. |
| Cost concern | Use managed jobs, right-sized machines, early stopping, preemptible/spot-style strategies where appropriate, and avoid idle accelerators. |
Evaluation and validation
A PMLE-ready evaluation plan includes more than a single score.
| Evaluation layer | What to check |
|---|---|
| Holdout test performance | Final unbiased estimate after tuning. |
| Cross-validation | Useful when data is limited or variance is high. |
| Slice performance | Performance across regions, devices, languages, demographic groups, product categories, or customer segments. |
| Calibration | Whether predicted probabilities match observed frequencies. |
| Fairness | Whether errors or outcomes are disproportionately harmful across groups. |
| Robustness | Sensitivity to noise, missing values, outliers, prompt variation, or distribution shift. |
| Explainability | Feature attribution, example-based explanations, model cards, stakeholder interpretability. |
| Latency and throughput | Whether model quality is achievable under serving constraints. |
| Cost | Training cost, prediction cost, storage, orchestration, and monitoring overhead. |
Notes and examples
Offline versus online evaluation
| Method | Purpose | Trap |
|---|---|---|
| Offline validation | Compare models before deployment. | May not predict user behavior or business impact. |
| Shadow deployment | Send production traffic to new model without affecting users. | Does not prove user response changes because outputs are not acted on. |
| Canary deployment | Serve small traffic percentage to new model. | Needs rollback and monitoring. |
| A/B test | Measure causal business impact. | Requires careful experiment design, sample size, and guardrail metrics. |
| Blue/green deployment | Switch between full environments. | Useful for rollback but not always enough for model behavior validation. |
MLOps, reproducibility, and pipelines
MLOps questions reward operational discipline.
| MLOps need | What good looks like |
|---|---|
| Reproducible training | Version data, code, dependencies, parameters, containers, and model artifacts. |
| Automated workflow | Use pipelines for data validation, training, evaluation, approval, deployment, and monitoring. |
| Model governance | Register models, track lineage, document metrics, require approvals where needed. |
| Safe deployment | Promote models through environments, use CI/CD, validate before serving traffic. |
| Rollback | Keep previous model versions and serving configs available. |
| Auditability | Log who changed data, code, parameters, model versions, and deployments. |
| Continuous training | Trigger retraining based on schedule, new data, drift, or performance degradation. |
| Experiment tracking | Compare runs consistently using parameters, metrics, artifacts, and dataset versions. |
Notes and examples
Pipeline anti-patterns
Avoid answers that:
- Manually run notebooks for production training.
- Deploy models without validation gates.
- Overwrite model artifacts without versioning.
- Use broad owner permissions for pipeline service accounts.
- Store secrets in source code or container images.
- Retrain automatically without checking model quality before deployment.
- Ignore rollback when changing models used by production systems.
Monitoring and production reliability
Production ML monitoring includes software reliability and model behavior.
| Monitor | Why it matters |
|---|---|
| Request count | Detect traffic spikes or drops. |
| Latency percentiles | p95/p99 latency often matters more than average latency. |
| Error rate | Detect serving failures, dependency failures, or malformed requests. |
| Resource utilization | Identify CPU, memory, GPU, or autoscaling issues. |
| Input schema | Catch missing fields, type changes, and invalid ranges. |
| Feature distribution | Detect skew or data drift. |
| Prediction distribution | Detect sudden output changes. |
| Ground-truth performance | Validate actual accuracy when labels become available. |
| Business KPIs | Confirm model improvements translate into business value. |
| Fairness slices | Detect degradation for specific subgroups. |
Notes and examples
Drift versus skew versus concept drift
| Term | Meaning | Example | Response |
|---|---|---|---|
| Training-serving skew | Training and serving data or transformations differ. | Feature computed in batch training but not available online. | Fix pipeline consistency and shared transformations. |
| Data drift | Input distribution changes over time. | Users from a new region create different feature values. | Monitor distributions, retrain or adapt features. |
| Concept drift | Relationship between features and label changes. | Fraud patterns change after attackers adapt. | Retrain with recent labels, update strategy, monitor performance. |
Retraining triggers
Retrain when:
- Ground-truth performance falls below an accepted threshold.
- Data drift is significant and affects model quality.
- New labeled data materially improves coverage.
- Product behavior or business rules change.
- A fairness, safety, or compliance issue appears.
- A better model passes validation and operational checks.
Do not retrain blindly if the root cause is a broken upstream pipeline, serving bug, label delay, or schema change.
Security, privacy, and access control
PMLE candidates should connect ML architecture to Google Cloud security fundamentals.
| Area | Review focus |
|---|---|
| IAM | Grant least privilege to users, service accounts, pipelines, and serving systems. |
| Service accounts | Use workload-specific identities instead of broad shared accounts. |
| Secrets | Store in Secret Manager; do not hard-code in notebooks, images, or repositories. |
| Encryption | Use Google Cloud encryption defaults and customer-managed keys where requirements specify. |
| Network controls | Use private connectivity and service perimeters when sensitive data boundaries matter. |
| Data minimization | Use only necessary fields; remove or mask sensitive attributes when not needed. |
| PII handling | Detect, classify, de-identify, tokenize, or redact sensitive data where appropriate. |
| Audit logging | Track access to data, artifacts, pipelines, and deployments. |
| Artifact security | Store images and packages in managed registries with scanning and access control. |
| Separation of duties | Keep development, approval, and production deployment roles distinct when governance requires it. |
Notes and examples
Security traps
- Giving a training pipeline broad project owner permissions.
- Exporting sensitive training data to unmanaged locations.
- Putting API keys in notebooks or container images.
- Allowing production models to read more data than required.
- Ignoring audit requirements for model artifacts and data lineage.
- Using public endpoints when private access is required by the scenario.
Quick symptom-to-fix table
| Symptom in question | Likely cause | Strong answer direction |
|---|---|---|
| Validation score high, production score poor | Leakage, skew, or drift | Compare training and serving data; monitor features; fix pipeline. |
| Model misses rare positive cases | Imbalanced data or wrong threshold | Optimize recall/PR AUC; resampling, class weights, threshold tuning. |
| Too many false alerts | Precision problem | Adjust threshold, improve features, use cost-sensitive evaluation. |
| Users complain about slow predictions | Serving latency | Optimize model, use accelerators, autoscaling, caching, or batch prediction. |
| Training job slow with idle GPU | Input bottleneck | Improve data loading, preprocessing, batching, and storage throughput. |
| Model quality differs by region/language | Slice performance issue | Evaluate by subgroup; improve data coverage and monitoring. |
| Pipeline sometimes deploys bad models | Missing validation gate | Add automated evaluation and approval criteria. |
| Model degrades after product change | Concept or data drift | Monitor, retrain, update features, validate new behavior. |
| Sensitive data appears in logs | Privacy control failure | Redact, minimize logging, protect access, review retention. |
| Generated answers are plausible but wrong | Hallucination or weak grounding | Use RAG, citations, evaluation, safety checks, human review. |
Final review checklist
Before moving to PMLE question-bank practice, make sure you can answer these quickly:
- Can you map a business goal to the right ML task and metric?
- Can you explain why accuracy may be the wrong metric?
- Can you choose between AutoML, BigQuery ML, custom Vertex AI training, pretrained APIs, and foundation models?
- Can you identify feature leakage and training-serving skew?
- Can you choose the correct split strategy for time series, users, groups, or imbalanced classes?
- Can you design a reproducible training pipeline with versioned artifacts?
- Can you select online, batch, or streaming prediction based on latency and volume?
- Can you describe safe rollout, rollback, monitoring, and retraining?
- Can you apply IAM least privilege to ML pipelines and model serving?
- Can you address privacy, explainability, fairness, and responsible AI requirements?
- Can you evaluate generative AI systems for groundedness, safety, relevance, cost, and latency?
Practice plan after this Cheat Sheet
Use IT Mastery practice to convert this review into exam readiness:
- Start with topic drills on weak areas: metrics, data leakage, Vertex AI services, deployment, monitoring, security, and responsible AI.
- Review every missed question with detailed explanations, especially why the wrong answers are tempting.
- Move to mixed original practice questions once individual topics feel stable.
- Use full mock exams to practice scenario triage, time management, and eliminating overbuilt solutions.
- Revisit this Cheat Sheet after each mock exam and update your personal trap list.
Next step: begin targeted PMLE question bank practice with original practice questions, then use detailed explanations to close gaps before attempting full-length mock exams.