Automating and Orchestrating ML Pipelines practice questions

@dsl.component\ndef my_component(input_text: str) -> Metric:\n metrics = Metric()\n metrics.log_metric('length', len(input_text))

Why it fails: Incorrect artifact type: should be Metrics (plural) and base_image missing; also Metric class doesn't exist in kfp.dsl.

@dsl.pipeline\ndef my_pipeline(input_text: str):\n metrics = Metrics()\n metrics.log_metric('length', len(input_text))

Why it fails: Incorrect: @dsl.pipeline is for pipeline definitions, not components. Also missing return type.

def my_component(input_text: str) -> Metrics:\n from kfp.dsl import Metrics\n metrics = Metrics()\n metrics.log_metric('length', len(input_text))\n return metrics

Why it fails: Missing @dsl.component decorator; without it, this is a plain Python function, not a KFP component.

Cloud Scheduler for the schedule, and Cloud Pub/Sub with Push subscription to Vertex AI for event-driven.

Why it fails: Cloud Pub/Sub cannot directly trigger Vertex AI pipelines; it requires a subscriber like Cloud Functions.

Cloud Functions for both schedule and event-driven, using cron trigger.

Why it fails: Cloud Functions cannot use a cron trigger to respond to new data arriving in a Cloud Storage bucket; cron triggers are time-based, not event-based. While Cloud Functions are suitable for both event-driven processing via Cloud Storage events and scheduled execution when paired with Cloud Scheduler, the option incorrectly suggests a single cron trigger mechanism for both requirements. Cloud Functions are often a correct choice for lightweight, event-driven tasks that need to react to various Google Cloud events or execute on a schedule, acting as the compute layer that then orchestrates other services.

Vertex AI Pipelines built-in scheduler for schedule, and Cloud Pub/Sub for event-driven.

Why it fails: Vertex AI Pipelines does not have a built-in scheduler; it relies on Cloud Scheduler. Also Pub/Sub alone cannot trigger pipelines.

Pass data in-memory as Python objects between components.

Why it fails: In-memory passing is not supported in KFP; data must be serialized and stored externally.

Use BigQuery table names as component outputs and inputs.

Why it fails: BigQuery table names are acceptable but less portable; GCS URIs are more standard for artifact passing.

Use Cloud SQL to store intermediate results and pass connection strings.

Why it fails: Cloud SQL is not designed for intermediate data passing in ML pipelines; adds latency and complexity.

A Lightweight Python component without base_image.

Why it fails: Lightweight components are Python functions; they cannot use custom containers.

A Python function component with a custom base_image.

Why it fails: Python function components with base_image still run Python code; they don't allow full custom container images.

A pre-built component from GCPC.

Why it fails: Pre-built components are for standard tasks; they don't allow arbitrary containers.

The precision value is stored as a float but the condition expects a string.

Why it fails: dsl.If comparisons fail when the operand is a ClassificationMetrics artifact, not because of float-versus-string typing; KFP conditions handle numeric types. It is tempting because type mismatches do cause failures elsewhere, but the actual cause is that the metric must be extracted as a primitive output before comparison.

The evaluation component did not output the metric correctly.

Why it fails: A missing or malformed metric output would raise a pipeline error rather than silently evaluating False. It is tempting because component output bugs are plausible, but the consistent False result indicates the condition compares an artifact object instead of a scalar value, which is the real cause.

The dsl.If block is placed incorrectly in the pipeline definition.

Why it fails: Placement of dsl.If affects execution order, not the boolean result; a misplaced block still evaluates its condition. It is tempting because pipeline structure errors are common, but the condition failing consistently points to the metric being passed as a ClassificationMetrics artifact rather than a scalar, which dsl.If cannot compare.

Cloud Monitoring and Cloud Logging

Why it fails: These are for monitoring infrastructure, not for data skew detection.

Cloud DLP and Cloud KMS

Why it fails: These are for data security and encryption, not for data skew.

BigQuery and Dataflow

Why it fails: BigQuery and Dataflow can be used for data processing but not for built-in skew detection.

Use Cloud Functions to periodically check for new model versions and deploy.

Why it fails: Polling with Cloud Functions introduces delay and cannot enforce an evaluation gate before promotion; it deploys whatever version it finds. It is tempting for scheduled checks, but the scenario requires event-driven promotion gated on evaluation results, not periodic polling.

Manually approve each model version before deployment.

Why it fails: Manual approval contradicts continuous delivery; automated gates are preferred.

Deploy every model version directly to production without evaluation.

Why it fails: Deploying every version unconditionally bypasses the evaluation gate entirely, so failing models reach production. It is tempting as the simplest continuous deployment pattern, and would be correct where rollback is trivial and evaluation happens post-deployment via monitoring rather than as a promotion precondition.

Use the Vertex AI Pipelines console to set a cron schedule directly on the pipeline.

Why it fails: Vertex AI Pipelines does not have a built-in scheduler; you must use Cloud Scheduler or other external triggers.

Create a Cloud Build trigger that runs the pipeline on a schedule.

Why it fails: Cloud Build triggers are for CI/CD, not scheduling recurring pipelines.

Use Cloud Tasks to create a recurring task that invokes the pipeline.

Why it fails: Cloud Tasks is for distributed task queues, not recurring schedules.

Use the dsl.CacheKey annotation to explicitly set cache keys.

Why it fails: dsl.CacheKey is not a valid KFP SDK v2 construct.

Change the component's image tag to :latest.

Why it fails: Using :latest is not recommended and may not invalidate cache if the digest is unchanged; it also breaks reproducibility.

Add a random integer parameter to the component to vary the inputs.

Why it fails: This would force re-execution but is a hack; the proper way is to disable caching.

AutoMLTabularTrainingJobRunOp

Why it fails: This is specifically for AutoML tabular training, not custom training.

VertexEndpointCreateOp

Why it fails: This is for creating an endpoint, not training.

VertexBatchPredictOp

Why it fails: This is for batch prediction, not training.

dsl.Metrics

Why it fails: dsl.Metrics only records scalar metric values for later visualisation and comparison; it launches no tasks, so it cannot run parallel training jobs. It is tempting because it genuinely supports the hyperparameter-tuning workflow's final stage — logging each trial's accuracy or loss so the best model can be selected — but orchestration requires dsl.ParallelFor.

dsl.If

Why it fails: dsl.If performs conditional branching, evaluating a boolean expression to execute one of two branches, so it cannot fan out parallel training jobs. It is tempting because hyperparameter selection feels conditional, but that construct belongs in a pipeline that chooses between alternatives, not one that launches concurrent trials.

dsl.Collected

Why it fails: dsl.Collected is a type annotation for declaring collected output artefacts, not a control-flow construct that launches tasks. It is used when a component consumes a list of artefacts produced by upstream tasks, not to fan out parallel training.

Increase the Airflow task timeout to account for the maximum expected pipeline duration.

Why it fails: This is a workaround but not robust; better to use asynchronous polling.

Run the pipeline synchronously by using a Kubernetes Pod operator.

Why it fails: Not necessary; the Vertex AI operator handles asynchronicity properly.

Split the DAG into two DAGs: one for the pipeline, one for the rest.

Why it fails: This loses the orchestration dependency and adds complexity.

Use Vertex AI Pipelines to deploy to production directly after evaluation.

Why it fails: This bypasses manual approval, which is required in the scenario.

Use Cloud Scheduler to trigger deployment every hour.

Why it fails: Not event-driven and lacks evaluation gate.

Use Cloud Functions to deploy after evaluation without approval.

Why it fails: Lacks manual approval step.

Use ContainerOp class from kfp.v2.dsl.

Why it fails: ContainerOp belongs to the legacy kfp.v2.dsl syntax, where the image is passed as an argument to the constructor rather than declared in the component specification. The decorator-based approach defines the image through the base_image parameter. ContainerOp tempts because it was the standard pattern in earlier Kubeflow Pipelines versions before the v2 authoring style.

Use a placeholder in the pipeline YAML.

Why it fails: A placeholder in the pipeline YAML supplies a runtime value for an input parameter; it does not declare which container image the component executes. The image must be named in the component specification itself. Placeholders tempt because pipeline YAML does parameterise many fields, but image selection is fixed at component definition time, not resolved at runtime.

Use the @dsl.component decorator and set the base_image parameter.

Why it fails: @dsl.component is for Python function-based components, not container components.

VertexEndpointDeployOp

Why it fails: This deploys a model to an endpoint, not register it.

CreateModelVersionsOp

Why it fails: Not a standard component name.

ModelRegisterOp

Why it fails: Not a standard component name.

Cloud Scheduler

Why it fails: Only for time-based scheduling, not orchestration.

BigQuery scheduled queries

Why it fails: Only for BigQuery queries, not full orchestration.

Cloud Functions

Why it fails: Not designed for complex orchestration with dependencies and retries.

Package the training code as a Vertex AI Training custom job and call it from a Python function component.

Why it fails: This adds complexity and is not the standard way to create reusable container components.

Define a Python function component using @dsl.component and pass hyperparameters as function arguments.

Why it fails: Python function components cannot use custom containers; they run Python code directly.

Use a pre-built Google Cloud Pipeline Component for custom training and override the image.

Why it fails: Pre-built components do not support custom container images.

Store the data in BigQuery and pass the table reference.

Why it fails: This is not the standard pattern for artifact passing in KFP.

Define output as a string and pass the GCS path manually.

Why it fails: While possible, using artifact types provides better tracking and lineage.

Use in-memory Python objects as function return values.

Why it fails: Passing data in-memory is not possible in distributed pipelines and violates best practices.

Ensure the component is deterministic and that caching is not disabled for that component.

Why it fails: While ensuring determinism and checking caching settings can help, it is a more manual approach. The question asks what they should do; using a pre-built component is a more direct solution.

Enable pipeline caching by setting 'enable_caching=True' on the pipeline decorator.

Why it fails: Incorrect because 'enable_caching=True' is not the correct API; caching is enabled by default and controlled per task.

Use the 'dsl.CachingOptions' to set a custom cache key for the component.

Why it fails: Unnecessary; custom cache keys are not required if the default caching mechanism works properly.

BigQueryOperator to run the pipeline as a query.

Why it fails: BigQueryOperator is for SQL queries, not pipeline execution.

PythonOperator with a custom script using the google-cloud-aiplatform library.

Why it fails: While possible, it's not the standard operator and requires manual error handling.

VertexAIPipelineRunOperator (or Airflow's GCSToGCSOperator) for pipeline orchestration.

Why it fails: GCSToGCSOperator is for file transfer, not pipeline runs. The correct operator is VertexAIPipelineRunOperator.