Professional Machine Learning Engineer · 22% of the exam

Automating and orchestrating ML pipelines: free practice questions

5 sample questions from our 55-question bank for this domain — answers and explanations included. These are the same scenario-based style as the real Google Cloud exam.

1. Your team implements a Vertex AI Pipeline that trains a recommendation model. The model training component takes as input a parameter `num_epochs` set to 50. After several production runs, you discover that due to changes in data distribution, 50 epochs often leads to overfitting. You want to modify the pipeline to automatically reduce `num_epochs` if the validation loss does not improve after 10 epochs (early stopping). Which approach best implements this without modifying the pipeline definition repeatedly?

  • A. Implement early stopping logic inside the training component code itself, configurable via a component parameter.✓ Correct
  • B. Create a separate pipeline that runs the training component with different epoch values and selects the best result.
  • C. Manually monitor training runs and change the num_epochs parameter before each run.
  • D. Use a Cloud Composer DAG to wrap the Vertex AI Pipeline and implement dynamic parameter adjustment between runs.
Explanation

The correct answer is to implement early stopping logic within the training component code, configurable via parameters (e.g., `early_stop_patience=10`). This keeps the logic where it belongs—in the training logic—and is parameterizable. The pipeline definition does not change; only component code evolves. Option B (separate pipeline with grid search) is overkill and expensive. Option C (manual intervention) defeats automation. Option D (Cloud Composer wrapper) adds unnecessary orchestration layer when the logic should be in the component. Component-level early stopping is standard ML practice and integrates naturally with Kubeflow Pipelines.

2. Your team uses Vertex ML Metadata to track lineage for a TFX-based recommendation model pipeline. You want to query the lineage to identify which training data versions contributed to a specific model version deployed in production. The model artifact has ID 'model_v42' in Metadata. What is the most efficient way to retrieve this lineage information?

  • A. Use the Vertex ML Metadata client to call `get_execution()` for the training execution that produced model_v42, then traverse backward through input artifacts to identify data source versions.✓ Correct
  • B. Export all metadata to BigQuery and query the lineage tables directly using SQL joins.
  • C. Manually review pipeline run logs in Cloud Logging to identify which data was used.
  • D. Use the Vertex AI Model Registry API to query the model's metadata field, which automatically includes full lineage.
Explanation

The correct answer is to use the Vertex ML Metadata client to retrieve the execution that produced the model artifact and traverse its input artifacts. This is the programmatic, queryable approach native to Vertex ML Metadata. Option B (export to BigQuery) works but is less direct. Option C (manual log review) is not scalable. Option D is incorrect because Model Registry does not automatically track Vertex ML Metadata lineage in its metadata fields; these are separate systems. Option A leverages the Vertex ML Metadata API's lineage traversal capabilities.

3. Your organization runs a Vertex AI Pipeline that trains a time-series forecasting model on streaming data ingested into BigQuery. The pipeline must run daily at 2:00 AM UTC, but the training must use only data from the previous 7 days. You also need to ensure that if the pipeline fails, it retries once after 1 hour. How should you configure the schedule and retry logic?

  • A. Create a Cloud Scheduler job that triggers the pipeline daily at 2:00 AM UTC, and configure the Vertex AI Pipeline execution with max_retries=1 and a 1-hour retry delay.
  • B. Use a Vertex AI Pipeline schedule resource with recurrence set to daily at 2:00 AM UTC, and set max_retries=1 with retry_delay_seconds=3600 in the PipelineJob specification.✓ Correct
  • C. Configure a Cloud Function that runs on a Cloud Pub/Sub timer and manually invokes the pipeline, then implement retry logic in the function.
  • D. Create two separate pipelines—one for scheduling and one for execution—and use Cloud Composer to orchestrate them.
Explanation

The correct answer uses Vertex AI's native schedule resource with recurrence settings and max_retries/retry_delay in the PipelineJob specification. This is the built-in, recommended approach for Vertex AI Pipelines. Option A (Cloud Scheduler with Pipeline retries) can work but requires additional configuration outside Vertex AI. Option C (Cloud Functions + Pub/Sub) is over-engineered. Option D (separate pipelines + Cloud Composer) is unnecessarily complex when Vertex AI native scheduling is available. The 7-day data window is handled by parameterizing the pipeline with a date range, not by the scheduling mechanism itself.

4. You are configuring a Vertex AI Pipeline that processes large unstructured image data. The data validation component must reject images with resolution below 512×512 pixels before they reach the model training component. Which approach best implements this validation gate?

  • A. Add a `dsl.Condition()` block after the data validation component that checks output metrics and conditionally skips the training component if validation fails✓ Correct
  • B. Use a metric threshold in the validation component's output artifact schema to automatically halt the pipeline execution
  • C. Implement validation logic inside the training component and catch exceptions to prevent model training
  • D. Create a separate validation pipeline and manually review results before triggering the training pipeline
Explanation

The correct answer is option 0. Vertex AI Pipelines (built on Kubeflow Pipelines SDK v2) uses `dsl.Condition()` to implement conditional task execution based on upstream component outputs. This creates a validation gate where the training component only executes if the validation component confirms data quality. Option 1 is incorrect because metric thresholds in artifact schemas are metadata—they don't control pipeline flow. Option 2 is wrong because exception handling inside a component doesn't stop upstream tasks from executing. Option 3 is inefficient and defeats the purpose of automation and orchestration.

5. Your team is building a Vertex AI Pipeline to retrain a fraud detection model weekly. The pipeline must automatically register the newly trained model only if its AUC-ROC on a held-out evaluation set exceeds the currently deployed model's AUC-ROC by at least 2%. Which approach best implements this conditional model registration gate?

  • A. Add a custom component after the evaluation step that reads both AUC-ROC values, compares them, and calls the Vertex AI Model Registry API to upload the model only when the improvement threshold is met.✓ Correct
  • B. Use a Vertex AI Pipeline parameter to hard-code the threshold, and rely on the training component to skip model upload automatically when performance degrades.
  • C. Configure a Cloud Monitoring alert that triggers a Cloud Function to register the model if the evaluation metric emitted as a custom log exceeds the threshold.
  • D. Set the pipeline's failure policy to FAIL_FAST so the pipeline terminates before the model upload step whenever the AUC-ROC threshold is not met.
Explanation

A custom component that performs the comparison and conditionally calls the Model Registry API is the canonical pattern in Vertex AI Pipelines for implementing a model validation gate. It keeps the logic inside the DAG, is auditable via pipeline metadata, and uses the official SDK. Option B is incorrect because the training component is not responsible for deployment decisions and the threshold cannot 'automatically' be enforced without explicit conditional logic. Option C moves the gating logic outside the pipeline to Cloud Monitoring and Cloud Functions, introducing operational complexity and losing lineage traceability within the pipeline. Option D misuses FAIL_FAST, which is a pipeline-level failure handling policy unrelated to conditional branching; it would mark the run as failed rather than gracefully skipping registration.

50 more questions in this domain

Practice the full bank with instant grading, flashcards, and a timed mock exam.

Start practicing free
Automating and orchestrating ML pipelines — Free Professional Machine Learning Engineer Practice Questions | DataCertPrep — Certification Prep