PMLE Automating and Orchestrating ML Pipelines Practice Question

An ML engineer is authoring a Vertex AI pipeline where a custom training component must read a dataset from a BigQuery table and write the trained model to a Cloud Storage bucket. The engineer wants the component to be reusable across projects and environments without hardcoding project IDs or bucket names. Which design should the engineer use?

⚠ Common exam trap

The trap here is thinking that relying on default credentials and default project inside a component is equivalent to passing explicit inputs, when implicit defaults make the component environment-dependent.

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

✓

Pass the BigQuery table URI and the Cloud Storage output URI as component input parameters, and let the pipeline caller supply them at runtime.

Component reusability in Vertex AI Pipelines comes from parameterizing all environment-specific values as inputs. Passing the BigQuery table URI and Cloud Storage output URI as component inputs lets the same component definition run in any project or environment, with the pipeline caller providing concrete values. The other options embed environment-specific values in the container or rely on implicit defaults, which breaks portability and can cause cross-environment mistakes.

Answer analysis

Option-by-option breakdown

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

✗
Use the Vertex AI SDK's aiplatform.init() with no arguments inside the component and rely on the default project and bucket.
Why it's wrong here
Calling aiplatform.init() with no arguments inside a pipeline component relies on the execution environment's default credentials and project, which are not guaranteed to match the caller's intended project. This creates hidden coupling and makes the component behave differently depending on where it runs, violating the reusability requirement.
✗
Read the project ID and bucket name from environment variables set inside the component's container image at build time.
Why it's wrong here
Baking environment variables into the container image at build time hardcodes environment-specific values into the image, so the component is no longer portable across projects. It also makes the component's behavior opaque to the pipeline author and prevents the same image from being reused in dev, staging, and production without rebuilding.
✗
Hardcode the production project ID and bucket name in the component, then override them with a pipeline-level parameter only when running in non-production.
Why it's wrong here
Hardcoding production values as defaults still embeds environment-specific assumptions in the component and risks accidentally writing to production from a dev run if the override is forgotten. A reusable component should have no baked-in project or bucket defaults; all environment-specific values belong in pipeline inputs.
✓
Pass the BigQuery table URI and the Cloud Storage output URI as component input parameters, and let the pipeline caller supply them at runtime.
Why this is correct
Making the dataset URI and output URI component inputs parameterizes the component so the same definition can be reused across projects and environments. The pipeline caller supplies the concrete values at runtime, which is the standard Vertex AI Pipelines pattern for portability. Hardcoding or deriving them inside the component would tie the component to one project and defeat reusability.

Go deeper

PMLE Automating and Orchestrating ML Pipelines Practice Question

Why each option matters

Option-by-option breakdown

Related to this question