Your enterprise is designing a secure CI/CD pipeline and runtime deployment in Google Cloud to handle sensitive application configurations and secrets. Your corporate security team imposes the following compliance and architectural requirements: All sensitive secrets, configuration artifacts, and pipeline resources must be encrypted at rest using Customer-Managed Encryption Keys (CMEK) hosted in Cloud KMS. An organization policy must mandate that all CMEK keys used across workload projects originate exclusively from a centralized security project (projects/corp-sec-kms). The principle of least privilege must be strictly enforced, granting workload identities and service agents only the precise cryptographic permissions required to perform automated encryption and decryption. Which set of configuration steps should you implement to satisfy these requirements?

Apply the organization policy constraint constraints/gcp.restrictCmekCryptoKeyProjects allowing under:projects/corp-sec-kms, provision regional symmetric keys in the central project, and grant the Cloud KMS CryptoKey Encrypter/Decrypter role (roles/cloudkms.cryptoKeyEncrypterDecrypter) on the keys to the specific service identities.: ### What this solution is This solution implements centralized **Customer-Managed Encryption Key (CMEK)** governance in Google Cloud by enforcing organization-level key project boundaries while provisioning symmetric encryption keys in **Cloud Key Management Service (Cloud KMS)** with fine-grained **Cloud IAM** access controls. ### How it meets the requirements - **Enforcing Centralized Key Origins**: Applying the `constraints/gcp.restrictCmekCryptoKeyProjects` constraint with the rule `under:projects/corp-sec-kms` prevents workloads from using keys from unauthorized projects, ensuring all encryption keys reside solely within the central security project. - **Symmetric Key Provisioning**: CMEK integrations for protecting data at rest across Google Cloud services require regional **symmetric encryption keys** matching the resource location. - **Principle of Least Privilege**: Granting the `roles/cloudkms.cryptoKeyEncrypterDecrypter` (Cloud KMS CryptoKey Encrypter/Decrypter) role directly to the relevant service agents and runtime service accounts provides exact encrypt and decrypt capabilities without granting key administration or destruction privileges. ### Key advantages and capabilities - **Centralized Security Governance**: Security administrators retain full control over key lifecycle events (rotation, revocation, and destruction) in `corp-sec-kms`. - **Fast Permission Consistency**: IAM role bindings on Cloud KMS keys propagate within seconds, allowing rapid revocation during incident response. - **Comprehensive Auditability**: Access to Cloud KMS generates Cloud Audit Logs, capturing every programmatic encryption and decryption request initiated by pipeline service accounts. ### Why this is optimal This architecture perfectly satisfies organizational compliance requirements by preventing shadow key creation across distributed workload projects, using standard symmetric CMEK patterns, and strictly limiting IAM permissions to cryptographic operations.

Cmek Organization Policy Least Privilege Cloudkms | Professional Cloud DevOps Engineer

Cmek Organization Policy Least Privilege Cloudkms

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.

Your enterprise is designing a secure CI/CD pipeline and runtime deployment in Google Cloud to handle sensitive application configurations and secrets. Your corporate security team imposes the following compliance and architectural requirements:

All sensitive secrets, configuration artifacts, and pipeline resources must be encrypted at rest using Customer-Managed Encryption Keys (CMEK) hosted in Cloud KMS.
An organization policy must mandate that all CMEK keys used across workload projects originate exclusively from a centralized security project (projects/corp-sec-kms).
The principle of least privilege must be strictly enforced, granting workload identities and service agents only the precise cryptographic permissions required to perform automated encryption and decryption.

Which set of configuration steps should you implement to satisfy these requirements?

Provision regional Cloud KMS keys in each individual workload project, assign the Project Owner role (roles/owner) to the deployment service accounts, and use IAM Conditions to restrict access to secret metadata.

Configure the organization policy constraint constraints/gcp.restrictNonCmekServices to Deny on the centralized KMS project, and grant the Cloud KMS Admin role (roles/cloudkms.admin) to the pipeline and runtime service accounts.

Apply the constraints/gcp.restrictCmekCryptoKeyProjects constraint to allow under:projects/corp-sec-kms, provision asymmetric signing keys in Cloud KMS, and assign the Cloud KMS CryptoKey Decrypter role (roles/cloudkms.cryptoKeyDecrypter) to the service identities.

Apply the organization policy constraint constraints/gcp.restrictCmekCryptoKeyProjects allowing under:projects/corp-sec-kms, provision regional symmetric keys in the central project, and grant the Cloud KMS CryptoKey Encrypter/Decrypter role (roles/cloudkms.cryptoKeyEncrypterDecrypter) on the keys to the specific service identities.

Professional Cloud DevOps Engineer

Cmek Organization Policy Least Privilege Cloudkms

Related questions