Google Cloud Professional Machine Learning Engineer · 18% practice allocation

Google Cloud Professional Machine Learning Engineer: Scaling prototypes into ML models Practice Questions

5 free sample questions from the Scaling prototypes into ML models domain, with answers and explanations. The full Professional Machine Learning Engineer bank has 251 questions across 6 domains. Questions are scenario-based and written from the official Google Cloud exam guide.

Your team is training a scikit-learn Random Forest model on Vertex AI using the Python package approach (not a container). After 2 hours, the job completes but the model performance is significantly worse than expected. You notice the training data has 500,000 rows and 200 features. What is the most likely issue?

A. Scikit-learn's Random Forest is loading the entire dataset into memory, exceeding available RAM
B. The random_state parameter was not fixed, causing non-deterministic results
C. The max_depth parameter was set too high, causing the model to overfit the training data
D. The n_jobs parameter was not set to utilize all available CPU cores during training✓ Correct

Explanation

Option 0 is correct. If n_jobs is not explicitly set to -1 or a positive value, scikit-learn defaults to n_jobs=1, using only a single core. With 500K rows and 200 features, parallelization is critical for performance. Option 1 is less likely because scikit-learn processes data efficiently and Vertex AI workers have sufficient RAM. Option 2 is wrong because non-determinism causes inconsistent results but not systematically worse performance. Option 3 is speculative without knowing the actual max_depth setting or whether overfitting is the issue; the question suggests a training speed/efficiency problem rather than model quality.

You are training a deep neural network on Vertex AI using a custom training container with mixed precision (float16 computations, float32 gradients). During training, you observe that the loss becomes NaN after the first epoch. What is the most likely cause?

A. Mixed precision is unsupported on the Vertex AI compute node type you selected
B. The learning rate is incompatible with mixed precision
C. Loss scaling is not properly configured, causing gradient underflow in float16✓ Correct
D. The batch size is too small for float16 arithmetic

Explanation

NaN loss in mixed precision typically indicates gradient underflow due to insufficient loss scaling. When gradients are too small in float16, they round to zero, breaking the training signal. Proper loss scaling (e.g., 1024x) prevents this. Batch size affects convergence, not float16 arithmetic directly. Learning rate itself doesn't cause underflow. Vertex AI supports mixed precision on modern hardware.

Your team is configuring a Vertex AI custom training job for an XGBoost model on a 150 GB tabular dataset. The job times out after 8 hours despite running on a multi-core CPU machine with 128 GB RAM. What are the most likely issues contributing to slow training? (Select TWO.)

A. XGBoost is I/O-bound due to repeated reads from Cloud Storage; cache the dataset locally on the training machine✓ Correct
B. The feature engineering pipeline is inefficient; optimize data preprocessing before training starts✓ Correct
C. XGBoost requires GPU acceleration; CPU-only training is inherently slow for large datasets
D. The tree depth or max_leaves parameter is set too high, increasing training complexity
E. The training machine's memory is insufficient for the dataset; increase machine type to 256 GB RAM
F. The number of boosting rounds is too high; reduce from 1000 to 100 rounds

Explanation

I/O bottlenecks and inefficient preprocessing are the most common causes of slowness. Caching data locally and optimizing preprocessing save significant time. While GPU can help, CPU training on 150 GB is feasible and not inherently slow. Reducing boosting rounds arbitrarily hurts model quality. Tree depth affects speed but is typically not the primary bottleneck. 150 GB exceeds 128 GB RAM, but modern XGBoost handles out-of-core data; memory upgrade alone won't fix I/O or preprocessing inefficiency.

You are designing a distributed training strategy for a large PyTorch model on Vertex AI. You need to choose between tf.distribute.MultiWorkerMirroredStrategy (synchronous all-reduce) and ParameterServerStrategy (asynchronous). Your dataset is 1 TB, model is 5 GB, and you have 16 workers with variable network conditions. Select TWO strategies that would be most appropriate.

A. Use ParameterServerStrategy to tolerate stragglers and variable network latency through asynchronous gradient updates✓ Correct
B. Use MultiWorkerMirroredStrategy for guaranteed convergence and synchronized updates across all workers despite variable network conditions
C. Use ParameterServerStrategy because it automatically handles fault tolerance without restarting the job
D. Use MultiWorkerMirroredStrategy because PyTorch's DistributedDataParallel is synchronous and expects synchronized gradients
E. Implement a hybrid approach using gradient compression with MultiWorkerMirroredStrategy to reduce network overhead✓ Correct

Explanation

Options 1 and 4 are correct. ParameterServerStrategy (option 1) is ideal for variable network conditions because asynchronous updates tolerate stragglers. Gradient compression (option 4) reduces bandwidth overhead in synchronized training. Option 0 is wrong because MultiWorkerMirroredStrategy's synchronization becomes a bottleneck with variable network conditions (workers wait for slowest). Option 2 is misleading phrasing; while DistributedDataParallel is synchronous, ParameterServerStrategy is still valid for large-scale PyTorch. Option 3 is incorrect; ParameterServerStrategy doesn't provide automatic fault tolerance—job failures require restart.

You are implementing a custom training job on Vertex AI for a PyTorch model using a container image. The training script needs to save model checkpoints every 50 steps to Google Cloud Storage. Which approach is best for ensuring checkpoints are reliably saved during distributed training?

A. Use local disk checkpointing only; transfer to GCS after training completes
B. Only the chief worker saves checkpoints to GCS, while other workers continue training without saving state✓ Correct
C. Each worker saves its own checkpoints to a unique GCS path; the chief worker downloads and merges them after training
D. All workers write checkpoints to the same GCS path simultaneously; GCS handles versioning

Explanation

In distributed training, only the chief worker should write checkpoints to avoid race conditions and redundant writes to GCS. Other workers focus on training; their state is replicated by the parameter server or collective communication. Simultaneous writes to the same path cause conflicts. Waiting until training finishes risks losing progress if the job fails.

Test yourself across every Professional Machine Learning Engineer domain

The free Professional Machine Learning Engineer practice test mixes about 20 questions weighted like the exam. The full 251-question bank adds instant grading, flashcards and a timed mock exam.

Take the free Professional Machine Learning Engineer practice test Practice the full bank

Study this domain

Scaling prototypes into ML models study guide (Professional Machine Learning Engineer) →

Other Professional Machine Learning Engineer domains

← All Google Cloud Professional Machine Learning Engineer study resources