Study guide
8.1 Data Encryption at Rest/Transit, Cloud KMS, CMEK & Cloud HSM
Google Professional Cloud Architect Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam Overview, Strategy & Case Study Methodology
1.1 Exam Overview, Structure & Scoring Logistics 1.2 The Professional Cloud Architect Role & Exam Mindset 1.3 Deconstructing GCP Case Studies & Scenario Questions
2 Chapter 2: Designing for Business Requirements
2.1 Mapping Business Objectives, ROI & Total Cost of Ownership 2.2 Cost Optimization Strategies, Pricing Models & Trade-Offs 2.3 Business Continuity, Governance & Compliance Planning
3 Chapter 3: Designing for Technical Requirements & Availability
3.1 Scalability, Elasticity & Capacity Planning 3.2 High Availability, Disaster Recovery Patterns & RTO/RPO 3.3 Performance Optimization & Global Latency Reduction
4 Chapter 4: Compute Selection & Workload Architecture
4.1 Compute Engine Architecture, Sizing & Managed Instance Groups 4.2 Google Kubernetes Engine (GKE) Standard vs Autopilot & Microservices 4.3 Serverless Architectures: Cloud Run, Cloud Functions & Eventarc
5 Chapter 5: Storage, Database & Data Warehouse Architecture
5.1 Cloud Storage Architecture, Storage Classes & Lifecycle Management 5.2 Relational Databases: Cloud SQL, AlloyDB & Cloud Spanner 5.3 NoSQL & Big Data Storage: Firestore, Bigtable & BigQuery
6 Chapter 6: Networking, Hybrid Connectivity & Traffic Routing
6.1 VPC Design, Subnets, Shared VPC & VPC Peering 6.2 Hybrid & Multicloud Connectivity: Cloud VPN & Cloud Interconnect 6.3 Cloud Load Balancing, Cloud CDN & Cloud DNS
7 Chapter 7: Identity, Access & Resource Governance
7.1 Cloud IAM Hierarchy, Custom Roles & Service Accounts 7.2 Workload Identity Federation, Service Account Impersonation & IAP 7.3 Organization Policies, Tags & Resource Governance
8 Chapter 8: Security Architecture, Data Protection & Compliance
8.1 Data Encryption at Rest/Transit, Cloud KMS, CMEK & Cloud HSM 8.2 Network Security: Cloud Armor, VPC Service Controls & Firewalls 8.3 Compliance Frameworks, Sensitive Data Protection & Security Command Center
9 Chapter 9: DevOps, Automation & Infrastructure as Code
9.1 Infrastructure as Code (IaC) with Terraform on Google Cloud 9.2 CI/CD Pipelines: Cloud Build, Artifact Registry & Cloud Deploy 9.3 Deployment Strategies (Blue/Green, Canary) & GitOps with Config Sync 9.4 Interacting with Google Cloud Programmatically: Cloud SDK, Cloud Shell & Emulators
10 Chapter 10: Site Reliability Engineering & Operations Excellence
10.1 SRE Fundamentals: SLIs, SLOs, SLAs & Error Budgets 10.2 Observability: Cloud Monitoring, Logging & Alert Policies 10.3 Diagnosing Performance: Cloud Trace, Profiler & Error Reporting
11 Chapter 11: Data Pipelines, Integration & Modernization
11.1 Event-Driven Architectures with Cloud Pub/Sub & Eventarc 11.2 Stream and Batch Processing: Dataflow & Dataproc 11.3 API Management & Service Integration: Apigee & Cloud API Gateway 11.4 Migration Planning & Execution: Migration Center, DMS, Datastream & Transfer Options
12 Chapter 12: Well-Architected Framework & Official Case Study Solutions
12.1 Google Cloud Well-Architected Framework & FinOps Governance 12.2 Comprehensive Case Studies: EHR Healthcare & Cymbal Retail 12.3 Comprehensive Case Studies: Altostrat Media & KnightMotives Automotive
13 Chapter 13: AI, Machine Learning & Generative AI Architecture
13.1 AI/ML Platform Architecture: Vertex AI, Gemini Enterprise Agent Platform & AI Hypercomputer 13.2 Prebuilt AI APIs, Model Garden, Gemini Cloud Assist & Securing AI
8.1 Data Encryption at Rest/Transit, Cloud KMS, CMEK & Cloud HSM
Key Takeaways Explain This Topic AI
Google Cloud enforces default encryption at rest using AES-256 (or AES-128) across all storage services with Google-managed keys, and default encryption in transit via TLS 1.3 externally and ALTS across Google's internal private fiber network.
Envelope encryption decouples data payload encryption from key governance: raw data chunks are encrypted by ephemeral Data Encryption Keys (DEKs) via AES-256-GCM, which are in turn wrapped by Key Encryption Keys (KEKs) managed in Cloud KMS.
Cloud Key Management Service (Cloud KMS) provides hierarchical cryptographic lifecycle control (Keyrings, Keys, Key Versions) supporting software keys, FIPS 140-2 Level 3 hardware security modules (Cloud HSM), and Cloud External Key Manager (Cloud EKM) for Hold-Your-Own-Key (HYOK) compliance.
Customer-Managed Encryption Keys (CMEK) enable granular customer revocation and automated rotation across Compute Engine, Cloud Storage, BigQuery, and Cloud SQL by granting roles/cloudkms.cryptoKeyEncrypterDecrypter to service-specific Google Service Agents.
Confidential Computing leverages AMD SEV / SEV-SNP hardware memory encryption on Confidential VMs and Confidential GKE Nodes to protect data in use in RAM, while Secret Manager securely versions, rotates, and mounts API credentials with fine-grained IAM governance.
Last updated: August 2026
Data Encryption at Rest/Transit, Cloud KMS, CMEK & Cloud HSM
Core Principle: Google Cloud enforces a multi-layered, defense-in-depth cryptographic model protecting data across all three states: at rest , in transit , and in use . By default, 100% of customer data stored on Google Cloud is encrypted using AES-256 with zero administrative configuration required. For enterprise compliance, architects leverage Cloud KMS, Cloud HSM, Cloud EKM, and Confidential Computing to retain absolute cryptographic custody, enable crypto-shredding, and protect memory payloads.
Google Cloud Default Encryption: At Rest, In Transit & In Use
Google Cloud provides automated, zero-overhead encryption across its global infrastructure without requiring customer intervention or licensing fees. +-----------------------------------------------------------------------------------+
- | GOOGLE CLOUD DEFAULT ENCRYPTION ARCHITECTURE |
- +-----------------------------------------------------------------------------------+
- | DATA AT REST | - 100% encrypted by default using AES-256 (or AES-128) |
- | | - Storage chunks encrypted at the storage sublayer |
- | | - Multi-tier envelope encryption (DEK wrapped by KEK) |
- +--------------------+---------------------------------------------------------------+
- | DATA IN TRANSIT | - External: TLS 1.3 / HTTPS terminated at Google Front Ends |
- | | - Inter-Data Center: Hardware-level MACsec / WAN encryption |
- | | - Internal Service-to-Service: ALTS (mutual auth + AES-GCM) |
- +--------------------+---------------------------------------------------------------+
- | DATA IN USE | - Confidential Computing (AMD SEV / SEV-SNP memory encrypt) |
- | | - Memory encrypted in hardware via ephemeral CPU AES keys |
- +-----------------------------------------------------------------------------------+
- 1. Data at Rest Encryption
Chunk-Level Encryption: Every file written to Google Cloud (Cloud Storage, Persistent Disk, BigQuery, Cloud Spanner) is automatically broken into individual storage chunks. Each chunk is encrypted with its own ephemeral Data Encryption Key (DEK) using AES-256 (or AES-128) in Galois/Counter Mode (GCM).
Google-Managed Keys: By default, Google manages the Key Encryption Keys (KEKs) that wrap and protect the DEKs, rotating them regularly and storing them within Google's internal Key Management Service.
2. Data in Transit Encryption
External to Google Cloud: Network traffic between external clients and Google Cloud services is encrypted using TLS 1.2 or TLS 1.3 and terminated at the global Google Front End (GFE) points of presence.
Internal Private Backbone: Network traffic moving between Google data centers over Google's global fiber backbone is encrypted at the physical/data link layer using MACsec and encapsulated within Google's proprietary routing infrastructure.
Application Layer Transport Security (ALTS): For internal RPCs communicating between microservices across Google's infrastructure, Google uses ALTS—a custom mutual-authentication and transport encryption protocol providing authenticated and encrypted channels using AES-128-GCM.
3. Data in Use (Confidential Computing)
Standard hypervisors and host operating systems have visibility into virtual machine RAM. To eliminate this vector, Confidential Computing uses hardware-based memory encryption to protect data while being actively processed by CPUs.
Comparison of Encryption States & Protocols
State Scope & Location Protocol / Cipher Key Custody Options
At Rest Storage chunks in Colossus, Persistent Disk, Cloud SQL, BigQuery AES-256 / AES-128 GCM Google-Managed, CMEK (Cloud KMS), Cloud HSM, Cloud EKM, CSEK
In Transit (External) Internet to Google Edge / GFE Load Balancer TLS 1.2 / TLS 1.3 Google-Managed SSL/TLS Certs, Self-Managed Certs, Certificate Manager
In Transit (Internal) Service-to-service internal Google Network RPCs ALTS / Wire-speed MACsec Google internal infrastructure PKI
In Use System RAM / CPU Caches during execution Hardware AES-128/256 (AMD SEV) Ephemeral hardware-generated keys managed by AMD Secure Processor
Envelope Encryption Mechanics (DEK vs. KEK)
Encrypting multi-gigabyte or terabyte files directly with a centralized key management service introduces massive network latency and creates a catastrophic bottleneck. Google Cloud solves this using Envelope Encryption . +-----------------------------------------------------------------------------------+
- | ENVELOPE ENCRYPTION WRITE FLOW |
- +-----------------------------------------------------------------------------------+
- | 1. Storage Engine generates local, ephemeral Data Encryption Key (DEK) |
- | 2. Raw Data Chunk + DEK ====(AES-256 Local Encrypt)====> Encrypted Data Chunk |
- | 3. DEK ====(Send to Cloud KMS via TLS)====> Cloud KMS wraps DEK with KEK |
- | 4. Cloud KMS returns Wrapped DEK (Encrypted DEK) |
- | 5. Encrypted Data Chunk + Wrapped DEK stored together on disk |
- | 6. Raw DEK is immediately purged from host memory |
- +-----------------------------------------------------------------------------------+
- +-----------------------------------------------------------------------------------+
- | ENVELOPE ENCRYPTION READ FLOW |
- +-----------------------------------------------------------------------------------+
- | 1. Storage Engine reads Wrapped DEK from storage metadata |
- | 2. Wrapped DEK ====(Send to Cloud KMS via TLS)====> Cloud KMS unwraps DEK |
- | 3. Cloud KMS checks IAM permissions on KEK -> Decrypts DEK using KEK |
- | 4. Cloud KMS returns raw DEK to storage engine over TLS |
- | 5. Encrypted Data Chunk + raw DEK ====(AES-256 Local Decrypt)====> Plaintext |
- | 6. Raw DEK is purged from host memory |
- +-----------------------------------------------------------------------------------+
- Architectural Benefits of Envelope Encryption
Performance & Scalability: Bulk data is encrypted and decrypted locally at wire speed directly on the storage node. Only tiny 256-bit DEKs traverse the network to Cloud KMS.
Security & Key Isolation: The master Key Encryption Key (KEK) never leaves the boundary of Cloud KMS or Cloud HSM. Even if an attacker gains physical access to the storage disks, the wrapped DEK cannot be decrypted without IAM access to the KEK.
Fast Re-encryption & Key Rotation: When a KEK is rotated, existing data chunks do not need to be re-encrypted. Only the small wrapped DEK needs to be re-wrapped with the new KEK version, or new writes simply adopt the newest KEK version.
Cloud Key Management Service (Cloud KMS) Architecture
Cloud KMS is a cloud-hosted key management service that allows organizations to generate, use, rotate, and destroy cryptographic keys across multi-region, regional, and global scopes. +-----------------------------------------------------------------------------------+
- | CLOUD KMS HIERARCHY MODEL |
- +-----------------------------------------------------------------------------------+
- | ORGANIZATION / FOLDER |
- | └── PROJECT |
- | └── LOCATION (e.g., global, us-central1, europe-west1) |
- | └── KEY RING (Logical collection; inherits IAM; cannot be deleted) |
- | └── CRYPTOKEY (Defines purpose, rotation schedule, HSM/Soft) |
- | ├── CRYPTOKEYVERSION 1 (Enabled / Disabled / Destroyed)|
- | ├── CRYPTOKEYVERSION 2 (Primary - used for encryption) |
- | └── CRYPTOKEYVERSION 3 (Pending destruction) |
- +-----------------------------------------------------------------------------------+
- Key Hierarchy & Lifecycle States
Key Rings: Organize keys within a specific GCP region or multi-region. Key rings cannot be deleted after creation to preserve cryptographic audit trails, but individual keys within them can be destroyed.
CryptoKey Purpose: Keys are created for specific cryptographic operations:
Symmetric Encryption/Decryption: AES-256-GCM (used for CMEK across Google Cloud services).
Asymmetric Signing/Verification: RSA (2048, 3072, 4096-bit) and Elliptic Curve (ECDSA P-256, P-384, Secp256k1).
Asymmetric Decryption: RSA-OAEP encryption.
Message Authentication Codes (MAC): HMAC-SHA256.
CryptoKeyVersion States:
Enabled : Available for cryptographic operations.
Disabled : Temporarily revoked; existing data cannot be decrypted until re-enabled.
Destroy scheduled : Placed in a configurable soft-delete destruction window (default 24 hours to 30 days).
Destroyed : Key material is permanently and irreversibly purged from KMS infrastructure.
Protection Levels: Software vs. HSM vs. EKM vs. CSEK
Feature / Level Cloud KMS (Software) Cloud HSM (Hardware) Cloud EKM (External) Customer-Supplied (CSEK)
Hardware Standard Software-backed (FIPS 140-2 Level 1) FIPS 140-2 Level 3 certified Hardware Security Module Third-party on-premises or SaaS HSM (Thales, Fortanix, HashiCorp) Customer's external key repository
Key Custody Google manages infrastructure; customer controls IAM Google manages physical HSM cluster; keys non-exportable Keys never leave customer on-premises/SaaS HSM Customer provides raw 256-bit AES key in HTTPS API headers
Availability SLA 99.99% 99.99% Subject to external HSM latency & Internet/VPC availability Customer's API infrastructure
Supported Services All GCP services supporting CMEK All GCP services supporting CMEK Cloud Storage, BigQuery, Compute Engine, Secret Manager Cloud Storage, Compute Engine Persistent Disks
Auditability Cloud Audit Logs Cloud Audit Logs + HSM Attestation reports External HSM audit logs + Cloud Audit Logs Cloud Audit Logs (shows CSEK used, not key material)
Hold-Your-Own-Key (HYOK) No No (Google-hosted HSM) Yes (Customer holds root of trust outside Google) Yes (Ephemeral per request)
Caution
Customer-Supplied Encryption Keys (CSEK) Danger: With CSEK, Google never stores the encryption key on disk or in Cloud KMS. The customer supplies the 256-bit AES key string directly in the HTTP request headers ( x-goog-encryption-key ). If the customer loses or forgets this key, Google cannot recover the data under any circumstances , resulting in permanent, unrecoverable data loss.
Customer-Managed Encryption Keys (CMEK) Enterprise Integration
CMEK bridges Google Cloud managed services (Compute Engine, BigQuery, Cloud Storage, Cloud SQL, Pub/Sub, Dataproc, GKE) with Cloud KMS, empowering enterprise security teams to retain control over key rotation, IAM permissions, and instant data revocation. +-----------------------------------------------------------------------------------+
- | CMEK SERVICE AGENT WORKFLOW |
- +-----------------------------------------------------------------------------------+
- | 1. Admin provisions Cloud KMS Key: projects/sec-proj/locations/us/keyRings/k1... |
- | 2. Admin discovers Service Agent for target service: |
- | - Cloud Storage: service-PROJECT_NUM@gs-project-accounts.iam.gserviceaccount.com|
- | - BigQuery: bq-PROJECT_NUM@bigquery-encryption.iam.gserviceaccount.com |
- | - Compute Engine:service-PROJECT_NUM@compute-system.iam.gserviceaccount.com |
- | 3. Admin grants IAM Role on Key: roles/cloudkms.cryptoKeyEncrypterDecrypter |
- | 4. Target resource configured with KMS Key URI |
- | 5. Target service automatically calls KMS to unwrap DEK during reads/writes |
- +-----------------------------------------------------------------------------------+
- Service-Specific CMEK Integration Details
Compute Engine Persistent Disks: When a CMEK key encrypts a persistent disk, the Compute Engine Service Agent requires roles/cloudkms.cryptoKeyEncrypterDecrypter . If the key is revoked or disabled, the VM immediately crashes or halts disk I/O.
Cloud Storage: CMEK can be set as a default key at the bucket level or passed per-object. New objects inherit the default key.
BigQuery: Tables, datasets, and query destination tables can be encrypted with CMEK. When querying a CMEK-encrypted table, the BigQuery Service Agent calls Cloud KMS to decrypt the underlying storage blocks.
Cloud SQL: CMEK encrypts the underlying storage volume, backups, and read replicas. Key rotation in Cloud SQL requires creating a new key version and applying it to the instance.
Crypto-Shredding & Instant Revocation
Instant Revocation: By disabling the primary CryptoKeyVersion or revoking the IAM roles/cloudkms.cryptoKeyEncrypterDecrypter binding from the Service Agent, all read/write operations immediately fail across the associated GCP services.
Crypto-Shredding: To permanently destroy petabytes of distributed data instantaneously across all backups and replicas, security administrators schedule the destruction of the KMS CryptoKey. Once destroyed, the encrypted data blocks become cryptographically unreadable noise, fulfilling strict compliance sanitization mandates (e.g., GDPR Right to be Forgotten).
CMEK Organizational Policy Constraints
To enforce CMEK across an entire GCP organization and prevent developers from creating unencrypted or Google-managed resources, security teams deploy Organization Policies:
constraints/gcp.cmekPolicy : Mandates CMEK for specific services.
constraints/gcp.restrictCmekCryptoKeyProjects : Restricts the specific KMS projects from which CMEK keys can be selected, preventing the use of unauthorized or external keyrings.
Confidential Computing Architecture
Confidential Computing is a breakthrough hardware security technology that encrypts data in memory (RAM) while it is being processed, preventing the cloud hypervisor, host OS, and system administrators from inspecting customer memory space. +-----------------------------------------------------------------------------------+
- | CONFIDENTIAL COMPUTING ARCHITECTURE |
- +-----------------------------------------------------------------------------------+
- | GUEST VM MEMORY SPACE (Encrypted with hardware AES-128/256 key) |
- | +-----------------------------------------------------------------------------+ |
- | | Application Data | In-Memory Secrets | Decrypted PII / Financial Data | |
- | +-----------------------------------------------------------------------------+ |
- | | |
- | (AMD Secure Processor HW Layer) |
- | v |
- | HYPERVISOR / GOOGLE HOST OS (CANNOT READ GUEST RAM) |
- | +-----------------------------------------------------------------------------+ |
- | | KVM Hypervisor | Host Linux Kernel | Host Root Admin (No Visibility!) | |
- | +-----------------------------------------------------------------------------+ |
- +-----------------------------------------------------------------------------------+
- Hardware Technologies & Implementations
AMD SEV (Secure Encrypted Virtualization): Generates an ephemeral, hardware-managed AES encryption key for each virtual machine. Memory is automatically encrypted when written to DRAM and decrypted when fetched into CPU caches.
AMD SEV-SNP (Secure Nested Paging): Adds strong memory integrity protection to prevent hypervisor-based replay attacks, memory corruption, and unauthorized page remapping.
Confidential VMs: N2D and C2D Compute Engine machine types supporting Confidential VM mode with zero code refactoring and negligible performance overhead (<2-4%).
Confidential GKE Nodes: Enforces memory encryption across all Kubernetes worker nodes and pods, ensuring multi-tenant pod memory isolation from the underlying node hypervisor.
Confidential Space: A specialized, hardened container execution environment enabling multi-party collaborative data analytics (e.g., competing banks training joint anti-fraud ML models) where neither party can access the other's raw dataset or proprietary algorithm.
Secret Manager: Architecture, IAM Governance & Rotation
Secret Manager is a fully managed, centralized storage service designed specifically for sensitive configuration metadata such as database passwords, API tokens, private SSH keys, and TLS certificates. +-----------------------------------------------------------------------------------+
- | SECRET MANAGER ARCHITECTURE |
- +-----------------------------------------------------------------------------------+
- | SECRET CONTAINER: "projects/prod-app/secrets/db-primary-password" |
- | ├── IAM Policy: Granted to service-account@prod-app.iam.gserviceaccount.com |
- | ├── Replication: Automatic (Multi-Region) or User-Managed (Specific Regions) |
- | ├── Rotation Policy: Rotates every 30 days -> Pub/Sub Topic -> Cloud Run/Func |
- | └── VERSIONS: |
- | ├── Version 1: DESTROYED |
- | ├── Version 2: DISABLED |
- | ├── Version 3: ENABLED (Current Active Secret Payload) |
- | └── "latest" alias -> Resolves dynamically to Version 3 |
- +-----------------------------------------------------------------------------------+
- Key Architectural Characteristics
Payload Limits: Designed for objects up to 64 KiB (for larger binary files, use Cloud Storage with CMEK).
Automatic Replication: Secrets can be replicated automatically across Google Cloud geographies or constrained to specific regulatory regions via user-managed replication policies.
Granular IAM Roles:
roles/secretmanager.secretAccessor : Permits reading the secret's payload value ( secretmanager.versions.access ).
roles/secretmanager.secretVersionManager : Permits adding and managing versions.
roles/secretmanager.admin : Grants full administrative control over secret metadata and IAM policies.
Automated Secret Rotation: Configured with a next_rotation_time and rotation_period . When the rotation timestamp is reached, Secret Manager publishes a message to a Cloud Pub/Sub topic, triggering a Cloud Function or Cloud Run service to provision new database credentials and upload a new secret version.
GKE Native Integration: The Secret Store CSI Driver mounts secrets directly from Secret Manager into Kubernetes Pods as local in-memory volumes ( tmpfs ), preventing credentials from being exposed in container environment variables or plain text config maps.
- Concrete Architectural Scenario: Multi-Tier FinTech Security Architecture
- Scenario Profile
Client: Global FinTech processing credit card tokenization and ACH transfers.
Requirements: FIPS 140-2 Level 3 cryptographic custody; instant data revocation capability; protection of cardholder data in memory from hypervisor access; automated 30-day rotation of database connection credentials; long-term compliance audit logging. [ Web/API Tier ] ----> [ Payment Processing Microservice on GKE ]
- Confidential GKE Nodes (AMD SEV Memory Encrypted)
- Secret Store CSI Driver (Mounts DB Secret from Secret Manager)
- |
- +-----> [ Cloud SQL & Cloud Storage ]
- Encrypted with CMEK (Cloud HSM)
- FIPS 140-2 Level 3 Certified
- Instant Revocation via IAM
- Architecture Blueprint
Cryptographic Key Storage: Cloud KMS configured with Cloud HSM (FIPS 140-2 Level 3) in us-central1 . Separate CMEK keys are created for Cloud Storage buckets and Cloud SQL databases.
Data in Use Protection: GKE worker nodes deployed as Confidential GKE Nodes using AMD SEV-SNP to protect cardholder memory payloads during payment parsing.
Credential Management: Database passwords stored in Secret Manager with automated 30-day rotation triggered via Cloud Pub/Sub and Cloud Functions, mounted into GKE pods using the Secret Store CSI Driver.
Revocation & Compliance: In the event of a security incident, the security team disables the Cloud HSM CryptoKeyVersion, immediately cutting off all database and storage I/O.
Important
Exam Watch: When a scenario requires compliance with FIPS 140-2 Level 3 hardware standards, you must select Cloud HSM . If the requirement states that the customer must hold the root keys exclusively in their own on-premises data center or external key vault , select Cloud EKM (External Key Manager) . If the question asks to protect data in memory from hypervisor inspection , select Confidential VMs / Confidential Computing .