A financial enterprise is designing an end-to-end machine learning pipeline on Google Cloud. The pipeline ingests sensitive customer records into Cloud Storage, processes structured feature data in BigQuery and Vertex AI Feature Store, and runs automated Vertex AI Training Pipelines to publish model artifacts to the Vertex AI Model Registry. The security team mandates the following security and governance requirements: Cryptographic Control: All storage and training resources containing or processing sensitive data (BigQuery datasets/tables, Vertex AI Feature Store, training pipelines, and Model Registry artifacts) must be encrypted using customer-managed encryption keys (CMEK) managed in Cloud KMS. Access Separation: Data scientists must develop and trigger training jobs without having direct read permissions to raw sensitive data residing in the dedicated data storage project. Sensitive Data Governance: Continuous discovery and profiling must be implemented across ML data repositories to identify sensitive data and prevent unauthorized public exposure. Which architectural approach satisfies these security requirements?

Separate data storage and Vertex AI compute into distinct projects; configure CMEK encryption across BigQuery datasets, Cloud Storage buckets, Vertex AI Feature Store, training pipelines, and Model Registry; assign custom service accounts to training pipelines with least-privilege IAM permissions to read storage project data; and enable Sensitive Data Protection profiling.: ### What the Recommended Architecture Is This architecture establishes an enterprise-grade, defense-in-depth security framework for machine learning systems on Google Cloud by decoupling compute and storage into separate projects, enforcing full-lifecycle **Customer-Managed Encryption Keys (CMEK)**, delegating execution access using dedicated custom service accounts, and enforcing continuous data discovery through **Sensitive Data Protection**. ### How It Meets the Requirements - **Cryptographic Control via CMEK**: CMEK is applied across all data and model storage components—including **Cloud Storage**, **BigQuery datasets/tables**, **Vertex AI Feature Store**, **Vertex AI Training Pipelines**, and **Vertex AI Models** in the Model Registry. This gives the security team cryptographic control over data at rest and allows immediate revocation of access via **Cloud Key Management Service (Cloud KMS)**. - **Access Separation via Decoupled Projects**: By maintaining sensitive datasets in a dedicated data project and ML workloads in a separate compute project, data scientists do not need direct `roles/storage.objectViewer` or `roles/bigquery.dataViewer` permissions on the raw data. Instead, training jobs execute under a **custom service account** that is granted least-privilege read access strictly to the required storage and BigQuery resources in the data project. - **Sensitive Data Governance**: Enabling **Sensitive Data Protection** (Cloud DLP API) facilitates automated discovery and profiling of datasets and storage buckets, surfacing sensitive infoTypes and helping remediate risky access configurations. ### Key Advantages and Capabilities - **Granular Least Privilege**: Prevents human data scientists from interacting directly with raw PII while permitting automated training workflows to run securely. - **End-to-End Cryptographic Governance**: Guarantees that neither training artifacts, cached metadata, nor feature stores exist in cleartext under standard Google-managed keys. - **Clear Auditability and Separation of Duties**: Isolates data tier administration from ML engineering workspaces and tracks key operations via Cloud Audit Logs. ### Why This Is Optimal This solution follows Google Cloud security best practices for AI/ML workloads by combining structural project isolation, cryptographic controls with **Cloud KMS**, programmatic identity delegation with custom service accounts, and data profiling with **Sensitive Data Protection**.