Professional Machine Learning Engineer · 20% of the exam

Serving and scaling models: free practice questions

5 sample questions from our 50-question bank for this domain — answers and explanations included. These are the same scenario-based style as the real Google Cloud exam.

1. You have a batch prediction job that must process 2 TB of customer records every night within a 4-hour window. The current setup uses Vertex AI Batch Prediction with 10 concurrent worker machines, completing in 6 hours. You want to meet the SLA. Which approach is most appropriate?

  • A. Increase worker concurrency to 15 machines and use SSD-backed persistent disks
  • B. Switch to online prediction with a request queue and process records through an endpoint over 8 hours
  • C. Keep batch prediction but optimize the model through quantization and increase worker count to 20, targeting sub-4-hour completion✓ Correct
  • D. Migrate to BigQuery ML and run predictions directly in SQL, which is always faster than Batch Prediction API
Explanation

Batch prediction is the correct paradigm for offline, high-volume processing. Doubling from 10 to 20 workers should proportionally reduce runtime. Model quantization reduces inference time per record. Option 1 underestimates the scaling needed. Option 2 is unsuitable because online prediction is for real-time queries, not time-windowed batch jobs. Option 4 is a misconception—BigQuery ML is useful for some workflows but not universally faster, and still uses similar underlying compute.

2. Your team deployed a demand forecasting model on Vertex AI that predicts inventory needs for a retail company. The endpoint currently uses a single n1-standard-4 machine type and serves 50 requests per second during business hours. You configure autoscaling with target CPU utilization of 80%. During a promotional event, traffic unexpectedly surges to 200 requests per second. The endpoint scales to 5 replicas but still experiences a request queue and 95% CPU utilization. The model itself is not compute-bound; profiling shows 40% of inference time is spent on data preprocessing. What is the root cause and the best remediation?

  • A. The autoscaling policy is too conservative; increase the target CPU utilization threshold to 90% to trigger earlier scaling
  • B. The machine type is too small; switch to a larger machine (e.g., n1-standard-8) that can handle more concurrent preprocessing
  • C. Data preprocessing is the bottleneck and is not utilizing GPU acceleration; move preprocessing logic to a preprocessing layer or use Vertex AI Feature Store to pre-compute features✓ Correct
  • D. The endpoint did not scale fast enough due to autoscaling lag; configure a higher replica reserve or use predictive autoscaling
Explanation

The correct answer is (2). The profiling data directly shows that 40% of inference time is spent on preprocessing, which is likely CPU-bound and not parallelized or optimized. Moving this logic to Feature Store (which pre-computes and caches features) or a dedicated preprocessing service offloads this bottleneck from the inference endpoint. This is more efficient than simply adding more CPU or replicas, which would still waste cycles on the same inefficient preprocessing. (0) is incorrect—raising CPU utilization to 90% doesn't address the root cause and would worsen responsiveness. (1) A larger machine might help temporarily, but it's wasteful when the bottleneck is algorithmic (preprocessing logic), not hardware capacity. (3) Autoscaling lag is less likely the issue given that the endpoint scaled to 5 replicas; the problem is that those replicas are all CPU-bound by preprocessing, so more replicas won't fix it without addressing the root cause.

3. Your company runs an A/B test comparing Model A (current, logistic regression baseline) with Model B (new gradient boosted trees model) on a Vertex AI endpoint using 50/50 traffic split. After 3 days, Model B shows 8% higher revenue per prediction, but the result is only significant at p<0.10 (not p<0.05). Your stakeholders want to roll out Model B immediately because the business upside is promising. What should you recommend?

  • A. Roll out Model B immediately; the p<0.10 result is directionally positive and the 8% uplift justifies the risk
  • B. Continue the test for at least 7-10 more days to reach p<0.05 statistical significance; the risk of a false positive is higher than waiting, especially for decisions with long-lasting business impact✓ Correct
  • C. Run a post-hoc power analysis to estimate sample size for p<0.05; if feasible, extend the test; if not, roll out with caution and monitor post-launch metrics closely
  • D. Switch to Bayesian analysis with a strong prior belief in Model B's superiority; this allows decision-making at lower frequentist p-values
Explanation

Option 1 (correct): Premature rollout of a model with p<0.10 risks deploying an inferior model if this is a false positive. For model selection with business impact, waiting for p<0.05 is the gold standard in ML. The additional 7-10 days of testing is a modest cost compared to weeks/months of poor production performance. Option 0 prioritizes speed over rigor incorrectly. Option 2 is more nuanced and reasonable, but the best practice is to reach p<0.05 before rollout. Option 3 is reasonable in Bayesian contexts, but frequentist p<0.05 remains the standard in industry A/B testing.

4. Your team is choosing between online and batch prediction for a customer churn model in a SaaS platform. The model must provide churn scores for 50,000 customers daily, with results used for outbound marketing campaigns the next day. Current online serving infrastructure serves 500 requests/second with 99.9% availability. Which statement BEST justifies using batch prediction instead of online serving for this use case?

  • A. Batch prediction eliminates the need to maintain high-availability serving infrastructure, reducing operational complexity and cost✓ Correct
  • B. Batch prediction allows the use of more complex ensemble models that are infeasible to run in online serving
  • C. Online serving would require 50,000 API calls daily, which is unsustainable and would degrade overall endpoint performance
  • D. Batch prediction results can be pre-joined with customer data and stored in BigQuery for direct use in marketing workflows✓ Correct
Explanation

Options 0 and 3 are correct. Option 0: Batch prediction doesn't require maintaining 24/7 availability; Vertex AI Batch Predict is cost-optimized for large-scale offline processing. Option 3: Integration with BigQuery enables seamless data workflows for downstream marketing systems. Option 1 is false—complexity depends on the model, not the serving method. Option 2 is misleading: 50,000 requests/day (0.58 req/sec) is easily sustainable on the existing 500 req/sec infrastructure; the concern isn't technical feasibility but economic efficiency.

5. A team is evaluating whether to serve a newly trained BERT-based text classification model using Vertex AI managed endpoints or a self-managed GKE deployment. Which THREE factors favor choosing Vertex AI managed endpoints over GKE for this use case? (Select THREE)

  • A. Built-in integration with Vertex AI Model Monitoring for input feature skew and prediction drift detection.✓ Correct
  • B. Ability to use custom Kubernetes operators and pod autoscalers with fine-grained control over node affinity.
  • C. Managed autoscaling that integrates directly with Vertex AI model registry and deployment pipelines.✓ Correct
  • D. Native support for traffic splitting between multiple model versions without additional load balancer configuration.✓ Correct
  • E. Ability to run sidecar containers alongside the model server for custom pre/post-processing logic.
  • F. Elimination of infrastructure management overhead such as node upgrades, cluster security patching, and networking configuration.✓ Correct
Explanation

Wait—this is a 'Select THREE' question. The three best answers are A, C, D, and F represent four strong reasons, so let me clarify the top three: Options A, D, and F are the most distinctly 'Vertex AI advantage' factors. Option A is correct because Vertex AI Model Monitoring is a fully managed service that integrates natively with Vertex AI endpoints to detect skew and drift—this requires significant custom work on GKE. Option D is correct because Vertex AI endpoints provide first-class traffic splitting across deployed model versions through a simple API, whereas GKE requires configuring custom ingress controllers or service meshes. Option F is correct because Vertex AI managed endpoints abstract away all cluster management, node upgrades, and security patching—GKE, even with Autopilot, still requires more operational involvement. Option B is wrong because custom Kubernetes operators and fine-grained node affinity are GKE advantages, not Vertex AI advantages—this favors GKE. Option C is also a valid Vertex AI advantage (managed autoscaling with model registry integration), making this question's three correct answers A, D, and F for the clearest differentiation. Option E is wrong because sidecar containers are a Kubernetes/GKE pattern and are not natively supported in Vertex AI managed endpoint containers.

45 more questions in this domain

Practice the full bank with instant grading, flashcards, and a timed mock exam.

Start practicing free
Serving and scaling models — Free Professional Machine Learning Engineer Practice Questions | DataCertPrep — Certification Prep