Free Google Cloud Professional ML Engineer Practice Questions: Serving and Scaling Models

Topic snapshot

Sample questions

These are original IT Mastery practice questions aligned to this topic area. They are not official Google Cloud questions, copied live-exam content, or exam dumps. Use them to preview question style and explanation depth before continuing with topic drills, mixed sets, and timed mocks in IT Mastery.

Question 1

Topic: Serving and Scaling Models

A retailer is adding a production feature that generates concise product descriptions from product images and existing catalog text. A foundation model available in Model Garden already supports the required multimodal generation, and the team wants online responses with minimal serving infrastructure to manage. Which serving setup should the team use?

Options:

• A. Deploy an open-source model on GKE GPU nodes

• B. Train a custom multimodal model on Agent Platform custom training

• C. Serve the Model Garden model as a managed service

• D. Wrap a local image model in Cloud Run

Best answer: C

Explanation: When the required capability is already provided by a foundation or managed model in Model Garden, the preferred serving choice is to use that managed model capability rather than build and operate a custom serving stack. In this scenario, the decisive facts are the existing Model Garden multimodal model, the need for online responses, and the desire to minimize infrastructure management. Managed model serving lets the team consume the model through a production-ready service interface without owning weights, building containers, or managing GPU clusters. Custom training or self-hosting would add operational complexity without addressing a missing capability.

• Custom training is unnecessary because the stem says an existing foundation model already supports the required generation task.
• GKE GPUs could serve self-managed models, but it shifts scaling and operations to the team.
• Cloud Run wrapper is the wrong layer when the needed capability is a managed foundation model rather than a local model service.

Question 2

Topic: Serving and Scaling Models

A team deployed registered model version recommender-v3 as a 10% canary on an Agent Platform Inference endpoint. The rollout requirement is p95 latency under 200 ms, 5xx rate under 1%, and no business metric regression before promotion.

What should the ML engineer do next?

Options:

• A. Keep v3 and relax the latency alert threshold

• B. Increase v3 traffic to collect more evidence

• C. Stop the canary and route traffic back to v2

• D. Promote v3 because offline AUC improved

Best answer: C

Explanation: Rollout decisions should use production evidence, not only offline model quality. Although v3 has a higher offline AUC, it fails the stated canary gates: p95 latency is above 200 ms, 5xx errors are above 1%, and the add-to-cart rate regressed. The safest promotion action is to stop the canary, send traffic back to the last known good registered version, and then diagnose v3 serving behavior before retrying the rollout.

A better offline metric can justify another iteration, but it does not override failed reliability or business gates during deployment.

• Offline-only promotion fails because improved AUC does not satisfy the canary’s production reliability and business requirements.
• More traffic is risky because the canary already shows clear SLO violations and a business regression.
• Relaxing alerts hides the symptom instead of addressing the failing rollout criteria.

Question 3

Topic: Serving and Scaling Models

A retail prediction service replaced its production model with a new version on an Agent Platform Inference endpoint. Within 20 minutes, conversion-rate predictions drifted from the baseline, and rollback required redeploying the old model. The release requirement was to compare versions in production, expose only a small share of traffic to the new version, and roll back quickly. What release correction should the ML engineer make next?

Options:

• A. Increase replicas for the new model deployment

• B. Use a canary traffic split with both model versions deployed

• C. Replace the model artifact in the registry after offline validation

• D. Move the new model to a separate public endpoint

Best answer: B

Explanation: A safe model-release pattern keeps the current production version available while introducing the new version to a controlled slice of traffic. On an Agent Platform Inference endpoint, deploying both versions and assigning a small traffic split supports canary-style release or A/B comparison. If the new model degrades metrics, rollback is a traffic-routing change rather than a redeployment. This directly addresses the observed failure: the team replaced the model outright, so all users were exposed and rollback was slow. Scaling replicas may help capacity, but it does not provide release safety.

• Registry replacement still risks overwriting or fully replacing the serving version and does not provide limited live exposure.
• Separate endpoint can isolate the model but does not automatically compare production traffic or support endpoint-level rollback.
• More replicas addresses throughput or latency, not the missing release-control pattern.

Question 4

Topic: Serving and Scaling Models

A fraud-scoring model runs on Agent Platform Inference for synchronous checkout decisions. The SLO is p95 <= 150 ms, but production p95 is 820 ms. Increasing endpoint replicas did not improve latency.

Model quality is acceptable. What should you do next to reduce response time?

Options:

• A. Use online feature serving or precomputed request features.

• B. Retrain a smaller model with fewer features.

• C. Increase the endpoint maximum replica count again.

• D. Move the model to GPU-backed serving nodes.

Best answer: A

Explanation: Latency tuning should focus on the stage that dominates the end-to-end critical path. The model container is taking only 45 ms, but the request-time BigQuery lookup takes 650 ms, so changing serving hardware or scaling replicas will not address the bottleneck. For synchronous inference, avoid analytical queries in the request path. Precompute needed features, include them in the request when appropriate, or use a low-latency online feature store such as Agent Platform Feature Store while keeping training and serving transformations consistent. The key takeaway is to optimize the slowest serving-path dependency before changing the model.

• More replicas helps throughput or queueing, but the evidence shows a per-request lookup bottleneck that scaling did not fix.
• GPU serving targets model computation latency, not the BigQuery feature lookup that dominates p95.
• Smaller model may reduce prediction time, but prediction is not the main contributor to the failed SLO.

Question 5

Topic: Serving and Scaling Models

A retailer uses an Agent Platform Inference online endpoint to score 42 million customer records from BigQuery every night for next-day personalization. The workflow sends highly parallel prediction requests and must finish before 6:00 AM, but no user waits for an individual response. During the run, the endpoint reports throttling and intermittent 5xx errors. What is the most likely cause of the failed nightly workflow?

Options:

• A. The model lacks an active registry version alias.

• B. BigQuery requires a private endpoint for predictions.

• C. Training-serving skew is causing the endpoint errors.

• D. Online inference is being used for scheduled bulk scoring.

Best answer: D

Explanation: Batch inference is designed for large prediction jobs that can run asynchronously, such as nightly scoring from BigQuery or Cloud Storage. An online endpoint is optimized for low-latency request-response traffic, not for a massive scheduled workload that floods the endpoint with parallel requests. The evidence points to a service-selection issue: high-volume nightly requests cause throttling and 5xx errors, while individual prediction latency is not a business requirement. Moving the nightly job to batch inference keeps bulk scoring separate from real-time serving capacity.

• Registry alias issue would usually prevent or misroute deployment, not only fail during a high-volume nightly scoring window.
• Training-serving skew affects prediction quality or feature consistency, not endpoint throttling caused by request volume.
• Private endpoint requirement is not implied by reading records from BigQuery for predictions.

Question 6

Topic: Serving and Scaling Models

An ML team is canarying a new image model version from Agent Platform Model Registry to an Agent Platform Inference endpoint. The canary receives 20% of traffic and must keep p95 latency under 250 ms. Production clients have valid IAM, and the same request succeeds during low traffic. Which cause best explains the failure?

Exhibit: Canary observations

Options:

• A. Container packaging defect

• B. Endpoint access misconfiguration

• C. Insufficient serving capacity

• D. Model Registry version not deployed

Best answer: C

Explanation: This is a resource scaling failure. The endpoint accepts requests, the model is deployed, health checks pass, and feature lookup latency is healthy. The decisive evidence is RESOURCE_EXHAUSTED, replicas already at the configured maximum, very high accelerator utilization, and errors disappearing when canary traffic is reduced. That pattern indicates the canary deployment does not have enough serving capacity for the assigned traffic share. A practical next step would be to adjust autoscaling limits, replica sizing, accelerator configuration, or canary percentage before increasing rollout traffic. Endpoint access, packaging, registry state, and feature serving problems would show different symptoms, such as authorization errors, container startup or handler failures, missing deployed model state, or feature lookup errors.

• Access issue does not fit because clients have valid IAM and the same requests succeed during low traffic.
• Packaging issue is unlikely because health checks pass and failures are load-dependent rather than constant.
• Registry state issue is unlikely because the canary is already receiving traffic from the deployed model version.

Question 7

Topic: Serving and Scaling Models

A bank is moving a real-time credit risk model to production on Google Cloud. The scoring application runs in a private VPC and must call the model without traversing the public internet or exposing a public prediction endpoint. Which serving setup best meets this requirement?

Options:

• A. Deploy the model to an Agent Platform Inference private endpoint.

• B. Run batch predictions and write results to Cloud Storage.

• C. Deploy the model to a public endpoint with IAM authentication.

• D. Expose the model through a public Cloud Run service.

Best answer: A

Explanation: Private endpoints are the serving choice when the primary requirement is network isolation or private application access. For an online model called by an internal application in a private VPC, the endpoint should be reachable privately rather than through a public prediction URL. IAM and HTTPS are still important, but they do not by themselves satisfy the requirement to avoid public internet paths. Batch prediction also changes the serving mode and does not support real-time scoring. The key takeaway is to match the endpoint network exposure to the application’s access pattern.

• Public endpoint with IAM protects access but still exposes a public prediction endpoint, which conflicts with the network isolation requirement.
• Batch prediction is for offline scoring workflows, not real-time application calls.
• Public Cloud Run front end adds another public service layer instead of keeping prediction access private.

Question 8

Topic: Serving and Scaling Models

A team promotes a churn model from staging to production on Agent Platform Inference. During canary rollout, recall is 8 percentage points lower than the offline evaluation reported for the candidate model. The release notes list only the endpoint name and container tag, but the team needs to verify which trained artifact, data snapshot, parameters, and evaluation metrics belong to the candidate versus the deployed production version. What is the most appropriate next diagnostic step?

Options:

• A. Replace the production feature data with the training snapshot.

• B. Rerun hyperparameter tuning for the candidate model.

• C. Review Model Registry metadata and ML Metadata lineage for both versions.

• D. Increase endpoint replicas and compare latency percentiles.

Best answer: C

Explanation: Agent Platform Model Registry is used to manage model versions and the metadata needed for promotion decisions, audits, and rollback analysis. In this scenario, the symptom is not primarily endpoint capacity or a known training failure; it is a mismatch between the evaluated candidate and the deployed production behavior. The next diagnostic step is to compare registry metadata and ML Metadata lineage for the candidate and deployed version, including artifact URI, training run, data snapshot, parameters, metrics, and approval status. That comparison can reveal whether the wrong artifact was promoted or whether the production version differs from the evaluated candidate. Scaling or retraining before confirming version identity can hide the real release issue.

• Replica scaling addresses latency or capacity symptoms, not a recall mismatch tied to version identity.
• Hyperparameter tuning may improve a future model, but it does not diagnose whether the evaluated artifact was deployed.
• Replacing feature data is risky and unsupported by the evidence; the first step is to compare version metadata and lineage.

Question 9

Topic: Serving and Scaling Models

A retail company has deployed a new Gemini-based recommendation endpoint on Agent Platform Inference using a canary rollout. The endpoint currently receives 5% of live traffic. Before increasing to 50%, the team must protect conversion rate, keep p95 latency under 300 ms, and avoid increases in safety-filter blocks or 5xx errors. Which readiness check is the BEST engineering decision?

Options:

• A. Confirm only Model Registry approval and container scan status

• B. Increase traffic first and wait for Model Monitoring alerts

• C. Compare canary and baseline live metrics against promotion thresholds

• D. Verify only offline evaluation results from the held-out test set

Best answer: C

Explanation: Before increasing traffic in a canary rollout, the readiness check should compare the new endpoint with the current baseline on the same production traffic slice. The visible constraints include business impact, latency, reliability, and responsible AI safety signals, so promotion should depend on predefined thresholds for conversion rate, p95 latency, 5xx errors, and safety-filter block rate. Offline tests, registry approval, and security scans are valuable release inputs, but they do not prove the live endpoint is ready for a larger traffic share. The key release-safety idea is to validate production behavior at low exposure before expanding blast radius.

• Offline-only evaluation misses production latency, error behavior, and live user impact during the canary.
• Registry and scan checks help governance and supply-chain safety, but they do not validate serving readiness.
• Alert-after-promotion increases blast radius before proving the new endpoint meets live promotion criteria.

Question 10

Topic: Serving and Scaling Models

A team deploys model version 2 from Agent Platform Model Registry to an Agent Platform Inference endpoint by replacing version 1. Within minutes, Model Monitoring shows higher p95 latency and errors for all users. The release requirement was to expose the new version to only a small portion of production traffic first, monitor health metrics, and expand only if the metrics stay acceptable. What should the team use for the next rollout?

Options:

• A. Canary deployment with gradual traffic increase

• B. Batch prediction before online deployment

• C. Shadow deployment with no user-facing traffic

• D. Blue-green deployment with an immediate cutover

Best answer: A

Explanation: A canary deployment is the rollout pattern that matches a gradual, risk-reducing release. The new model version receives a small percentage of real production traffic while the previous version continues serving most users. The team monitors serving metrics such as latency, error rate, and prediction quality before increasing the traffic split. If the new version regresses, the team can stop the rollout or route traffic back to the stable version with limited user impact. The symptom in the stem affected all users because the team replaced the existing version instead of progressively shifting traffic.

• Immediate cutover is faster, but it exposes all users to the new version at once and does not meet the staged rollout requirement.
• Shadow deployment helps observe behavior without affecting users, but it does not gradually expose real user-facing predictions.
• Batch prediction can validate offline inference, but it does not control traffic for an online endpoint rollout.

Continue in the web app

Use IT Mastery for interactive Google Cloud Professional ML Engineer practice with mixed sets, timed mocks, topic drills, explanations, and progress tracking.

Try Google Cloud Professional ML Engineer on Web

Related focused pages

• Free Google Cloud Professional ML Engineer Full-Length Practice Exam
• Low-Code AI Architecture
• Data and Model Collaboration
• Scaling ML Models
• ML Pipeline Automation
• Monitoring AI Solutions