An enterprise security architect is designing an encryption and governance model for Google Cloud services across multiple application projects. The security compliance mandate states: All newly provisioned workloads must strictly use Customer-Managed Encryption Keys (CMEK) rather than Google default encryption. Encryption keys must be centrally managed in a dedicated security project (prj-kms-central) to enforce separation of duties. Service agents must adhere to the principle of least privilege when accessing cryptographic resources. Which combination of Organization Policy constraints and IAM configurations should the architect implement?

Apply the `constraints/gcp.restrictNonCmekServices` constraint to deny non-CMEK service creation, configure `constraints/gcp.restrictCmekCryptoKeyProjects` allowing `under:projects/prj-kms-central`, and grant `roles/cloudkms.cryptoKeyEncrypterDecrypter` to each service agent on the specific Cloud KMS keys.: ### What this configuration is This configuration combines Google Cloud **Organization Policy CMEK constraints** with targeted **IAM role bindings** to establish an enterprise-grade Customer-Managed Encryption Key (CMEK) governance model with strict separation of duties. ### How it meets the requirements - **Mandatory CMEK protection**: Applying `constraints/gcp.restrictNonCmekServices` in a `Deny` policy list ensures that integrated services reject creation or provisioning requests if CMEK encryption is omitted, blocking fallback to Google default encryption. - **Centrally managed keys and boundary enforcement**: Configuring `constraints/gcp.restrictCmekCryptoKeyProjects` with the allowed hierarchy value `under:projects/prj-kms-central` restricts CMEK keys so that only CryptoKeys residing within the centralized security project can be selected by service teams. - **Separation of duties & least privilege**: Granting the **Cloud KMS CryptoKey Encrypter/Decrypter** role (`roles/cloudkms.cryptoKeyEncrypterDecrypter`) specifically to the respective Google Cloud service agents (e.g., `service-PROJECT_NUMBER@gcp-sa-...`) on individual keys or key rings allows automated cryptographic operations without exposing administrative rights or key management operations. ### Key advantages - **Automated compliance**: Prevents shadow key management or unencrypted resource deployment across all child projects. - **Centralized cryptographic boundary**: Key lifecycle, auditing, HSM protection levels, and rotation policies are controlled by security operators in `prj-kms-central`. - **Granular authorization**: Avoids granting broad project-level KMS permissions by binding least-privilege roles directly at the CryptoKey level. ### Why this is optimal This approach aligns with Google Cloud security best practices by decoupling key governance from application infrastructure while relying on native policy enforcement rather than detective controls.

Enforce Cmek Org Policy Central Kms | Professional Cloud Security Engineer

Enforce Cmek Org Policy Central Kms

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 security architect is designing an encryption and governance model for Google Cloud services across multiple application projects. The security compliance mandate states:

All newly provisioned workloads must strictly use Customer-Managed Encryption Keys (CMEK) rather than Google default encryption.
Encryption keys must be centrally managed in a dedicated security project (prj-kms-central) to enforce separation of duties.
Service agents must adhere to the principle of least privilege when accessing cryptographic resources.

Which combination of Organization Policy constraints and IAM configurations should the architect implement?

Apply the constraints/gcp.restrictCmekCryptoKeyProjects constraint allowing under:projects/prj-kms-central, configure Cloud Audit Logs exports to Cloud Storage, and assign roles/cloudkms.cryptoKeyEncrypterDecrypter to developers in the KMS project.

Apply the constraints/gcp.restrictNonCmekServices constraint to deny non-CMEK service creation, configure constraints/gcp.restrictCmekCryptoKeyProjects allowing under:projects/prj-kms-central, and grant roles/cloudkms.cryptoKeyEncrypterDecrypter to each service agent on the specific Cloud KMS keys.

Apply the constraints/gcp.enforceCmekPerService constraint to all projects, configure constraints/gcp.restrictCmekCryptoKeyProjects allowing projects/prj-kms-central, and grant roles/cloudkms.admin to each service agent.

Apply the constraints/gcp.restrictNonCmekServices constraint to deny non-CMEK service creation, disable Cloud KMS automated key rotation on all centralized keys, and grant roles/cloudkms.viewer to each application's compute service agent.

Professional Cloud Security Engineer

Enforce Cmek Org Policy Central Kms

Related questions