An enterprise is designing a centralized Customer-Managed Encryption Key (CMEK) strategy in Google Cloud to protect sensitive datasets across several workload projects. The security architecture must adhere to the following operational and compliance requirements: Separation of duties: Key administrators who create, configure automated rotation for, and retire cryptographic keys must not have permissions to perform cryptographic operations (encrypt/decrypt). Least privilege: Workload service accounts must only perform encryption and decryption operations on their specific designated keys without gaining access to other keys or administrative controls. Data continuity: Key rotation must occur automatically every 90 days without disrupting access to existing historical data encrypted with earlier key versions. Which architectural approach should you implement in Cloud Key Management Service (Cloud KMS)?

Manage keys in a dedicated key project, grant security administrators the Cloud KMS Admin role (`roles/cloudkms.admin`) on the key ring, configure an automatic rotation period of 90 days on the CryptoKey, and grant workload service accounts the Cloud KMS CryptoKey Encrypter/Decrypter role (`roles/cloudkms.cryptoKeyEncrypterDecrypter`) on their specific CryptoKeys.: ### What Cloud KMS Key Lifecycle and Granular IAM Is **Google Cloud Key Management Service (Cloud KMS)** provides a scalable and secure cryptographic key management system. In a secure enterprise architecture, keys are organized hierarchically within **Projects**, **Key Rings**, and **CryptoKeys**, allowing administrators to define fine-grained Identity and Access Management (**IAM**) policies and automate key lifecycle workflows. ### How It Meets the Requirements - **Separation of Duties**: Granting administrators the `roles/cloudkms.admin` role allows them to manage key rings, create keys, set automatic rotation periods, and disable or destroy retired key versions without granting data access. The `roles/cloudkms.admin` role specifically **does not include** permissions to encrypt or decrypt data payload contents (`cloudkms.cryptoKeyVersions.useToEncrypt` or `cloudkms.cryptoKeyVersions.useToDecrypt`). - **Enforcing Least Privilege**: Granting the `roles/cloudkms.cryptoKeyEncrypterDecrypter` role directly at the **individual CryptoKey resource level** ensures workload service accounts can only encrypt and decrypt using their designated key, preventing cross-workload access and administrative modifications. - **Data Continuity & Automated Rotation**: Configuring an automatic rotation period generates a new primary **key version** every 90 days. Cloud KMS automatically uses the new primary version for all future encryption calls while keeping older versions enabled in the background to seamlessly decrypt existing data without data loss or administrative overhead. ### Key Advantages and Capabilities - **Centralized Key Governance**: Isolating keys in a dedicated `prj-c-kms` project enables dedicated auditability and strict perimeter management. - **Seamless Key Versioning**: Automated rotation avoids application downtime because legacy data does not need to be immediately rewritten or re-encrypted upon version rotation. - **Granular IAM Binding**: IAM policies can be bound at the organization, folder, project, key ring, or individual key level to enforce strict boundary controls. - **Audit Visibility**: Every administrative adjustment and cryptographic operation generates **Cloud Audit Logs** for tracking and compliance. ### Why This Is Optimal This design perfectly balances **least privilege**, **operational automation**, and **separation of duties** by keeping administrative permissions isolated from data plane cryptographic access.

StudyCerts

Cloud Kms Lifecycle Rotation Iam Least Privilege | Intrigued by the art of cloud architecture? Discover how to design, develop, and manage robust, secure, scalable, and dynamic solutions on Google Cloud as you prepare for the Professional Cloud Architect exam! | StudyCerts

Professional Cloud Architect

Intrigued by the art of cloud architecture? Discover how to design, develop, and manage robust, secure, scalable, and dynamic solutions on Google Cloud as you prepare for the Professional Cloud Architect exam!

Intermediate

Prepare and test your skills

Track Readiness

Set Exam Goal

Intermediate

Prepare and test your skills

Track Readiness

Set Exam Goal

Cloud Kms Lifecycle Rotation Iam Least Privilege

Section: Data security (key management, encryption, secret management)

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.

An enterprise is designing a centralized Customer-Managed Encryption Key (CMEK) strategy in Google Cloud to protect sensitive datasets across several workload projects.

The security architecture must adhere to the following operational and compliance requirements:

Separation of duties: Key administrators who create, configure automated rotation for, and retire cryptographic keys must not have permissions to perform cryptographic operations (encrypt/decrypt).
Least privilege: Workload service accounts must only perform encryption and decryption operations on their specific designated keys without gaining access to other keys or administrative controls.
Data continuity: Key rotation must occur automatically every 90 days without disrupting access to existing historical data encrypted with earlier key versions.

Which architectural approach should you implement in Cloud Key Management Service (Cloud KMS)?

Manage keys in a dedicated key project, grant security administrators the Cloud KMS Admin role (roles/cloudkms.admin) on the key ring, configure an automatic rotation period of 90 days on the CryptoKey, and grant workload service accounts the Cloud KMS CryptoKey Encrypter/Decrypter role (roles/cloudkms.cryptoKeyEncrypterDecrypter) on their specific CryptoKeys.

Grant security administrators the Cloud KMS CryptoKey Encrypter/Decrypter role (roles/cloudkms.cryptoKeyEncrypterDecrypter) at the project level, configure automatic rotation, and grant workload service accounts the Cloud KMS Admin role (roles/cloudkms.admin) on individual key rings.

Assign the basic Editor role (roles/editor) to workload service accounts on the key project, create a single shared CryptoKey for all workloads, and configure security administrators to manually rotate and re-encrypt data every 90 days.

Manage keys in the respective application workload projects, configure a 90-day rotation schedule, immediately destroy older key versions upon rotation, and grant the Cloud KMS Admin role (roles/cloudkms.admin) to workload service accounts.

Professional Cloud Architect

Cloud Kms Lifecycle Rotation Iam Least Privilege

Related questions