GCP-PMLE Exam Notes

Must-Know Facts

• Data parallelism replicates the FULL model on every worker and splits the data — use it when the model fits on one device but training is slow. Model parallelism splits the MODEL itself across devices — use it only when the model does not fit in a single device's memory
• TPUs are optimized for large-scale TensorFlow and JAX workloads with massive batch sizes. GPUs are the general-purpose choice and are required for PyTorch or custom CUDA operations
• Vertex AI Vizier performs hyperparameter tuning using BAYESIAN OPTIMIZATION by default — it is more sample-efficient than grid search (exhaustive, expensive) or random search (faster than grid but less efficient than Bayesian)
• Transfer learning means starting from a PRE-TRAINED model and fine-tuning on your smaller domain-specific dataset. It is not training from scratch, and it reduces both data and compute requirements
• A large gap between training accuracy and validation accuracy (e.g., 98% vs 72%) is the classic signature of OVERFITTING = high variance. Fix with regularization (L1/L2), dropout, more data, or a simpler model — never with more epochs or more layers
• Low accuracy on BOTH training and validation sets is UNDERFITTING = high bias. Fix by increasing model complexity, adding features, or training longer — the opposite remedy from overfitting
• Framework selection: TensorFlow for production pipelines with the TFX ecosystem, PyTorch for research flexibility and dynamic graphs, scikit-learn for classical ML on small tabular data, XGBoost/boosted trees for structured tabular problems
• Model explainability methods differ by data type: Shapley values work generically across tabular/structured data, XRAI is optimized for image region-based attribution, integrated gradients work well for differentiable models including images and text
• Vertex AI Experiments tracks metrics, parameters, and artifacts ACROSS TRAINING RUNS for comparison — it is a research/prototyping tool, not a production traffic-splitting mechanism
• Evaluation metric selection must match the business framing: precision/recall/F1/AUC-ROC for classification, RMSE/MAE/R-squared for regression — a question stating 'costly false negatives' always points to maximizing recall

Common Traps

Confusing Pairs

Scenario Tips

Last-Minute Facts

Must-Know Facts

• Online prediction via Vertex AI Endpoints is for real-time, low-latency, user-facing inference (fraud scoring, chatbots, recommendations at request time) and supports autoscaling and traffic splitting
• Batch prediction has NO persistent endpoint — it spins up compute, processes a large dataset, writes results, and shuts down, making it the cost-effective choice whenever latency is not a constraint
• Autoscaling on Vertex AI Endpoints is REACTIVE, not predictive. It reacts to observed load after the fact and cannot instantly absorb a sudden spike. For known future spikes (product launch, sale), pre-scale by raising the minimum replica count ahead of time
• Traffic splitting on Vertex AI Endpoints routes a configurable percentage of production requests to each deployed model version, enabling canary releases and gradual rollouts — this is DIFFERENT from Vertex AI Experiments, which only tracks training runs
• Model optimization for serving has three distinct techniques: quantization (reduces numeric precision to shrink size/latency, may reduce accuracy), pruning (removes unnecessary weights/connections), and distillation (trains a smaller 'student' model to mimic a larger 'teacher')
• Serving infrastructure choices: Vertex AI Endpoints is the managed, exam-preferred option for ML-specific serving; Cloud Run is valid for containerized custom serving logic; GKE is used when you need full Kubernetes control — Vertex AI Endpoints wins by default on this exam unless the scenario explicitly requires custom infrastructure
• Cost optimization for batch workloads includes preemptible/Spot VMs (since jobs are not latency-sensitive and can tolerate interruption) and right-sizing machine types instead of always choosing the largest instance
• Model Registry manages VERSIONING and governance metadata for models — the underlying model binary artifact can live in Cloud Storage. Registry is a governance layer, not a storage location itself

Common Traps

Confusing Pairs

Scenario Tips

Last-Minute Facts

Must-Know Facts

• Vertex AI Pipelines (built on Kubeflow Pipelines) is the near-universal correct orchestrator for ML workflows on this exam — component definition, parameter passing, and DAG structure are all built on the Kubeflow Pipelines SDK
• Pipeline components must be DECOUPLED, independently testable, and containerized. A scenario describing tightly-coupled steps (e.g., preprocessing directly calling the training function) signals that the fix is refactoring into separate containerized components with defined interfaces
• CI/CD for ML extends beyond code testing — it includes DATA VALIDATION, model evaluation against a threshold, and staged/gated deployment as pipeline stages, not just unit tests
• Cloud Build handles the CI/CD build-test-deploy mechanics; Vertex AI Pipelines handles the ML-specific workflow orchestration. These two services are typically paired, not substituted for one another
• Automated retraining triggers can be schedule-based (fixed cron), data-driven (new data arrival), or monitoring-driven (drift/performance threshold exceeded). When a question specifies drift-based triggering, a fixed schedule is the wrong answer even if it 'sounds automated'
• Vertex AI Model Monitoring can detect drift and publish an event (e.g., via Pub/Sub) that triggers a Vertex AI Pipeline run for retraining — this is the standard drift-triggered retraining architecture
• Artifact management (training data, model binaries, evaluation metrics, pipeline outputs) is handled through Artifact Registry (containers/packages) and Cloud Storage (data/model files), with metadata and lineage tracked via Vertex AI Metadata
• A/B testing and canary deployment in production is a traffic-splitting concern on Endpoints (Domain 4), while champion/challenger evaluation logic can be embedded as an automated pipeline stage that gates promotion of a new model

Common Traps

Confusing Pairs

Scenario Tips

Last-Minute Facts

Must-Know Facts

• Vertex AI Feature Store is the fix whenever a scenario describes MULTIPLE TEAMS independently re-engineering the same features, or inconsistent feature values between training and serving (training-serving skew) — it provides a single centralized source with both online (low-latency) and offline (point-in-time, batch) serving
• Training-serving skew specifically means the features computed at training time differ from the features computed at serving/prediction time — Feature Store solves this by using the SAME feature computation and storage layer for both paths
• Vertex AI Workbench provides managed Jupyter notebooks for prototyping; MANAGED notebooks auto-idle/shut down for cost efficiency, while USER-MANAGED notebooks give more configuration control but require manual lifecycle management
• Vertex AI Experiments tracks metrics, parameters, and artifacts to COMPARE model architectures and hyperparameter runs — it is a development-time tool, not a production monitoring or A/B testing tool
• Model Registry provides governance: versioning, access control via IAM, lineage, and metadata for models across their lifecycle — distinct from Feature Store (which manages features, not models)
• Data quality practices include schema validation, anomaly detection in incoming data pipelines, and handling drift — these belong to the collaboration/governance domain because they are typically shared responsibilities across data engineering and ML engineering teams
• BigQuery is the primary tool for SQL-based large-scale data exploration; Vertex AI Workbench notebooks are used for interactive, code-based (Python) exploration and prototyping — teams often use both depending on the task and audience

Common Traps

Confusing Pairs

Scenario Tips

Last-Minute Facts

Must-Know Facts

• BigQuery ML supports specific model types only: linear regression, logistic regression (binary/multiclass), K-means clustering, matrix factorization (recommendations), boosted trees (XGBoost), DNN, ARIMA (univariate time series), and autoencoders. It does NOT support image/video classification or arbitrary custom neural architectures
• The decisive signal for BigQuery ML: data is ALREADY in BigQuery and the team's primary skill is SQL. The decisive signal for AutoML: labeled data exists but ML expertise is limited and time-to-production matters. The decisive signal for pre-built APIs: NO labeled training data exists and the use case matches a standard capability (vision, language, translation, speech) exactly
• Pre-built ML APIs require ZERO training data — they are ready-to-use out of the box. AutoML requires YOUR OWN labeled data to train a custom model. This single distinction ('no labeled data available' vs. 'we have labeled data') is the most common exam trap in this domain
• Model Garden provides access to foundation models (Gemini, PaLM, and open-source models) for fine-tuning or direct deployment — the correct answer whenever a scenario needs a general-purpose or generative capability without training from scratch
• RAG (Retrieval-Augmented Generation) via Vertex AI Agent Builder grounds a foundation model's responses in enterprise documents at QUERY TIME, without retraining the model — this is different from fine-tuning, which bakes new knowledge into model weights and is more expensive and slower to update
• Matrix factorization in BigQuery ML is specifically for RECOMMENDATION systems, not general dimensionality reduction — do not confuse it with PCA-style use cases

Common Traps

Confusing Pairs

Scenario Tips

Last-Minute Facts

Must-Know Facts

• Data drift = the INPUT feature distribution changes over time while the input-output relationship stays the same. Concept drift = the RELATIONSHIP between inputs and the target changes, even if input distributions look unchanged. Prediction drift = the model's OUTPUT distribution changes, which is a symptom that can result from either data or concept drift
• A falling accuracy with an UNCHANGED input distribution is the textbook signature of concept drift, not data drift — the exam tests this distinction directly
• Vertex AI Model Monitoring detects WHEN retraining may be needed (via drift/skew signals) but does NOT retrain automatically on its own — automatic retraining requires connecting monitoring alerts to a pipeline trigger (e.g., via Pub/Sub)
• Feature attribution (Shapley values, XRAI, integrated gradients) explains WHY a model made a specific prediction — it is about explainability/interpretability, not about measuring accuracy or drift, and should not be conflated with either
• Responsible AI on this exam spans more than bias detection: fairness (demographic parity, equalized odds), transparency, accountability, privacy, and safety are all in scope, and a fairness problem (e.g., disparate rejection rates for a demographic group) is fixed by assessing fairness metrics and applying bias mitigation in the training pipeline — not simply by removing the demographic attribute, which leaves proxy variables intact
• Continuous evaluation compares live predictions against ground-truth labels AS THEY BECOME AVAILABLE to track real-world accuracy over time, complementing drift detection which does not require ground truth

Common Traps

Confusing Pairs

Scenario Tips

Last-Minute Facts