PMLE Automating and Orchestrating ML Pipelines Practice Question

An ML engineer is authoring a Vertex AI Pipelines component that runs a custom Python script. The component must accept a GCS path to training data and output a model artifact. The engineer wants the component interface to be strongly typed and to automatically generate the component specification from the Python function. Which approach should the engineer use?

⚠ Common exam trap

The trap here is assuming that any decorator or containerization automatically generates a typed component interface, when only the KFP v2 @dsl.component decorator does so from annotations.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Define the component using the @dsl.component decorator from the kfp package, annotating the function parameters with types like str and Output[Model].

The Kubeflow Pipelines SDK v2 @dsl.component decorator introspects Python type annotations to build a component specification, including input and output artifacts. This provides strong typing and automatic generation, which is exactly what the engineer needs. Other approaches either require manual YAML definition or are intended for different use cases like custom training jobs.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Define the component using the @component decorator from the google.cloud.aiplatform.v1alpha1 package, specifying the input and output types as function annotations.
Why it's wrong here
This decorator exists but is part of the legacy Kubeflow Pipelines SDK v1. It does not automatically generate a component spec from type annotations in the same way as the v2 SDK, and it is not the recommended approach for new Vertex AI Pipelines components. The engineer would need to manually define the component YAML, which is error-prone.
✗
Use the google.cloud.aiplatform.CustomContainerTrainingJob class to package the script and run it as a pipeline step.
Why it's wrong here
CustomContainerTrainingJob is designed for training a model on Vertex AI, not for defining a reusable pipeline component. It does not provide the same component interface typing or automatic spec generation. Using it inside a pipeline would require additional wrapping and would not meet the strong typing requirement.
✗
Write a Dockerfile that installs the required dependencies and exposes the script as an entrypoint, then build and push the image to Artifact Registry.
Why it's wrong here
Building a custom container image is a valid way to create a component, but it does not automatically generate a component specification from the Python function's interface. The engineer would still need to define the component YAML or use a loader. This approach adds unnecessary complexity for a simple Python script.
✓
Define the component using the @dsl.component decorator from the kfp package, annotating the function parameters with types like str and Output[Model].
Why this is correct
The kfp.dsl.component decorator (Kubeflow Pipelines SDK v2) generates a component specification from the Python function's type annotations. It supports InputPath, OutputPath, and artifact types like Model, ensuring strong typing. This is the standard method for authoring lightweight Python components in Vertex AI Pipelines.

Go deeper

PMLE Automating and Orchestrating ML Pipelines Practice Question

Why each option matters

Option-by-option breakdown

Related to this question