PMLE Automating and Orchestrating ML Pipelines Practice Question

An ML engineer is running a Vertex AI pipeline that includes a data validation component and a training component. The engineer wants the pipeline to stop before training if data validation fails, but wants the validation component to record its result as an output artifact for later inspection. Which combination of pipeline features should the engineer use?

⚠ Common exam trap

The trap here is assuming that a failed component cannot produce artifacts, when artifacts written before the exception are still persisted and available for inspection.

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

✓

Have the validation component raise an exception on failure and write a validation report artifact before raising.

In Vertex AI Pipelines, a task that raises an exception fails, and dependent tasks are not executed. Writing the validation report artifact before raising ensures the artifact is captured for later inspection. The other options either let training proceed, rely on retries that do not address deterministic data failures, or move the validation check into the training component, none of which stop the pipeline before training while preserving the report.

Answer analysis

Option-by-option breakdown

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

✗
Configure the validation component with a retry policy of 3 so transient validation errors are retried, then let training proceed.
Why it's wrong here
Retries are for transient infrastructure or service errors, not for data validation failures, which are deterministic. Retrying a failed validation three times wastes time and, more importantly, does not stop training if the validation ultimately succeeds on a retry that should not have been attempted. The engineer wants training to be blocked on validation failure.
✗
Use a dsl.Condition to skip training when validation fails, and have the validation component always succeed while writing the report.
Why it's wrong here
Using dsl.Condition to skip training keeps the pipeline in a succeeded state, which may be undesirable when validation fails and the engineer wants a clear failure signal. It also requires encoding the failure logic in the pipeline rather than the component. The requirement is to stop before training, which a condition can do, but the engineer also wants the pipeline to reflect the validation failure, making an exception the cleaner signal.
✗
Have the validation component write the report artifact and return a success status, then check the artifact contents in the training component before training.
Why it's wrong here
Pushing the validation check into the training component couples training to validation logic and means the pipeline does not stop before training starts; the training component itself must run to perform the check. This defeats the purpose of gating training on validation and makes the pipeline graph less clear.
✓
Have the validation component raise an exception on failure and write a validation report artifact before raising.
Why this is correct
Raising an exception causes the pipeline task to fail, which stops downstream training tasks because they depend on the validation task. Writing the validation report artifact before raising ensures the artifact is persisted and available for inspection even though the task failed. This combination satisfies both the stop-before-training and record-for-inspection requirements.

Go deeper

PMLE Automating and Orchestrating ML Pipelines Practice Question

Why each option matters

Option-by-option breakdown

Related to this question