How to serve an XGBoost model as an HTTP microservice with least effort?

You recently trained an XGBoost model on tabular data. You plan to expose the model for internal use as an HTTP microservice. After deployment, you expect a small number of incoming requests. You want to productionize the model with the least amount of effort and latency. What should you do?

  1. Deploy the model to BigQuery ML by using CREATE MODEL with the BOOSTED_TREE_REGRESSOR statement, and invoke the BigQuery API from the microservice.
  2. Build a Flask-based app. Package the app in a custom container on Vertex AI, and deploy it to Vertex AI Endpoints.
  3. Build a Flask-based app. Package the app in a Docker image, and deploy it to Google Kubernetes Engine in Autopilot mode.
  4. Use a prebuilt XGBoost Vertex container to create a model, and deploy it to Vertex AI Endpoints. Source Reference Answer

Community Votes

D
100%

100% of anonymous learners picked answer D. Votes are pick records left by other test-takers — they are not the verified answer.

Community Insight

The question tests matching 'least effort and latency' to a prebuilt serving container on a managed endpoint, and the trap is choosing options that require building custom Flask containers or retraining the model in BigQuery ML.

Serving a trained XGBoost model with minimal effort and latency is best achieved by uploading it to Vertex AI with the prebuilt XGBoost prediction container and deploying it to a managed Vertex AI Endpoint. The community unanimously (100% of votes) agrees this avoids custom serving code while delivering a low-latency managed HTTP microservice.

The most common wrong answer is B: building a Flask app in a custom container on Vertex AI Endpoints. It seems right because it also uses managed endpoints, but writing, packaging, and maintaining custom serving code directly contradicts the 'least amount of effort' requirement that the prebuilt XGBoost container eliminates.

Community Discussion (4 comments)

pikachu007 👍 7 Selected: D
Prebuilt Container: It eliminates the need to build and manage a custom container, reducing development time and complexity. Vertex AI Endpoints: It provides a managed serving infrastructure with low latency and high availability, optimizing performance for predictions. Minimal Effort: It involves simple steps of creating a Vertex model and deploying it to an endpoint, streamlining the process.
b1a8fae 👍 5 Selected: D
Bit lost here. I would discard buiding a Flask app since that is the opposite of "minimum effort". Between A and D, I guess a prebuilt container (D) involves less effort, but I am not 100% confident.
AzureDP900 👍 1
Option D is correct : Using a prebuilt XGBoost Vertex container (Option D) is the most straightforward approach. This container is specifically designed for running XGBoost models in production environments and can be easily deployed to Vertex AI Endpoints. This will allow you to expose your model as an HTTP microservice with minimal additional work.
fitri001 👍 2 Selected: D
Package the Model: Use a library like xgboost-server to create a minimal server for your XGBoost model. This package helps convert your model into a format suitable for serving predictions through an HTTP endpoint. Deploy to Cloud Functions: Deploy the packaged model server as a Cloud Function on Google Cloud Platform (GCP). Cloud Functions are serverless, lightweight execution environments ideal for event-driven applications like microservices. Configure Trigger: Set up an HTTP trigger for your Cloud Function, allowing it to be invoked through HTTP requests.

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Expert Analysis

Why the Answer Is Correct

Vertex AI publishes prebuilt prediction containers specifically for XGBoost, so you can upload the trained model artifact and deploy it without writing any serving code. Deploying to a Vertex AI Endpoint provides a fully managed, low-latency HTTP service with autoscaling, health checks, and traffic handling managed by Google. Because only a small number of requests are expected, a single lightweight node on the endpoint keeps both cost and latency minimal. As comment 1 explains, the prebuilt container 'eliminates the need to build and manage a custom container, reducing development time and complexity,' which directly satisfies the least-effort requirement.

Why the Other Options Are Wrong

Option A uses CREATE MODEL with BOOSTED_TREE_REGRESSOR, which trains a new model inside BigQuery ML rather than serving the XGBoost model you already trained, and invoking the BigQuery API per request adds unnecessary query latency. Option B is functionally viable, but building, testing, and maintaining a Flask app plus a custom container is exactly the overhead the question asks you to avoid; comment 2 notes that building a Flask app is 'the opposite of minimum effort.' Option C adds even more operational burden, since GKE Autopilot still requires cluster setup, Docker image management, and Kubernetes service configuration for a low-traffic microservice. The Cloud Functions idea floated in comment 3 is not among the options and would still require custom packaging of the model server.

Community Comment Notes

Comment 1, with the most likes (7), justifies D across three angles: the prebuilt container, managed Vertex AI Endpoints, and minimal deployment steps. Comment 2 shows the practical elimination process, discarding the Flask-based options first and then choosing the prebuilt container over BigQuery ML. Comment 4 reinforces that the prebuilt XGBoost container is 'the most straightforward approach' for exposing the model as an HTTP microservice. With 100% of votes on D, there is no meaningful community disagreement on this question.

Official Reference

Exam Strategy

When a question stresses 'least effort' for serving a supported framework like XGBoost, TensorFlow, or scikit-learn, immediately look for the prebuilt container plus managed endpoint option. Custom containers and GKE are reserved for models that need custom dependencies, preprocessing, or fine-grained control. Also reject any option that retrains a new model (such as CREATE MODEL) instead of serving the artifact you already built.

Related Analysis

Practice All PMLE Questions

Access 65 questions with complete answers and detailed explanations.

View Full PMLE Practice Test →

← Back to PMLE Study Guide