Articles
Vertex AI Interview Questions: Model Uploads, Endpoint Deployments, and Prediction Contracts
Practice Vertex AI interview questions on model uploads, endpoint deployments, health routes, prediction payloads and rollback contracts.
Vertex AI interview questions become much easier when you stop treating “the model” as one object. A model can appear in the registry while no serving deployment exists. A container can accept health checks while rejecting every prediction. A successful response can still use the wrong feature order or model version.
The useful interview skill is tracing those boundaries: what was uploaded, what was deployed, where traffic went, and what the prediction contract required.
Official behavior below comes from Google Cloud documentation. The logs, identifiers and exercises are original teaching examples. This guide covers custom-trained model serving through the aiplatform resource APIs; it does not assume that a Gemini publisher-model request follows the same upload and deployment path.
Vertex AI interview questions: identify the four objects
Google’s custom-container guide describes a Model with a container specification. Its deployment sample separately references that Model, creates a DeployedModel on an Endpoint, and assigns traffic. Those distinctions are the starting point for an answer.
| Object or boundary | What you should record | What its existence does not establish |
|---|---|---|
| Artifacts and image | Artifact location, image digest, preprocessing version | A registered or running model |
| Model | Resource name, version, container configuration | An Endpoint deployment |
| DeployedModel | Deployment ID, referenced Model, serving resources | That normal client traffic reaches it |
| Endpoint and prediction | Endpoint identity, traffic allocation, request and response | Correct business meaning of the output |
Imagine a registry entry called risk-score. A client also has an endpoint variable named risk-score. Display names do not tell you whether they refer to the same resource, region or version. In an interview, ask for full resource names and the returned deployment ID before investigating latency.
A concise answer to “Does uploading make the model available for online prediction?” is: uploading establishes a Model resource; online serving requires the appropriate deployment and request destination. Follow that answer with the evidence you would collect. Naming the separation matters more than memorizing a console button.
Explain upload success without overclaiming readiness
The official upload sample supplies a serving image and artifact location, then waits for the upload operation. For a custom container, the container guide makes Cloud Storage artifacts optional. An image may package its own model, so “every upload must have a bucket of weights” is too broad.
Our original upload ledger records:
image: regional-repository/risk-server@sha256:example
artifact path: gs://example-models/risk/v17/
Model: projects/example/locations/us-central1/models/410
upload result: operation completed successfully
Endpoint: not yet selected
DeployedModel: not yet created
The ledger establishes that the upload operation completed for the recorded Model. You have no observation of a running server, a loaded artifact or a successful prediction. Adding a “ready” flag to this ledger would hide work that has not happened.
If the interviewer changes the artifact path after upload, do not guess that existing replicas hot-reload it. Ask how the serving image reads artifacts, whether the location is immutable, and which deployment must be replaced. Your recovery design should preserve the exact image, artifacts and preprocessing used together. A model weight file alone is an incomplete rollback package.
Separate image access from runtime artifact access
Google’s container requirements distinguish the service agent that pulls the container image from a custom service account used by serving code. Granting Artifact Registry access to the latter is not automatically a fix for an image-pull failure.
That official distinction supports an original diagnostic sequence. If deployment fails before the process starts, inspect the image URI, repository location, service-agent access and deployment operation details. If the process starts but logs an artifact-access error, identify the principal making that runtime read and the actual location it requests. A successful pull does not prove that serving code can read a separate bucket.
Keep the scopes explicit when proposing a fix. “Give the model permissions” names neither an identity nor an operation. A better answer is: “Determine which principal failed which read, then grant only the required access to that resource.” Also separate the caller’s permission to invoke prediction from the server’s permission to obtain its inputs. They sit on opposite sides of the request.
Do not interpret a generic permission-denied message in isolation. Match it to an operation, timestamp and identity. Otherwise, a broad role change may appear to help because a deployment retry coincidentally reached a different stage.
Use a deployment ledger before changing traffic
The deployment sample returns a long-running operation and waits for completion. It uses the special traffic-split key "0" for the newly deployed model. Those are official sample semantics, not a reason to identify every later prediction as deployment zero.
For the original example, write down the transition explicitly:
before: Endpoint 900 -> DeployedModel 71, Model 409, 100%
request: deploy Model 410; allocate 10% to the new deployment
operation: pending, then completed
after: Endpoint 900 -> 71 at 90%, 72 at 10%
The deployment IDs here are invented. Their purpose is to show what your client should observe after the operation completes. Verify the resulting configuration rather than relying on the request you intended to send.
Now ask what a ten-percent canary proves. It can expose traffic to the new deployment, but it does not establish user-level assignment, identical workloads or correct predictions. Our recommendation is to compare deployment-specific errors, latency and domain checks before increasing traffic. Keep the previous deployment available until the rollback decision is meaningful.
If the new version changes the feature schema, switching traffic back may not recover clients that already changed their payloads. Plan a compatible overlap or versioned client contract. A traffic rollback and a schema rollback are separate decisions.
Diagnose a healthy server that rejects predictions
The container requirements specify a listening HTTP server and separate health and inference routes. Under the documented default health-check behavior, a successful health response establishes readiness according to that check. It does not run your application’s complete prediction validation.
Use this original request ledger. The exercise assumes a server that implements /health and /predict, with those exact routes configured on the Model.
| Observation | What it establishes | Next useful check |
|---|---|---|
| Deployment operation completed | The deployment operation succeeded | Read deployed resource and traffic configuration |
Container log: GET /health -> 200 | That health route answered successfully | Check whether readiness depends on model loading |
Local POST /predict with valid fixture succeeds | The local image handles that fixture | Compare image, environment and deployed request |
Deployed log: POST /predict -> 400, missing instances | This request reached prediction parsing and failed validation | Inspect the transmitted JSON envelope |
The last row changes the investigation. Increasing machine size is unlikely to repair a missing field. First reproduce the smallest failing payload and compare it with the successful fixture.
If no prediction access log appears, the evidence is different. Investigate caller authorization, endpoint selection, traffic, health and route configuration before asserting that preprocessing crashed. An absent log is not conclusive by itself: confirm that logging is enabled and that you are examining the correct deployment.
State the prediction contract at both boundaries
Google’s online prediction guide shows a REST JSON envelope with an instances array. Its Python SDK example passes that array as endpoint.predict(instances=instances). Passing an already wrapped object where a list is expected confuses the SDK boundary with the REST boundary.
For our original two-feature risk model, define the application contract before writing a client:
{
"instances": [[125.0, 3.0], [40.0, 12.0]],
"parameters": {"threshold": 0.7}
}
Assume the features mean amount_usd followed by account_age_days. The numbers and threshold are teaching choices. Both rows are valid JSON even if someone swaps the feature order. A type check can therefore miss a feature-order mistake.
An answer should cover feature order, expected width, units, missing-value policy, preprocessing version and output meaning. Ask whether the returned number is a calibrated probability, a raw score or a class label. A threshold has different meaning for each.
For the fixture, require two predictions corresponding to the two input rows in order. Reject a response with one result, three results or a different association. Google’s online prediction documentation describes ordered per-instance responses; your application tests should make that requirement visible rather than checking only for status 200.
The same guide distinguishes rawPredict, which permits arbitrary HTTP payloads, from the standard prediction envelope. Choose it deliberately when your model server needs another protocol. Do not “fix” a broken standard contract by changing APIs without discussing which integration behavior and observability you need to preserve.
Practice contract failures without a cloud deployment
This original exercise can run around a local handler or a pure validation function. It tests your application contract; it does not establish that Vertex AI deployment, IAM or networking works.
Start with two valid feature rows. Then independently change one condition: omit instances, supply a row of the wrong width, insert a string into a numeric field, swap features while keeping their types, or return predictions in reverse order. State which cases input validation catches and which require a semantic fixture with known expected outcomes.
For example, a width check catches [125.0], but not [3.0, 125.0]. A known-case assertion can expose the latter only if the fixture meaning and expected output are trustworthy. Include a case where the model score legitimately changes between versions so that your test suite does not freeze all predictions forever.
Then add a request ID to the client-side ledger and deployment identity to the response record. Keep sensitive feature values out of routine logs. You want enough evidence to associate a failure with the correct contract and deployment without making production data the debugging interface.
When presenting this exercise, describe the limit honestly: “These fixtures validate serialization, shape and response association locally. I would separately verify the deployed image, permissions, health and endpoint routing.” That is a stronger answer than calling a passing local test an end-to-end serving test.