Advanced
Prepare and test your skills
Advanced
Prepare and test your skills
Envelope Encryption with Cloud KMS for Large Files
Free sample question, answered and explained below. The Professional Data Engineer practice bank has 1,353 more like it. Try 10 free: instant score, no account.
A data engineering team is designing an automated ingestion pipeline that processes sensitive transaction files exceeding 50 MB before storing them in Google Cloud. The organization's security policy requires column- and application-layer encryption managed centrally through Cloud Key Management Service (Cloud KMS).
During architectural review, the team observes that the Cloud KMS Encrypt API rejects direct encryption requests exceeding 64 KiB.
Which cryptographic key management strategy should the team implement to encrypt these large payloads securely and efficiently?
Explanations
Submit a quota increase request in the Google Cloud console to raise the Cloud KMS API max plaintext payload limit from 64 KiB to 100 MB per request.
Submit a quota increase request in the Google Cloud console to raise the Cloud KMS API max plaintext payload limit from 64 KiB to 100 MB per request.
What Requesting a KMS Payload Quota Increase Assumes
This option assumes that the 64 KiB limit on the Cloud KMS Encrypt and Decrypt API methods is a configurable administrative quota that can be adjusted via standard Google Cloud support or quota requests.
Why It Doesn't Meet the Requirement
- Architectural Hard Limit: The 64 KiB limit is a fundamental, non-configurable architectural constraint of the Cloud KMS API, not an adjustable quota.
- Design Mismatch: Cloud KMS is architected strictly as a key management service for handling Key Encryption Keys (KEKs) rather than a bulk data processing engine.
Key Characteristics and Limitations
- Cloud KMS limits maximum direct request payload size to 64 KiB across all regions and tiers.
- Google Cloud enforces envelope encryption patterns across all internal services (e.g., BigQuery, Cloud Storage) specifically to handle large volumes of data securely.
This Answer Would Be Correct If
The limit in question were an adjustable API request rate quota (such as read/write queries per minute) rather than an immutable payload data boundary.
Implement envelope encryption using a cryptographic library like Tink by generating a local Data Encryption Key (DEK) to encrypt the payload, wrapping the DEK with a Key Encryption Key (KEK) in Cloud KMS, and storing the ciphertext with the wrapped DEK.
Implement envelope encryption using a cryptographic library like Tink by generating a local Data Encryption Key (DEK) to encrypt the payload, wrapping the DEK with a Key Encryption Key (KEK) in Cloud KMS, and storing the ciphertext with the wrapped DEK.
What Envelope Encryption Is
Envelope encryption is a multi-layered cryptographic approach where actual application data is encrypted with a locally generated Data Encryption Key (DEK), and that DEK is subsequently encrypted (wrapped) using a centrally managed Key Encryption Key (KEK) stored in Cloud Key Management Service (Cloud KMS).
How It Meets The Requirements
- Overcomes 64 KiB API Limit: Direct encryption via Cloud KMS API functions (
Encrypt/Decrypt) has a hard input size limit of 64 KiB. By encrypting the large 50 MB payload locally with a symmetric DEK (such as AES-256-GCM), the workload avoids sending large data streams over the network to the KMS API. - Central Key Management: The KEK never leaves Cloud KMS, ensuring central access auditing, IAM access enforcement, and automated key rotation policies.
- Application-Layer Protection: Client-side libraries such as Tink streamline generating ephemeral DEKs, encrypting fields or payloads, wrapping the DEK with the Cloud KMS KEK URI, and outputting combined ciphertexts.
Key Advantages and Capabilities
- High Performance: Symmetric encryption of large datasets occurs locally in memory at wire speed.
- Minimal API Overhead: Only the tiny DEK (typically 32 bytes) is sent to Cloud KMS for wrapping/unwrapping operations.
- No Key Rotation Needed for DEKs: Generating a fresh DEK per write operation eliminates the operational need to rotate DEKs while keeping KEK rotation centralized.
- Granular Access Control: Decryption permissions are managed via IAM roles like
roles/cloudkms.cryptoKeyEncrypterDecrypteron the KEK.
Why This Is Optimal
Envelope encryption is Google Cloud's standard pattern for encrypting data at scale. It perfectly balances local compute performance with centralized KMS governance, adhering to security standards without hitting API payload size ceilings.
Create an asymmetric RSA-4096 Cloud KMS key pair, export the private key material directly into the data processing application runtime, and encrypt payloads locally using the exported private key.
Create an asymmetric RSA-4096 Cloud KMS key pair, export the private key material directly into the data processing application runtime, and encrypt payloads locally using the exported private key.
What Exporting Private Keys Entails
This option attempts to export the private key material of an asymmetric Cloud KMS key pair to application memory so that local encryption/decryption can proceed without making API calls to KMS.
Why It Doesn't Meet the Requirement
- KMS Keys Cannot Be Exported: By design, non-software HSM and Cloud KMS managed keys are non-exportable; the private key material cannot leave the secure boundary of Cloud KMS.
- Violates Centralized Security Policies: Exporting raw cryptographic keys into pipeline containers or compute instances exposes key material to leakage and memory dumps, defeating centralized key management and audit trails.
- Asymmetric Encryption Inefficiency: Asymmetric RSA ciphers are computationally expensive and cannot natively encrypt payloads larger than their key size (e.g., RSA-4096 can only encrypt a few hundred bytes directly).
Key Characteristics and Limitations
- Asymmetric keys in Cloud KMS are intended for signing/verifying or wrapping small payloads, not high-volume bulk data encryption.
- Cloud KMS guarantees that private key material remains protected inside Google's cryptographic boundary.
This Answer Would Be Correct If
The workload required public-key distribution for external digital signatures where client applications verify data using the public key.
Split each 50 MB payload into 64 KiB blocks, invoke the Cloud KMS Encrypt API synchronously for each block using a single symmetric CryptoKey, and concatenate the resulting ciphertexts.
Split each 50 MB payload into 64 KiB blocks, invoke the Cloud KMS Encrypt API synchronously for each block using a single symmetric CryptoKey, and concatenate the resulting ciphertexts.
What Chunking and Direct KMS Encryption Does
This approach breaks large data files into thousands of 64 KiB fragments and sends each fragment as an independent REST/gRPC API call to the Cloud KMS projects.locations.keyRings.cryptoKeys:encrypt endpoint, subsequently stitching the returned ciphertexts together.
Why It Doesn't Meet the Requirement
- Massive Network and Latency Overhead: A 50 MB payload requires over 800 discrete network requests to Cloud KMS per file, resulting in severe pipeline latency and network bottlenecks.
- Exceeds KMS Rate Limits and Quotas: High-throughput ingestion pipelines sending thousands of direct KMS encryption calls per second will quickly breach KMS API rate limits and quotas.
- Excessive Cost: Cloud KMS charges on a per-cryptographic-operation basis; chunking multiplies operational costs exponentially compared to local DEK encryption.
Key Characteristics and Limitations
- Cloud KMS direct
Encrypt/Decryptis strictly intended for small secrets, tokens, or cryptographic keys under 64 KiB. - Storing split ciphertexts requires complex metadata management to guarantee ordering, chunk integrity, and non-repudiation.
This Answer Would Be Correct If
The data payload was an isolated secret, API key, or credential that was guaranteed to remain strictly below 64 KiB.
Try 10 interactive questions like this one, free
Answer them yourself and get your score the moment you finish. No account needed.
Full access includes
- 1,353 practice questions across all 5 exam domains
- Every answer explained: why it is right, and why the others are not
- Scout, an AI tutor that answers your follow-up questions
- Readiness tracking by domain, so you know when to book the exam
Related questions
Keep the momentum going with these hand-picked practice scenarios
AdvancedProfessional Data Engineer
Cloud SQL ENCRYPTED_ONLY Private Services Access VPC-SC
Data encryption
AdvancedProfessional Data Engineer
CSEK vs CMEK vs Cloud EKM
Data encryption
AdvancedProfessional Data Engineer
Cloud SQL Cross-Region Replica Failover
Data replication and failover (e.g., Cloud SQL, Redis clusters)
AdvancedProfessional Data Engineer
Tink Envelope Encryption with BigQuery AEAD
Data security (encryption and key management)
AdvancedProfessional Data Engineer
BI Engine Materialized View Preferred Tables
Connecting to tools
FundamentalAssociate Data Practitioner
Cloud Composer vs Workflows vs Dataproc Workflow Templates
Select a data orchestration solution (e.g., Cloud Composer, scheduled queries, Dataproc Workflow Templates, Workflows) based on business requirements
Last updated Validated