How can you speed up Kubeflow Pipelines runs without extra cost?
Short answer
B Enable caching in all the steps of the Kubeflow pipeline.
Question
Key Takeaways
The question tests the concept of pipeline step caching: a step is skipped if its inputs and code have not changed, so only modified steps (like new feature engineering or training versions) are re-run; the trap is mistaking other optimizations like BigQuery delegation or GPU addition for direct, cost-free speedups.
For speeding up Kubeflow Pipelines development when iterating on multiple versions, enabling step caching is the community-endorsed answer; it reuses outputs of unchanged steps across runs, reducing execution time and avoiding additional compute costs.
Common mistake: Choosing C (Delegate feature engineering to BigQuery) is the most likely wrong answer because it appears to reduce pipeline work; however, it changes the end-to-end design and does not reuse already-computed training or evaluation steps, while caching directly addresses redundant execution of unchanged steps.
Expert Analysis
Why the Answer Is Correct
B is correct because Kubeflow Pipelines caching lets you reuse the outputs of steps whose code and inputs have not changed. In this scenario, you are modifying only feature engineering and model training versions, but other steps like data loading, evaluation, and deployment may be identical; caching those unchanged steps cuts the per-run time dramatically. One commenter noted that 'different version of feature engineering and model training' means caching helps reuse results from previous runs, and it avoids the extra cost of recomputing unchanged stages. Another commenter added that caching directly addresses redundant computations, especially for frequently used feature engineering versions, while still maintaining an end-to-end KFP workflow.
Why the Other Options Are Wrong
A (Comment out the part of the pipeline you are not updating) is manual and error-prone; it weakens the end-to-end pipeline and still requires rerunning the remaining steps, and the commented-out parts are not tested automatically. C (Delegate feature engineering to BigQuery) changes the architecture and may be a good optimization in some systems, but it does not address repeated executions of model training or evaluation, and it violates the stated 'end-to-end' pipeline requirement. D (Add a GPU to the model training step) could speed up training but incurs additional cost, directly contradicting the requirement to 'avoid additional costs' and does nothing for feature engineering or other unchanged stages.
Community Comment Notes
The top comment (7 likes) chose B and also correctly rejected C by pointing out that delegating feature engineering to BigQuery breaks the 'end-to-end' MLOps pipeline requirement. A second comment expanded on B, explaining that caching avoids redundant computation for unchanged versions, which is the key idea. One lower-liked comment answered C, likely because moving feature engineering to BigQuery seems like a natural performance optimization; however, the consensus clearly favors B because caching is the only option that both speeds up runs and avoids extra cost without changing the pipeline architecture.
Official Reference
- https://www.kubeflow.org/docs/components/pipelines/caching/
- https://cloud.google.com/vertex-ai/docs/pipelines/configure-caching
These links open the official vendor documentation in a new tab.
Exam Strategy
When asked about speeding up pipeline runs without extra cost, look for an answer that reuses previous work, such as caching. Remember that Kubernetes or Kubeflow step caching skips a step only when its code and inputs are unchanged, so during development you can iterate on one step while all other steps are reused from prior runs.
Community Votes
100% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.
Discussion 3 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.
From public community threads 3
-
Yan_X 👍 7 Answered BB 'Different version of feature engineering and model training', so enable cache can help to reuse results of previous run. Guess not be C, as it mentioned 'end-to-end' MLOps, if delegate to BigQuery, it is not 'end-to-end' now.
-
omermahgoub 👍 1B, and here's why: 1. Caching directly addresses the issue of redundant computations, especially for frequently used feature engineering versions 2. End-to-End" MLOps, Kubeflow Pipelines handle all stages, including feature engineering, maintaining your desired "end-to-end" workflow.
-
JG123 👍 1Answer is C
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.
Related Analysis
Practice All PMLE Questions
Access 65 questions with complete answers and detailed explanations.
View Full PMLE Practice Test →