A data science team uses BigQuery to store raw data and Vertex AI for model training. They want to ensure that only authorized users can access training data, and that model artifacts are automatically versioned and tracked. Which combination of Google Cloud services should they use?
Trap 1: Dataflow for data access control and Vertex AI Experiments for…
Dataflow is a streaming and batch data-processing service, not an access-control mechanism, and Vertex AI Experiments tracks training runs rather than versioning model artifacts. It is tempting because both are Vertex-adjacent analytics tools, and would be correct for pipeline transformation plus experiment comparison, not IAM authorisation and artifact lineage.
Trap 2: Cloud Storage with bucket-level IAM and Cloud Build for versioning
Bucket-level IAM governs Cloud Storage objects, not BigQuery table access, and Cloud Build is a CI/CD service that does not version model artifacts in the registry. It is tempting because both are common GCP building blocks, and would be correct if training data lived in Cloud Storage and versioning meant container image builds.
Trap 3: Cloud Composer for data access control and Cloud Source…
Cloud Composer orchestrates workflows and does not enforce data access, while Cloud Source Repositories versions source code, not model artifacts. It is tempting because both are pipeline-adjacent services, and would be correct for scheduling training DAGs and tracking notebook or code revisions rather than authorising BigQuery data and registering models.
- A
Dataflow for data access control and Vertex AI Experiments for model tracking
Why it fails: Dataflow is a streaming and batch data-processing service, not an access-control mechanism, and Vertex AI Experiments tracks training runs rather than versioning model artifacts. It is tempting because both are Vertex-adjacent analytics tools, and would be correct for pipeline transformation plus experiment comparison, not IAM authorisation and artifact lineage.
- B
Cloud Storage with bucket-level IAM and Cloud Build for versioning
Why it fails: Bucket-level IAM governs Cloud Storage objects, not BigQuery table access, and Cloud Build is a CI/CD service that does not version model artifacts in the registry. It is tempting because both are common GCP building blocks, and would be correct if training data lived in Cloud Storage and versioning meant container image builds.
- C
Cloud Composer for data access control and Cloud Source Repositories for model versioning
Why it fails: Cloud Composer orchestrates workflows and does not enforce data access, while Cloud Source Repositories versions source code, not model artifacts. It is tempting because both are pipeline-adjacent services, and would be correct for scheduling training DAGs and tracking notebook or code revisions rather than authorising BigQuery data and registering models.
- D
Vertex AI Feature Store with access control and Vertex AI ML Metadata for model versioning
Vertex AI Feature Store enforces IAM access control at the feature view level, restricting training data to authorised users, while Vertex AI ML Metadata automatically records artifacts, parameters and lineage for each pipeline run, satisfying the versioning and tracking requirement. Together they address both the access and artefact-tracking constraints in the stem.