Select Two (Multi-Select) Questions

Use full fine-tuning of all model parameters

Why it fails: Full fine-tuning is computationally expensive and not cost-minimizing.

Use TPU v4 pods for training

Why it fails: TPUs are powerful but typically more expensive than GPU spot instances for fine-tuning; not a cost-minimization strategy.

The analyst must call ML.TRAIN after CREATE MODEL to start training

Why it fails: CREATE MODEL itself triggers and completes training synchronously, so no separate ML.TRAIN call exists in BigQuery ML. The tempting confusion arises from frameworks where fitting is a distinct step after defining architecture; here the CREATE MODEL statement with the OPTIONS clause performs both definition and training in one query.

The trained model is stored in Cloud Storage

Why it fails: BigQuery ML stores trained models as objects inside a BigQuery dataset, addressable via ML.PREDICT and the model resource name, not in Cloud Storage. Cloud Storage holds exported model artefacts or training data; it would be the destination only if the analyst explicitly ran ML.EXPORT_MODEL to serve the model elsewhere.

The model must be exported to Vertex AI for prediction

Why it fails: BigQuery ML serves predictions directly from the trained model using ML.PREDICT, so exporting to Vertex AI is not required. It is tempting because Vertex AI hosts custom models, and export is correct when deploying outside BigQuery or serving at scale.

A manual QA step where data scientists approve each deployment.

Why it fails: Manual approval gates deployments on human availability, so weekly retraining cannot run unattended; drift and performance monitoring need automated triggers instead. It is tempting because human sign-off suits regulated, low-frequency releases where auditability outweighs cadence, not scheduled weekly pipelines.

A manual review of new data before it is used for training.

Why it fails: Manual review adds human latency and does not scale to weekly retraining, and it provides no drift or performance monitoring. It is tempting where regulatory approval of training data is mandatory, but automated pipelines with Vertex AI Pipelines and Model Monitoring satisfy this scenario.

Share a service account key with all team members so they can access the same resources.

Why it fails: A shared service account key is a long-lived credential that cannot attribute runs to individuals and is not a reproducibility mechanism for code, data or environment. It is tempting because it grants uniform resource access quickly, which suits short-lived demos, but Vertex AI Experiments reproducibility requires versioned datasets, containers and tracked parameters.

Use Vertex AI's hyperparameter tuning job to automatically find the best parameters.

Why it fails: Hyperparameter tuning searches for optimal parameters within a single experiment; it neither versions the code, data or environment nor records them for replay. It is tempting because tuning jobs appear in Vertex AI Experiments, but reproducibility demands logged artefacts and parameters, not automated parameter search.

Keep all pipeline logic in a single large DAG for simplicity.

Why it fails: Large DAGs are difficult to collaborate on and test.

Embed service account keys directly in DAG code for authentication.

Why it fails: Security risk; use Workload Identity or environment variables.

Eliminate all features that are correlated with protected attributes from the model input to ensure fairness.

Why it fails: Simply removing correlated features is not sufficient and may harm model performance; fairness should be evaluated directly.

Periodically compare the model's performance metrics (e.g., AUC) on the overall population versus the holdout test set.

Why it fails: Comparing overall performance does not reveal per-group disparities.

Store all model predictions in BigQuery but do not capture ground truth labels to avoid privacy issues.

Why it fails: Without ground truth labels, you cannot compute fairness metrics like equal opportunity or demographic parity.

Compute engine CPU and memory logs for each pipeline step.

Why it fails: Pipeline-step CPU and memory metrics describe the underlying Compute Engine VMs, not the ML workflow itself. Vertex AI Pipelines exposes task-level execution metadata, artefacts, and lineage; the dashboard needs those pipeline-run signals. Host metrics would be the right choice when diagnosing infrastructure saturation on self-managed training VMs.

Online prediction latency and request count from the deployed model endpoint.

Why it fails: The pipeline covers training, evaluation, and batch prediction, so endpoint request metrics sit outside its scope — no deployed online endpoint is involved. Online latency and request counts belong on a dashboard for a real-time prediction service, where traffic volume and tail latency drive autoscaling and SLO alerting.

Use a single large batch size across all workers.

Why it fails: One global batch size cannot be split across workers without partitioning; each worker needs its own per-device batch, with gradients synchronised each step. It is tempting because large batches do improve throughput on a single GPU, so it would be right when tuning one device's memory and convergence rather than scaling across many.

Use asynchronous gradient updates to reduce communication overhead.

Why it fails: Asynchronous updates let workers proceed on stale gradients, which harms convergence and reproducibility; synchronous all-reduce is what keeps replicas consistent. It is tempting because async does cut communication stalls, so it would be correct for latency-tolerant parameter-server setups, not for tightly coupled multi-GPU training needing stable accuracy.

Use Cloud Functions to retrain the model each time a build completes

Why it fails: Cloud Functions cannot natively orchestrate Vertex AI training pipelines; Cloud Build steps or Vertex AI Pipelines trigger training directly on commit. Cloud Functions suits lightweight event-driven glue, such as reacting to a Pub/Sub message, not managing multi-step ML workflows with dependency tracking and artefact lineage.

Set up a Cloud Scheduler job to poll for new build artifacts

Why it fails: Polling for build artefacts introduces latency and wasted invocations; Cloud Build publishes build events to Pub/Sub, which triggers the pipeline immediately. Cloud Scheduler suits fixed-time batch jobs, such as nightly data exports, not event-driven ML retraining where each successful build must kick off training without delay.

dsl.PipelineParam

Why it fails: dsl.PipelineParam passes a single value into a pipeline run; it cannot fan out work across shards. It is tempting because parameterising pipelines is genuinely useful for reusable, configurable workflows, but parallel per-shard execution requires dsl.ParallelFor to iterate the shard list and spawn concurrent tasks.

dsl.Condition

Why it fails: dsl.Condition branches on a boolean predicate, executing one path or another; it cannot iterate a shard collection to launch concurrent tasks. It is tempting because conditional branching is genuinely useful for optional pipeline steps, but the scenario needs dsl.ParallelFor to fan out identical preprocessing tasks across every shard.

dsl.ExitHandler

Why it fails: dsl.ExitHandler runs a cleanup or notification task after a pipeline scope completes or fails; it does not iterate shards or spawn parallel tasks. It is tempting because exit handlers are genuinely useful for teardown and error notification, but per-shard parallelism requires dsl.ParallelFor to iterate the shard list.

AutoML Vision

Why it fails: AutoML Vision classifies or detects objects in still images, but it does not track movement across video frames over time. It is tempting because it is a custom vision model, and it would be correct for image labelling or single-frame detection, not for temporal tracking in video.

Speech-to-Text

Why it fails: Speech-to-Text transcribes spoken audio into written text; it processes no video frames, so it cannot detect or track objects. It is tempting because it is a media-analysis service, and it would be correct for generating transcripts or subtitles from recorded audio, not for visual object detection and movement tracking.

Natural Language API

Why it fails: Natural Language API analyses text for sentiment, entities and syntax, and cannot process video frames for object detection or tracking. It is tempting because it is a pre-trained ML API, and it would be correct for extracting entities or sentiment from transcripts, not for visual analysis of video content.

Use batch prediction for all requests.

Why it fails: Not suitable for real-time.

Use manual scaling with a fixed number of replicas.

Why it fails: Cannot handle spikes efficiently.

Deploy all models on the same machine type for consistency.

Why it fails: May not match model requirements.

Use a larger pre-trained model as a starting point.

Why it fails: Larger model increases size and latency.

Use half-precision (FP16) instead of INT8.

Why it fails: FP16 still uses 16 bits; INT8 is more aggressive in compression.

Increase the number of layers in the model.

Why it fails: Increases size and latency.

Manually engineer features for each training iteration

Why it fails: Manual feature engineering per iteration does not scale and blocks reproducible retraining pipelines as data volumes grow. It is tempting because hand-crafted features often lift prototype accuracy, and would be correct during early experimentation rather than production scaling.

Run the model on a single high-memory Compute Engine VM

Why it fails: A single high-memory VM caps throughput and offers no horizontal scaling or redundancy, so it cannot absorb production load. It is tempting because large VMs suit memory-bound prototyping, and would be correct for a one-off batch job rather than a scaled service.

Use proprietary libraries to maximize performance regardless of lock-in

Why it fails: Proprietary libraries create lock-in and hinder portability across Google Cloud services and future runtimes. It is tempting because vendor-tuned libraries can squeeze out performance, and would be correct only where measured gains outweigh migration and maintenance constraints.

Pipeline parameters must be serialized to JSON before use.

Why it fails: Kubeflow Pipelines SDK v2 accepts native Python types such as int, float, bool, list and dict directly, serialising them internally; manual JSON encoding is unnecessary. It is tempting because parameters are stored as JSON in the IR YAML, and would be correct only when constructing that IR by hand.

Pipeline parameters can only be of type str.

Why it fails: Parameters support int, float, bool, list and dict as well as str, so restricting them to strings is false. It is tempting because command-line arguments are strings, and would be correct if the question concerned passing values to a container entrypoint rather than declaring pipeline parameters.

Pipeline parameters can be used to pass large datasets between components.

Why it fails: Parameters carry small scalar configuration values, not bulk data; large artefacts move between components via URI references to Cloud Storage or Artifact Registry. It is tempting because parameters do flow between components, and would be correct for passing a path or dataset identifier rather than the dataset itself.

Increase the memory of the evaluation step's machine.

Why it fails: Premature fix without knowing if memory is the issue.

Replace the evaluation step with a Vertex AI Model Evaluation service.

Why it fails: Changes the process instead of diagnosing the current failure.

Use a larger machine type with more memory

Why it fails: Adding memory does not reduce inference latency; the bottleneck is usually compute, model size or request concurrency, and larger machines can even add cold-start delay. Bigger machine types suit memory-bound or high-throughput workloads, but latency reduction comes from optimised runtimes, accelerators or autoscaling.

Use batch prediction instead of online prediction

Why it fails: Batch prediction processes stored data asynchronously and returns results to a destination, so it does not serve interactive requests at all; latency is measured differently and often higher. Batch prediction is the right choice for large offline scoring jobs, not for reducing online endpoint response times.

Enable model caching at the endpoint

Why it fails: Vertex AI Endpoints provide no endpoint-level model caching feature; caching must be implemented in application code or a serving layer. Response caching is genuinely valuable for repeated identical queries, but it is not a configurable Vertex AI endpoint capability, so it cannot be the stated best practice.

The programming language used for training

Why it fails: Training language is irrelevant to serving inference; the serving framework, latency, throughput and accelerator requirements govern the compute choice. It is tempting because the training stack does constrain reproducibility, and would be correct when selecting a training platform rather than a production inference option.

The color of the team's logo

Why it fails: Logo colour has no bearing on compute selection; the factors are workload characteristics such as latency, throughput, GPU/TPU requirements and cost. It is tempting because team branding matters for dashboards and documentation, but that is a presentation concern, not a serving-infrastructure decision.

Cloud Logging

Why it fails: Cloud Logging records and queries log entries; it neither orchestrates retraining nor calculates training-serving skew. It tempts because pipeline components emit logs, and would be correct for auditing or troubleshooting runs, not for the pipeline and skew-detection services themselves.

Cloud Functions

Why it fails: Cloud Functions runs short event-driven code, not the managed pipeline that schedules retraining or computes training-serving skew metrics. It tempts because it can trigger workflows on new data, and would be correct for lightweight glue logic, not for orchestrating training and skew detection.

Cloud Monitoring

Why it fails: Cloud Monitoring tracks operational metrics and alerts, but does not orchestrate training pipelines or compute feature distribution skew. It tempts because skew metrics can be charted there, and would be correct for alerting on infrastructure health rather than detecting training-serving skew within the pipeline.

Using Vertex AI Vizier to optimize the model parallelism strategy

Why it fails: Vizier is for hyperparameter tuning, not for configuring parallelism.

Enabling Vertex AI AutoML to automatically distribute the model

Why it fails: AutoML is for automated model building, not for custom distributed training.