GCP Professional Cloud Architect Practice Question

Your fintech company is migrating its fraud-detection analytics to Google Cloud. Compliance mandates that all encryption keys be generated in, and remain in, an on-premises HSM; Google must never have access to the plaintext key material. Keys must rotate every 90 days without forcing re-encryption of existing BigQuery tables or Cloud Storage objects. The security operations team must control key lifecycle, while data engineers may only encrypt and decrypt data. Which approach best satisfies these requirements?

Generate a new key in Cloud HSM and export its material to the on-prem HSM for backup; enforce rotation by re-encrypting all existing data with each new key version and give security operations the Owner role on the projects.
Configure Cloud External Key Manager (EKM) with an externally managed key backed by the on-prem HSM; automate creation of a new external key version every 90 days, grant the security team the Cloud KMS Admin role, and grant data engineers the Cloud KMS CryptoKey Encrypter/Decrypter role.
Create a customer-managed symmetric key in Cloud KMS (software protection level), import the HSM-generated material into a new key version every 90 days, and make data engineers key Owners for direct management.
Store the HSM-generated key in Secret Manager and rotate it by updating the secret every 90 days; have data engineers retrieve the secret at runtime to encrypt and decrypt data.

Report Issue

Answer Description

Using Cloud External Key Manager (EKM) ensures that the key is generated and stored solely in your on-premises HSM, so Google never sees the plaintext material. Each encryption or decryption call from BigQuery or Cloud Storage is proxied to the external HSM, meeting the data-sovereignty constraint. You can meet the 90-day rotation requirement by automating the creation of a new external key version every 90 days-for example, with Cloud Scheduler triggering a Cloud Function that calls the Cloud KMS API. Previous key versions remain available for decryption, so no re-encryption is needed. Assign the Cloud KMS Admin role to the security operations team for key lifecycle control, and the Cloud KMS CryptoKey Encrypter/Decrypter role to data engineers so they can use, but not manage, the key. The other options fail because importing the key into a Cloud KMS software key stores the plaintext within Google's boundary, Secret Manager is not intended for cryptographic key operations and would expose the key to Google, and Cloud HSM keys are non-exportable so they cannot originate in an on-premises HSM.

Ask Bash

Bash is our AI bot, trained to help you pass your exam. AI Generated Content may display inaccurate information, always double-check anything important.