Professional Cloud Security Engineer

Configuring Sensitive Data Protection

Discovery, Inspection, and Redaction

Sensitive Data Protection scans structured and unstructured storage locations to identify sensitive elements such as personally identifiable information (PII). The inspection engine evaluates data against predefined detectors called infoTypes, which recognize common patterns such as credit card numbers, national identification numbers, and email addresses. Organizations can also create custom infoTypes using regular expressions or dictionary lists to locate internal identifiers like employee badges or proprietary account codes. When the service finds sensitive data, it can immediately redact the text by masking matching characters or completely removing the sensitive values before downstream systems process the file.

Pseudonymization and Format-Preserving Encryption

When applications require data for analytics without exposing raw personal details, de-identification transforms the records while preserving their analytical utility. Pseudonymization replaces direct identifiers with artificial tokens or cryptographic hashes generated using a secret encryption key and salt. Organizations choose among distinct transformation methods depending on downstream application needs:

• Format-Preserving Encryption (FPE) encrypts data such as sixteen-digit credit card numbers into a ciphertext that retains the original format and length, preventing schema breakage in legacy systems.
• Cryptographic hashing with a salt generates deterministic surrogate values that allow systems to perform join operations across tables without revealing the original identities.
• Bucketing and generalization replaces exact numerical values, such as ages or salaries, with broad ranges to protect individual privacy while maintaining demographic patterns.

---

Restricting Access to Google Cloud Data Services

BigQuery Access Controls

BigQuery enforces fine-grained data governance at the dataset, table, column, and row levels. Administrators apply column-level security by assigning policy tags to sensitive fields, requiring querying users to possess fine-grained reader permissions to view those columns. To restrict records based on user identity, row access policies evaluate conditions against the calling identity using built-in session functions to filter visible rows dynamically. When sharing aggregated analytical results without granting direct table access, teams use authorized views or authorized datasets, which query underlying data on behalf of an analyst without exposing the base tables.

Cloud Storage Security Boundaries

Cloud Storage secures unstructured objects through identity policies, perimeter controls, and key management. Enabling Uniform bucket-level access disables legacy access control lists (ACLs) and unifies permissions under standard Identity and Access Management (IAM) policies across all objects in a bucket. To protect against unauthorized external transfers, VPC Service Controls establish a secure network perimeter that blocks data exfiltration to unauthorized storage destinations. For data encryption, storage buckets can use default Google-managed keys, or administrators can enforce Customer-Managed Encryption Keys (CMEK) managed in Cloud Key Management Service (Cloud KMS) to retain revocation control.

Cloud SQL Network and Identity Controls

Cloud SQL restricts database connections by enforcing network isolation and identity verification. Setting up instances with private IP allows instances to communicate exclusively within a Virtual Private Cloud (VPC) through private services access, eliminating exposure to the public internet. Applications connecting from external or hybrid networks use the Cloud SQL Auth Proxy, which automatically establishes an encrypted mutual TLS tunnel and authenticates clients using IAM credentials rather than static database passwords. Database administrators also restrict administrative privileges by granting specific Cloud SQL IAM roles and configuring CMEK to govern underlying database storage disks.

---

Securing Secrets with Secret Manager

Secret Access and Lifecycle Management

Secret Manager provides centralized, encrypted storage for API keys, passwords, and certificates. Each secret holds one or more immutable secret versions that move through distinct lifecycle states: enabled, disabled, or destroyed. Applications authenticate using service accounts granted the Secret Manager Secret Accessor role, retrieving the secret payload directly into memory at runtime over private API channels. Administrators manage administrative tasks—such as creating new versions or updating IAM bindings—using separate administrative roles, enforcing a strict separation of duties between operators and consumers.

Automated Secret Rotation

To minimize the exposure window of compromised credentials, Secret Manager integrates with event-driven services to automate rotation schedules. When a rotation period elapses, Secret Manager publishes an event notification to a Cloud Pub/Sub topic. This notification triggers a serverless handler, such as a Cloud Function or Cloud Run service, which generates a new credential inside the target system and adds it as a new secret version. Once the consuming application retrieves the updated secret version, the automation workflow updates the old version to a disabled state before eventual destruction.

---

Protecting and Managing Compute Instance Metadata

Metadata Server Protection

The Compute Engine metadata server supplies configuration data, startup scripts, and temporary OAuth tokens to running virtual machines. To prevent Server-Side Request Forgery (SSRF) attacks from stealing tokens, applications must query the v1 metadata endpoint with the HTTP header Metadata-Flavor: Google. Organizations disable legacy, unauthenticated endpoints across projects by setting the metadata value disable-legacy-endpoints=true. For containerized workloads on Google Kubernetes Engine (GKE), Workload Identity intercepts requests to the metadata server and replaces shared node credentials with short-lived tokens tied specifically to Kubernetes service accounts.

SSH Keys and Instance Access

Managing administrative login credentials on virtual machines requires centralizing access to prevent orphaned keys. OS Login links SSH access directly to a user's corporate identity and IAM roles, eliminating the need to manage individual, project-wide public SSH keys. When users log in, the OS Login service checks project permissions, validates multi-factor authentication requirements, and generates short-lived authorization certificates. Disabling project-wide SSH keys ensures that all shell access flows through this centrally audited identity boundary rather than static local configurations.