Free Professional Machine Learning Engineer practice test: 30 questions with answers

A managed feature store serves the same feature definitions to offline training and online prediction, which prevents mismatched values. A spreadsheet or local copies depend on people keeping them aligned, and a Pub/Sub topic delivers messages but does not manage feature consistency.

Granting each team IAM access to one dataset keeps a single governed source, with the owner controlling access and sensitive columns. Emailed copies and local laptop copies drift apart and escape control. Separate local copies in notebooks are the same problem in another form.

Vertex ML Metadata and Experiments record artifacts, parameters and the lineage between datasets, runs and models, which supports comparison and tracing. Log sinks and object versions keep records but do not link them into lineage. A shared notebook with pasted outputs is manual and not traceable.

The Vertex AI Model Registry stores model versions with labels and aliases, and its deployment history supports a review step before a version is promoted. Lifecycle rules delete files rather than manage versions, and deploying every commit skips review. A notebook log is not a registry.

Versioning datasets and models, and recording the version each run used, makes results traceable. Documenting owners and access policies in the catalog keeps sharing governed. Shared service keys weaken security, in-place edits remove history, and personal-only data prevents collaboration.

Custom training on Vertex AI with distributed workers reads the full data from storage and parallelises the work, which is how a prototype becomes a scalable model. A single bigger VM hits limits, and downsampling discards most of the data. Manual splits on laptops are slow and hard to reproduce.

Accelerators with a suitable distributed strategy speed up the heavy matrix operations that dominate deep learning training. More epochs lengthen training, removing validation does not speed up the main compute, and a batch size of one usually slows throughput.

Hyperparameter tuning jobs run many trials across a defined search space and report the best one. Batch prediction, Model Monitoring and Explainable AI each support a different stage, and none of them searches for training hyperparameters.

Using the same preprocessing code, packaged with the pipeline, for training and serving keeps the transformations identical, which prevents skew. Reimplementing the steps by hand or running different versions in each place is the cause of training-serving skew.

Preemptible or Spot capacity with checkpoints lowers the price of compute without losing completed progress, and early stopping avoids paying for runs that will not improve. The largest accelerator for every run, idle clusters and full copies to every worker all increase cost without a benefit.

An online endpoint with autoscaling returns predictions for individual requests with low latency. Batch jobs and scheduled queries produce results on a schedule rather than per request, and a manually started pipeline is far too slow for a live request.

Traffic splitting across versions deployed to the same endpoint sends a set percentage of requests to the new version, which supports a gradual rollout. Deleting the current model removes the fallback, and a second project forces users to change. Zero minimum replicas affects scaling, not traffic routing.

Autoscaling with a sensible minimum and maximum matches capacity to traffic, which reduces cost while keeping latency acceptable. Pinning replicas at peak wastes money all day, and a weekly batch job cannot answer online requests. An open notebook is not a production serving pattern.

A custom prediction container image lets the team choose its inference server and libraries, and Vertex AI deploys it to an endpoint. AutoML tabular models and BigQuery ML models use their own serving paths, and a Vision API key uses a managed model that the team cannot modify.

Batch prediction over BigQuery scales to large volumes without per-row calls, and caching repeated inputs avoids scoring the same request again. Calling an endpoint row by row is slow at that size, and client-side loading or text compression do not address throughput.

Vertex AI Pipelines orchestrates defined steps and records artifacts and lineage for every run, which suits a repeatable weekly retrain. A cron-driven notebook and notifications lack tracked lineage, and a dashboard only displays results rather than running the pipeline.

An Eventarc trigger on the Cloud Storage upload starts the pipeline as soon as new data arrives, which removes manual steps. Approvals, reminders and dashboards all depend on a person acting, or they only display information.

A conditional pipeline step compares the candidate's metrics with a threshold or the current baseline, so the rule is enforced on every run. Manual reviews and comments depend on people following them, and a display name does not gate deployment.

Pinned image versions and recorded parameters and data versions let a run be recreated later and in another environment. Whatever library happens to be installed, a laptop-only definition and the latest tag all change behaviour between runs without warning.

Testing and deploying pipeline changes through a reviewed path, and versioning infrastructure and pipeline definitions, make ML delivery repeatable and auditable. Skipping evaluation, personal unversioned copies and hidden failures all undermine reliability.

BigQuery ML trains and evaluates models with SQL where the data already lives, which matches an analyst's skills and avoids moving data. A custom TensorFlow cluster and a laptop workflow require engineering effort and copies of the data. Writing feature tables per request is an inference pipeline, not a way to build the model.

AutoML image classification trains a model on the team's labelled images with managed infrastructure and little code, which is the requirement. A custom container needs manual setup, and Vision label detection uses generic labels rather than the team's categories. Matrix factorisation is for recommendation-style problems and is a poor fit for raw pixels.

Vertex AI Search or a grounded generative model over an index of the articles gives answers based on the company's content with little custom ML work. Training a transformer from scratch needs large data and specialist effort. Keyword search and manual answers do not meet the assistant requirement.

AutoML tabular in Vertex AI trains and tunes candidate models automatically, and the chosen model can be deployed to an endpoint in Vertex AI. It is designed for structured tabular data, and it does not require hand-written training loops or deployment outside the platform.

BigQuery ML's ARIMA_PLUS model forecasts time series per store with SQL, next to the sales data, which meets the minimal-code requirement. A hand-built PyTorch network needs far more engineering effort, and a moving average or a mean is not a forecasting model with the horizon and seasonality the team needs.

Vertex AI Model Monitoring compares production feature and prediction distributions against a baseline, which reveals drift over time. Billing reports, storage lifecycle rules and DNS logs describe cost, storage and traffic, not whether the model's inputs or outputs have shifted.

Training-serving skew compares serving feature distributions with the training distributions, which shows the mismatch the question describes. Replica counts, request sizes and version counts describe infrastructure or storage, not the data values.

Cloud Monitoring latency metrics with an alerting policy at the objective's threshold notify the team automatically when the objective is breached. Sprint reviews, billing emails and a watched browser are slow, indirect, or depend on someone being present.

Segment-level monitoring reveals unfair performance differences, and feature attributions help investigate unexpected predictions. Reviewing accuracy only at launch misses later degradation, and removing explainability or ignoring user feedback removes the signals that responsible monitoring depends on.

Tracking performance by segment, with fairness metrics measured against the defined goals over time, shows whether the model treats groups fairly in production. Overall accuracy hides group differences, removing the data stops any measurement, and an annual review is too infrequent.