Free Google Cloud Professional ML Engineer Practice Questions: ML Pipeline Automation

Topic snapshot

Sample questions

These are original IT Mastery practice questions aligned to this topic area. They are not official exam questions, copied live-exam content, or exam dumps. Use them for self-assessment, scope review, and deciding what to drill next.

Question 1

Topic: Automating and Orchestrating ML Pipelines

A team runs nightly retraining for a tabular churn model with Agent Platform Pipelines. A Cloud Storage event starts the pipeline when a new daily file arrives. Validation succeeds, but training sometimes starts while preprocessing is still running, and the team wants to keep orchestration managed in the pipeline.

Exhibit: Pipeline fragment

validate_data -> preprocess
validate_data -> train_model
preprocess output: processed_data_uri
train_model parameter: processed_data_uri = ""
train_model log: FileNotFoundError: processed_data_uri is empty

Which engineering decision is best?

Options:

• A. Add retries to the training component

• B. Increase the training worker machine type

• C. Bind training to the preprocessing output and dependency

• D. Replace the pipeline with Managed Service for Apache Airflow

Best answer: C

Explanation: The pipeline graph lets train_model run after validate_data, not after preprocess, and the training parameter is not bound to the preprocessing output. In Agent Platform Pipelines, component ordering should be expressed through artifact or parameter dependencies whenever a downstream step requires an upstream output. Binding processed_data_uri from preprocessing into training also creates the correct execution dependency and passes the actual location to the training job. Retries or larger compute may hide timing symptoms, but they do not fix the missing dependency or empty parameter.

• Larger compute fails because the log shows an empty input URI, not a resource bottleneck.
• Retries fail because repeated attempts can still run without the required preprocessing output.
• Airflow replacement adds orchestration complexity when the managed pipeline DAG can express the needed dependency.

Question 2

Topic: Automating and Orchestrating ML Pipelines

A media company has a tabular churn model serving online predictions. New labeled outcomes arrive daily in BigQuery, and the business wants monthly model improvements with auditable lineage for data, code, and model versions. Releases must automatically block candidates that regress on accuracy or fairness metrics, with minimal custom orchestration on Google Cloud. Which design is the best engineering decision?

Options:

• A. Use Agent Platform Pipelines with validation gates, ML Metadata, and Model Registry promotion.

• B. Schedule BigQuery batch predictions and review dashboard changes monthly.

• C. Train once in Agent Platform Workbench and deploy the notebook output.

• D. Use Cloud Build to redeploy the container on code commits.

Best answer: A

Explanation: An end-to-end MLOps design should make model improvement repeatable and governed. Agent Platform Pipelines can orchestrate scheduled retraining from new BigQuery labels, run data and model validation components, and stop promotion when accuracy or fairness checks fail. Agent Platform ML Metadata captures lineage across inputs, code, artifacts, and metrics, while Agent Platform Model Registry manages model versions and promotion to serving. This turns monthly improvement into an operational process rather than a manual deployment event. The key distinction is that CI, notebooks, and dashboards can support parts of the workflow, but they do not by themselves provide continuous training, validation gates, lineage, and controlled release.

• Notebook deployment is useful for prototyping but lacks scheduled retraining, governed promotion, and durable lineage.
• Code-only CI updates application or container code but does not evaluate new model candidates against data and fairness metrics.
• Prediction dashboards can expose performance trends, but they do not automate retraining, validation, or registry-based release control.

Question 3

Topic: Automating and Orchestrating ML Pipelines

An ecommerce company uses a tabular model to forecast next-week inventory demand. Fresh transactions land in BigQuery daily, but labels are reliable only after 7 days. Model Monitoring shows drift during promotions, and past errors increased when the model was not refreshed before holiday seasons. Bad forecasts can cause costly stockouts, so production changes need validation and staged rollout. Which retraining policy should you implement?

Options:

• A. Keep quarterly retraining and increase endpoint autoscaling when forecast errors rise.

• B. Schedule weekly retraining after label maturity, add pre-holiday runs, and allow drift-triggered runs with validation gates.

• C. Retrain and redeploy automatically every day when new transactions arrive.

• D. Retrain only when model code or the feature schema changes.

Best answer: B

Explanation: A good continuous training policy combines time-based, event-based, and risk-based controls. In this scenario, daily data is not enough by itself because labels mature after 7 days, so retraining should wait for reliable labels. Holiday seasonality justifies planned retraining before known demand shifts. Model Monitoring drift or performance degradation should trigger off-cycle retraining, but the high business impact means the pipeline should include validation checks and staged rollout rather than direct redeployment. The key is to retrain when new trustworthy signal or known seasonality makes the current model stale, then promote only models that pass evaluation.

• Daily redeployment uses fresh but unreliable labels and skips the validation discipline needed for costly inventory decisions.
• Code-only retraining ignores data drift, label freshness, and recurring seasonal demand changes.
• Autoscaling focus addresses serving capacity, not model staleness or forecast accuracy degradation.

Question 4

Topic: Automating and Orchestrating ML Pipelines

A retail company retrains a weekly churn classifier from BigQuery data. The MLOps team must reproduce any production model for audits, recover from transient failures without rerunning successful preprocessing, and deploy only models that pass an approved evaluation threshold. Which pipeline structure is the best engineering decision?

Options:

• A. An Airflow DAG that runs latest scripts and records only final metrics

• B. Separate versioned Agent Platform Pipelines components with ML Metadata and an evaluation gate

• C. One scheduled notebook with inline preprocessing, training, evaluation, and deployment code

• D. One custom training job that deploys the model after training completes

Best answer: B

Explanation: Reproducible ML delivery is best handled as a componentized pipeline with explicit inputs, outputs, parameters, artifacts, and lineage. Agent Platform Pipelines can split preprocessing, training, evaluation, registration, and deployment into repeatable steps, record run metadata in Agent Platform ML Metadata, and reuse successful step outputs when appropriate. A metric gate before registration or deployment also makes change control explicit: only validated model artifacts move forward to Model Registry and serving.

The key takeaway is that orchestration alone is not enough; the pipeline must preserve versions, artifacts, lineage, and promotion criteria across runs.

• Scheduled notebook is easy to start, but it weakens auditability, failure recovery, and repeatable promotion across runs.
• Training-only job misses explicit preprocessing, evaluation, registration, and deployment stages with tracked handoffs.
• Latest-script DAG provides scheduling, but using mutable scripts and only final metrics does not preserve full lineage or change control.

Question 5

Topic: Automating and Orchestrating ML Pipelines

A team uses Cloud Build for CI/CD/CT of a custom model. The build triggers training, builds a serving container, and then deploys the model to Agent Platform Inference. The team must stop deployment when the holdout metric is below the approved threshold or when the container cannot serve a sample prediction. What is the best pipeline configuration?

Options:

• A. Add Cloud Build validation steps before deploy

• B. Enable Model Monitoring after deploy

• C. Run a canary release in production

• D. Increase the Cloud Build machine type

Best answer: A

Explanation: In a CI/CD/CT workflow, release gates should run before the deployment step and fail the build when required checks do not pass. Cloud Build can include steps that read evaluation artifacts or metadata from the training run, compare metrics against an approved threshold, build the serving image, run container health and sample prediction tests, and only then execute the deployment step. This verifies the model and serving artifact at the correct lifecycle stage. Post-deployment monitoring and canaries are useful, but they do not replace a pre-deployment gate when the requirement is to stop an unqualified release before it reaches production.

• Post-deployment monitoring detects issues after serving begins, so it does not block the initial release.
• Canary release limits blast radius but still deploys the candidate model to production traffic.
• Larger build machine may speed up steps, but it does not add metric or container validation.

Question 6

Topic: Automating and Orchestrating ML Pipelines

A team is troubleshooting why its first production ML workflow is still unreliable after three sprints. The workflow only needs monthly retraining for a tabular classifier: run data validation, train, evaluate, and register the model if metrics pass. The only custom logic is a SQL feature query. Failures are mostly component packaging, pipeline parameters, and missing metadata. What is the best next diagnostic step?

Options:

• A. Continue building the fully custom pipeline

• B. Map the workflow to a managed pipeline template

• C. Move orchestration to self-managed Airflow

• D. Run retraining manually from notebooks

Best answer: B

Explanation: Pipeline templates are preferred when the workflow is standard, the required customization is small, and the team is not yet mature in pipeline engineering. The evidence points to over-customization: the model workflow is ordinary, but the team is failing on packaging, parameters, and metadata. The next diagnostic step is to compare the workflow against a managed pipeline template and identify only the small extension point, such as the SQL feature query. A fully custom solution is better when templates cannot express required orchestration logic, integrations, runtimes, or governance needs.

• Maximum flexibility is not useful when the current failures come from custom orchestration complexity rather than model requirements.
• Self-managed Airflow increases operational ownership and does not address the team’s low maturity with pipeline implementation.
• Manual notebooks reduce repeatability, metadata capture, and production reliability for scheduled retraining.

Question 7

Topic: Automating and Orchestrating ML Pipelines

An ML team runs a nightly workflow from an Agent Platform Workbench notebook using cron. The workflow extracts BigQuery data, preprocesses features, trains a custom model, evaluates it, and conditionally registers it. Recent runs were skipped after a notebook maintenance restart, and reviewers cannot trace which dataset snapshot and model artifact produced a registered version. What is the best next step?

Options:

• A. Trigger the notebook with Cloud Scheduler

• B. Rebuild it with Agent Platform Pipelines

• C. Move the schedule to Managed Service for Apache Airflow

• D. Resize the Workbench instance and keep cron

Best answer: B

Explanation: The evidence points to an orchestration and lineage problem, not a model-training or notebook sizing problem. A notebook plus cron is fragile for production ML workflows because restarts can skip runs, and local execution does not provide first-class tracking of pipeline components, artifacts, parameters, and lineage. Agent Platform Pipelines is the managed Google Cloud service designed to orchestrate AI/ML workflows such as preprocessing, training, evaluation, and registration while preserving execution metadata. It also supports repeatable, parameterized runs and step-level retry behavior. Managed Service for Apache Airflow can orchestrate general DAGs, but the requirement here is native managed orchestration for ML workflow execution and traceability.

• Airflow DAGs can orchestrate general workflows, but they are not the most direct fit for native ML artifact and lineage tracking.
• Cloud Scheduler can start a job, but it does not manage multi-step ML execution, retries, or metadata.
• Workbench resizing addresses compute capacity, not skipped cron runs or missing dataset-to-model lineage.

Question 8

Topic: Automating and Orchestrating ML Pipelines

A team trains fraud models in Agent Platform Pipelines and serves approved versions on Agent Platform Inference. They need a repeatable CI/CD workflow that tests code changes, builds the serving container, records the model version, and promotes deployments from staging to production only after review. Which setup best meets these requirements?

Options:

• A. Use Model Monitoring alerts to trigger production redeployment when prediction drift is detected

• B. Use Cloud Build triggers with tests, Artifact Registry, Model Registry, and approval-gated deployment steps

• C. Use Agent Platform Workbench notebooks to manually upload containers and deploy selected model files

• D. Schedule Agent Platform Pipelines to retrain nightly and automatically deploy the newest model to production

Best answer: B

Explanation: Controlled CI/CD for ML deployment should manage each promoted artifact at the right lifecycle layer. Cloud Build triggers can run tests when code changes, build the serving container, push the image to Artifact Registry, register or reference the approved model version in Agent Platform Model Registry, and execute deployment steps to staging and production. Approval gates keep production promotion intentional while preserving an auditable path from source code to container image to model version to endpoint. Training orchestration and monitoring can feed this process, but they should not replace deployment controls.

• Nightly retraining skips controlled promotion and may deploy a model before validation or approval.
• Manual notebooks are useful for exploration but do not provide repeatable, auditable CI/CD promotion.
• Monitoring-triggered redeployment belongs to operations response and does not test, build, version, or approve artifacts.

Question 9

Topic: Automating and Orchestrating ML Pipelines

A retailer uses Agent Platform Pipelines for continuous training of an online churn model. The current policy says: run every Sunday, deploy the newest model if training succeeds, overwrite the production alias, and keep only the final model artifact URI. After a retrain, false positives increase. The team had no early metric alert, cannot compare candidate evaluation with the production baseline, cannot restore the previous version quickly, and cannot show which data and code produced the model.

Which policy gap best explains the incident?

Options:

• A. Insufficient accelerator capacity for the training job

• B. Missing manual notebook review before each retrain

• C. Missing batch prediction before online serving

• D. Missing CT controls for monitoring, evaluation, rollback, and lineage

Best answer: D

Explanation: A continuous training policy should govern more than successful pipeline completion. It should define monitoring signals, candidate evaluation criteria, deployment promotion rules, rollback procedures, and lineage capture through metadata such as data versions, code versions, parameters, artifacts, and model registry entries. In the stem, the model was promoted only because training succeeded, then production quality degraded. The missing alert, missing baseline comparison, inability to restore the previous model, and lack of audit evidence all point to absent CT governance controls rather than a training capacity or serving-mode issue. The key takeaway is that retraining must be treated as a controlled release process, not just an automated training run.

• Training capacity affects runtime or failed jobs, but the incident is about unsafe promotion and missing operational evidence.
• Manual notebook review may help exploration, but it does not define measurable gates, rollback, or lineage for CT.
• Batch prediction first can be useful for some deployments, but it does not by itself provide monitoring, promotion criteria, rollback, or traceability.

Question 10

Topic: Automating and Orchestrating ML Pipelines

A retail company is moving a notebook-based fraud model into a production ML pipeline. Data engineering must own BigQuery feature transformations, ML engineering must own training and evaluation code, security must enforce least privilege and approval before production deployment, and operations must be able to trace and roll back released models. Which pipeline configuration best supports safe cross-team collaboration?

Options:

• A. A BigQuery scheduled query that trains and deploys the model after each data refresh

• B. Managed Service for Apache Airflow with manual spreadsheet tracking of model versions

• C. Agent Platform Pipelines with team-scoped service accounts, Cloud Build, ML Metadata, and Model Registry approvals

• D. A shared Agent Platform Workbench notebook with a single project Editor role for all teams

Best answer: C

Explanation: Safe ML pipeline collaboration needs both workflow automation and governance controls. Agent Platform Pipelines provides an ML-aware orchestration layer, while team-scoped service accounts and IAM boundaries let data, ML, security, and operations teams contribute without sharing broad permissions. Cloud Build supports controlled CI/CD from versioned source, and Agent Platform ML Metadata plus Model Registry provide lineage, artifact tracking, model versioning, approvals, and rollback references. This setup addresses the full production lifecycle instead of only scheduling jobs or sharing a development environment.

The key distinction is that collaboration safety comes from least privilege, versioned artifacts, auditable metadata, and controlled promotion gates together.

• Shared notebook fails because it centralizes execution and broad access instead of enforcing governed, reproducible production workflows.
• Manual tracking fails because spreadsheets do not provide reliable lineage, artifact governance, or automated release controls.
• Scheduled training fails because it automates one step but skips approvals, model version governance, and operational rollback support.

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
• Serving and Scaling Models
• Monitoring AI Solutions