Vertex AI Pipelines show up on the Professional Cloud Architect exam in scenarios that involve automating the machine learning workflow, and the structure that powers them is a directed acyclic graph, or DAG. I want to walk through what an ML pipeline is, what makes Vertex AI Pipelines a DAG, and how retraining fits into a model that does not allow cycles.
An ML pipeline automates the end-to-end machine learning workflow. Instead of running data ingestion, feature engineering, training, evaluation, deployment, and monitoring as separate manual steps, a pipeline ties them together so the whole sequence runs as a single orchestrated process. The payoff is consistency, less time spent on glue work, and fewer chances for human error to slip in between steps.
Pipelines also support flexible trigger criteria. A pipeline can run on a schedule, fire when new data arrives, or kick off automatically when monitoring detects model degradation. That trigger flexibility is part of what makes pipelines useful in production rather than just in a notebook.
The standard simplified picture of an ML pipeline has six stages. Data ingestion pulls in the raw data. Data preparation cleans and transforms it. Development and training builds the model. Model evaluation checks whether the model meets quality thresholds. Model deployment pushes it to a serving endpoint. Model monitoring watches performance in production and feeds back into either retraining on the same data or retraining on new data when drift appears.
That picture is intentionally simplified. In reality, a production pipeline can have many more steps with branching and conditional logic, and some steps invoke external dependencies that have nothing to do with the ML artifacts directly.
Vertex AI Pipelines structures these workflows as directed acyclic graphs. The three words each carry weight, and the exam expects you to know what they mean.
Directed means the arrows between steps go one way. They are not bidirectional. Step A feeds into step B, and there is no implicit path back from B to A within the same run.
Acyclic means there are no loops or circular dependencies. You cannot have a step that points back to an earlier step in the same pipeline execution.
Graph means the structure is a collection of nodes connected by edges. In Vertex AI terminology, the nodes are called components and represent each step in the pipeline. The edges are the arrows that define the relationships and execution order between components.
To see why DAGs matter, consider a customer churn prediction pipeline. The first component extracts customer data. From there, the pipeline validates the schema to confirm the data has the expected structure, calculates features, and splits the dataset into training, validation, and test sets. Already the steps are more specific than the broad categories in the simplified picture.
The modeling phase tunes hyperparameters first to find the optimal settings, then trains an XGBoost model using those parameters, then computes metrics like AUC, precision, and recall. Conditional logic enters at the check model quality step. If AUC is below 0.75, the pipeline sends a failure alert to the ML team. If AUC is at or above 0.75, the pipeline uploads the model to the model registry and deploys it to an endpoint.
This kind of conditional branching is part of why DAGs are powerful. A real pipeline can have many branches with logic that is more complex than a single threshold check. The DAG abstraction lets you encode the decisions you would normally make manually about a model and automate the entire process around them.
The natural follow-up question is how retraining is possible if cycles are not allowed. The simplified ML lifecycle picture literally shows two cycles, one for retraining on the same data and one for retraining on new data after drift. So how does that reconcile with the acyclic property?
The answer is that retraining cycles and triggers happen at the orchestration level, not within the DAG structure itself. Each individual pipeline execution remains acyclic. When model monitoring detects data drift or performance degradation, it does not loop back inside the same pipeline run. It triggers a completely new pipeline execution.
Concretely, the churn prediction pipeline might run successfully on Monday as DAG Run 1. On Friday, monitoring detects that customer behavior patterns have shifted significantly. That triggers DAG Run 2 with fresh data, but it is an entirely separate execution that starts from data ingestion again. The pipeline definition is reused, but the run is new, often with different parameters like updated date ranges, new data sources, or incremented version numbers. Vertex AI handles these triggers through scheduled runs, event-driven triggers via Cloud Run Functions, or Pub/Sub messages when new data arrives.
So while the conceptual ML lifecycle looks cyclical, the implementation maintains the acyclic property within each run. That is what allows Vertex AI to optimize execution order and guarantee that pipelines complete successfully without getting stuck in a loop.
For the Professional Cloud Architect exam, the pattern to internalize is this. ML pipelines automate the full ML workflow with consistent, repeatable runs. Vertex AI Pipelines are structured as DAGs, where directed means one-way arrows, acyclic means no loops, and graph means nodes connected by edges. Retraining and ongoing model updates are not violations of the acyclic property because they happen at the orchestration level as new DAG runs, not as cycles within a single execution.
If a scenario describes automating a multi-step ML workflow with conditional logic and branching, Vertex AI Pipelines is the answer. If the question presses on how retraining fits into a system that does not allow cycles, the answer is that each run is its own acyclic execution and retraining is a separate run triggered by monitoring, scheduling, or events.
My Professional Cloud Architect course covers Vertex AI Pipelines and DAGs alongside the rest of the ML and AI material.
