Professional Cloud Security Engineer

Protecting sensitive data and preventing data loss

Cloud Data Loss Prevention (DLP) is the primary service for inspecting, classifying, and de-identifying sensitive data across Google Cloud. The service scans data at rest in Cloud Storage, BigQuery, and Datastore, as well as data in motion through Pub/Sub or streaming pipelines. When DLP finds a match against a built-in or custom infoType—such as a credit card number or a passport ID—it can apply a transformation like masking, tokenization, or redaction before the data is stored or sent further. The inspection job runs on a schedule or on demand, and the results are written to a BigQuery table or a Cloud Storage bucket so that security teams can audit where sensitive data lives.

Preventing data loss also depends on VPC Service Controls, which create a security perimeter around managed services. When a perimeter is in place, data cannot be copied from a protected service to a resource outside the perimeter, even if the user has valid credentials. This boundary stops exfiltration that would otherwise bypass IAM permissions. Cloud Audit Logs record every data access event, and Organization Policies can enforce rules such as preventing public access to Cloud Storage buckets or requiring that all BigQuery datasets have a default expiration. Together, these controls give an organization a layered defense: DLP finds and transforms sensitive content, VPC Service Controls block unauthorized movement, and logging provides visibility for incident response.

Managing encryption at rest, in transit, and in use

Google Cloud encrypts data at rest by default using Google-managed encryption keys. For customers who need more control, Cloud Key Management Service (Cloud KMS) lets you create and manage your own keys, known as customer-managed encryption keys (CMEK). When you use CMEK, the key is stored in Cloud KMS and is used to wrap the data encryption keys that actually encrypt your data. You can rotate keys on a schedule, disable them, or set a destruction delay so that a key cannot be deleted immediately. For the highest level of control, customer-supplied encryption keys (CSEK) allow you to bring your own key material, though CSEK is limited to a few services such as Compute Engine and Cloud Storage.

Encryption in transit is handled by TLS for all external traffic and by application-layer encryption for traffic between Google services. When two Google Cloud services communicate within the same zone or region, traffic is encrypted at the network layer by default. For workloads that require encryption of data while it is being processed—in use—Google Cloud offers Confidential VMs and Confidential GKE Nodes. These use AMD SEV (Secure Encrypted Virtualization) to encrypt memory in use. The CPU decrypts data only inside the processor, so even the hypervisor cannot read the memory. The trust boundary shifts: the customer controls the encryption keys for the VM’s memory, and the cloud provider cannot access the plaintext data. This is especially important for workloads that handle regulated data or intellectual property.

Securing AI workloads

AI workloads introduce unique data protection challenges because models are trained on large datasets and can inadvertently memorize sensitive information. Vertex AI provides a managed environment where you can control access to training data, models, and predictions. IAM roles such as aiplatform.user and aiplatform.customCodeServiceAgent limit who can create, deploy, or invoke models. VPC Service Controls can be applied to Vertex AI to prevent data from leaving a defined perimeter during training or inference.

For sensitive training data, use Cloud DLP to de-identify the dataset before it is ingested. This removes or masks personally identifiable information (PII) so that the model never sees the raw sensitive values. During training, Confidential VMs can encrypt the memory of the compute nodes, protecting the intermediate weights and gradients from exposure. After training, the model artifact itself can be encrypted at rest with Cloud KMS and stored in a Cloud Storage bucket that has uniform bucket-level access and a retention policy. When the model serves predictions, Cloud Armor can block malicious requests, and Cloud Audit Logs record every API call to Vertex AI. The overall flow is: de-identify the source data, train inside a confidential environment, encrypt the model at rest, and monitor all access with audit logs.