GCP Professional ML Engineer Practice Question 16: Custom Container Unsupported Framework
Google Cloud Professional Machine Learning Engineer · Test 2 · question 6 of 10
A risk model is implemented in a niche gradient-boosting library that Agent Platform does not ship a prebuilt inference container for, and each request needs a short postprocessing step that converts the raw score into the bands the caller expects. The team wants the model served from a managed Agent Platform endpoint rather than infrastructure they operate themselves.
How should the model be deployed?
Show answer and explanation
Answer:
A custom container is the documented answer for both of these needs: serving inferences from a model trained with a framework that is not available as a prebuilt container, and preprocessing requests or postprocessing the inferences the model generates. You build an image that meets the custom container requirements, push it to Artifact Registry, and point the Model resource at it; Agent Platform then runs that container on each inference node behind a normal endpoint, so the team keeps managed serving (option B).
- A is wrong because it assumes the niche library converts cleanly to ONNX and that the XGBoost prebuilt container will load it, and it pushes the band conversion into every caller instead of keeping it with the model. - C is wrong because Model Registry holds model versions and their artifacts, not pointers to externally hosted services. A Cloud Run service is not reachable as an Agent Platform endpoint and gets none of the endpoint's traffic splitting or monitoring. - D is wrong because rewriting a working model in another library to suit the serving stack is a large, risky change, and it still leaves the postprocessing step with nowhere to run.
Reference: Use a custom container for inference