An enterprise is architecting a high-throughput, low-latency transaction processing platform on Google Cloud using managed services such as Firestore in Datastore mode and Dataproc Metastore across the us multi-region. The security engineering team must establish a key management architecture that satisfies several operational and architectural requirements: Access and lifecycle control: The organization must maintain cryptographic key control, audit logging, and the ability to revoke keys independently of Google default encryption. Performance and latency: High-volume transactional read and write operations must not incur per-transaction cryptographic RPC overhead or latency degradation. High availability: Key resolution must support regional and multi-regional redundancy without depending on external infrastructure or off-cloud network links. Service integration: The keys must adhere to Google Cloud customer-managed encryption key (CMEK) location-matching constraints across regional and multi-regional deployments. Which cryptographic key management architecture should the organization implement to fulfill these requirements?

Configure symmetric Cloud KMS keys with Software or Cloud HSM protection levels in locations that match the resource regions and multi-regions.: ### What Cloud KMS In-Cloud Keys Are Google **Cloud Key Management Service (Cloud KMS)** provides managed symmetric key encryption keys (KEKs) hosted either in software or within hardware security modules (**Cloud HSM**). These keys integrate natively with Google Cloud services to provide **Customer-Managed Encryption Keys (CMEK)** while maintaining low latency and high availability. ### How It Meets the Requirements - **Access and lifecycle control**: CMEK allows administrators to manage key rotation schedules, IAM access policies, cryptographic boundaries, and key state transitions (enabling/disabling) while producing detailed Cloud Audit Logs for tracking key access. - **Performance and latency**: Google Cloud services use **envelope encryption**. Services like Firestore generate local Data Encryption Keys (DEKs) and use Cloud KMS to wrap/unwrap DEKs. They employ periodic background polling to validate key availability rather than issuing a Cloud KMS encrypt/decrypt call on every individual transactional request, ensuring near-zero impact on real-time query latency. - **High availability**: In-cloud Software and Cloud HSM keys benefit from Google Cloud's distributed infrastructure and multi-region replication (such as the `us` multi-region), removing external network dependencies. - **Service integration**: Keys can be provisioned in exact matching regional and multi-regional topologies (e.g., Cloud KMS `us` multi-region mapped to Datastore `nam5`), satisfying strict location validation rules. ### Key Advantages and Capabilities - **Native envelope encryption**: Eliminates per-transaction cryptographic RPC bottlenecks. - **Multi-region resilience**: High-availability SLAs backed directly by Google Cloud infrastructure. - **Location compliance**: Seamlessly aligns key rings with resource locations. - **Granular IAM governance**: Assigns `roles/cloudkms.cryptoKeyEncrypterDecrypter` to specific Google-managed service agents. ### Why This Is Optimal Choosing in-cloud Software or Cloud HSM keys avoids the latency, availability risks, and external egress dependencies of external key managers while ensuring full CMEK compatibility across all Google Cloud services.