A multinational financial services institution is migrating a mission-critical payment processing system to Google Cloud. The compliance and security teams mandate a comprehensive, end-to-end data protection strategy that enforces strict data confidentiality across all stages of the data lifecycle: Data in use: Processing in memory must be cryptographically isolated from the underlying hypervisor, host OS, and cloud operator operations via hardware-rooted Trusted Execution Environments (TEEs). Data at rest: All databases, object stores, and persistent disk volumes must be encrypted using customer-controlled keys with automated rotation and hardware security module backing. Data in transit: All communication channels between external clients, ingestion endpoints, and backend services must strictly enforce modern cryptographic ciphers and protocols. Which architecture meets all of these end-to-end data protection requirements?

Deploy the processing workloads on Confidential VM instances utilizing hardware-based memory encryption, enforce TLS 1.2+ using Cloud Load Balancing SSL policies for in-transit traffic, and encrypt all persistent disks and storage using Customer-Managed Encryption Keys (CMEK) backed by Cloud HSM.: ### What the Solution Is This architecture combines **Confidential Computing**, **Customer-Managed Encryption Keys (CMEK)** with **Cloud HSM**, and managed **SSL/TLS Policies** on Cloud Load Balancing to achieve comprehensive cryptographic protection across data at rest, data in transit, and data in use. ### How It Meets All Requirements - **Data in Use**: **Confidential VM** instances leverage hardware-based memory encryption technologies (such as AMD SEV/SEV-SNP or Intel TDX). Memory encryption keys are generated by dedicated on-chip secure processors, residing exclusively within hardware registers inaccessible to Google hypervisors, host OS processes, and administrative interfaces. This establishes a hardware-isolated **Trusted Execution Environment (TEE)**. - **Data at Rest**: Configuring **CMEK** backed by **Cloud HSM** (FIPS 140-2 Level 3 validated hardware security modules) ensures that storage buckets, persistent disks, and database volumes are encrypted with cryptographic keys under the enterprise's direct administrative ownership and rotation policies. - **Data in Transit**: Applying restrictive **SSL policies** to Cloud Load Balancers disables legacy, vulnerable protocols and mandates modern cipher suites (such as TLS 1.2 and TLS 1.3), ensuring transport-layer encryption from client ingestion through internal service boundaries. ### Key Advantages and Capabilities - **Zero-Trust Memory Protection**: Protects active computations and sensitive memory payloads against unauthorized memory inspection, hypervisor vulnerabilities, and physical DRAM probing attacks. - **Cryptographic Control**: CMEK with Cloud HSM provides granular lifecycle control, auditability, and emergency access revocation over data storage encryption keys. - **Defense-in-Depth**: Integrates transport security, hardware TEEs, and storage encryption into a unified, layered security model. ### Why This Is Optimal This solution directly addresses every stage of the data lifecycle without operational blind spots, ensuring data confidentiality is maintained from network transit to persistent storage and active memory execution.

End To End Confidential Computing Data Protection Architecture | Professional Cloud Security Engineer

End To End Confidential Computing Data Protection Architecture

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

A multinational financial services institution is migrating a mission-critical payment processing system to Google Cloud. The compliance and security teams mandate a comprehensive, end-to-end data protection strategy that enforces strict data confidentiality across all stages of the data lifecycle:

Data in use: Processing in memory must be cryptographically isolated from the underlying hypervisor, host OS, and cloud operator operations via hardware-rooted Trusted Execution Environments (TEEs).
Data at rest: All databases, object stores, and persistent disk volumes must be encrypted using customer-controlled keys with automated rotation and hardware security module backing.
Data in transit: All communication channels between external clients, ingestion endpoints, and backend services must strictly enforce modern cryptographic ciphers and protocols.

Which architecture meets all of these end-to-end data protection requirements?

Deploy standard Compute Engine instances inside a VPC Service Controls perimeter, enforce Private Google Access for service communications, and implement Cloud Armor security policies on ingress endpoints.

Deploy standard Google Kubernetes Engine (GKE) clusters using Sensitive Data Protection to de-identify data fields before writing to storage, and enforce Binary Authorization on container deployments.

Deploy the processing workloads on Shielded VM instances with Secure Boot and vTPM enabled, enforce IPSec tunnels across internal VPCs, and rely on default Google-managed encryption keys for storage and persistent disk protection.

Deploy the processing workloads on Confidential VM instances utilizing hardware-based memory encryption, enforce TLS 1.2+ using Cloud Load Balancing SSL policies for in-transit traffic, and encrypt all persistent disks and storage using Customer-Managed Encryption Keys (CMEK) backed by Cloud HSM.

Professional Cloud Security Engineer

End To End Confidential Computing Data Protection Architecture

Related questions