A financial enterprise is implementing an organizational security architecture in Google Cloud to meet strict compliance mandates for data at rest across regional workloads. The security team has established the following requirements: All newly created storage and database resources must strictly use Customer-Managed Encryption Keys (CMEK) rather than Google default encryption. Encryption keys must be centrally managed in dedicated security projects, preventing workload project teams from creating or selecting keys in unauthorized projects. Workload service identities must be granted only the minimum necessary cryptographic permissions required for envelope encryption. Which combination of organization policies and Identity and Access Management (IAM) configurations should the security engineer implement?

Configure `constraints/gcp.restrictNonCmekServices` as a Deny rule for the required service APIs, configure `constraints/gcp.restrictCmekCryptoKeyProjects` as an Allow rule specifying the central KMS projects, and grant `roles/cloudkms.cryptoKeyEncrypterDecrypter` on the KMS keys to the respective service agents.: ### What this configuration is This architectural solution combines Google Cloud CMEK organization policy constraints with least-privilege Cloud KMS Identity and Access Management (IAM) role bindings to enforce centralized cryptographic governance across an enterprise hierarchy. ### How it meets the requirements - **Mandatory CMEK enforcement:** The `constraints/gcp.restrictNonCmekServices` list constraint blocks the creation of resources in designated services if CMEK is omitted. Setting this policy to **Deny** for specific services (e.g., `bigquery.googleapis.com`, `storage.googleapis.com`, `alloydb.googleapis.com`) prevents users from falling back to Google default encryption. - **Centralized key restriction:** The `constraints/gcp.restrictCmekCryptoKeyProjects` list constraint restricts which projects can supply Cloud KMS keys for CMEK. Setting it to **Allow** with values such as `under:projects/KMS_PROJECT_ID` ensures workload projects can only consume keys provisioned in central, governed security projects. - **Least-privilege envelope encryption:** Granting the `roles/cloudkms.cryptoKeyEncrypterDecrypter` role to each service's respective service agent (e.g., `service-[PROJECT_NUMBER]@gcp-sa-...iam.gserviceaccount.com`) provides exactly the encrypt and decrypt capabilities required to wrap and unwrap Data Encryption Keys (DEKs) during I/O operations without granting administrative privileges. ### Key advantages - **Separation of duties:** Decouples key administration in central security projects from resource administration in workload projects. - **Automated enforcement:** Prevents non-compliant resource provisioning at the API layer with immediate `FAILED_PRECONDITION` error responses. - **Granular auditability:** Generates explicit Cloud KMS Data Access audit logs whenever service agents perform cryptographic wrap/unwrap operations. ### Why this is optimal This approach directly leverages predefined organization policy constraints designed for CMEK governance and avoids custom scripting or complex detective-only remediation pipelines.

Enforce Cmek Org Policies Central Kms Iam | Professional Cloud Security Engineer

Enforce Cmek Org Policies Central Kms Iam

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.

A financial enterprise is implementing an organizational security architecture in Google Cloud to meet strict compliance mandates for data at rest across regional workloads. The security team has established the following requirements:

All newly created storage and database resources must strictly use Customer-Managed Encryption Keys (CMEK) rather than Google default encryption.
Encryption keys must be centrally managed in dedicated security projects, preventing workload project teams from creating or selecting keys in unauthorized projects.
Workload service identities must be granted only the minimum necessary cryptographic permissions required for envelope encryption.

Which combination of organization policies and Identity and Access Management (IAM) configurations should the security engineer implement?

Configure constraints/gcp.restrictServiceUsage to allow only cloudkms.googleapis.com in central projects, enforce Customer-Supplied Encryption Keys (CSEK) on all compute disks, and grant roles/cloudkms.signerVerifier to workload service agents.

Configure constraints/gcp.restrictNonCmekServices as a Deny rule for the required service APIs, configure constraints/gcp.restrictCmekCryptoKeyProjects as an Allow rule specifying the central KMS projects, and grant roles/cloudkms.cryptoKeyEncrypterDecrypter on the KMS keys to the respective service agents.

Configure constraints/gcp.restrictCmekCryptoKeyProjects as an Allow rule targeting the central KMS projects, set default project-level bucket encryption to CMEK, and assign roles/cloudkms.cryptoKeyDecrypter to the workload compute instances' default service accounts.

Configure constraints/gcp.restrictNonCmekServices as an Allow rule for the required service APIs, configure constraints/gcp.restrictCmekCryptoKeyProjects as a Deny rule listing the workload projects, and grant roles/cloudkms.admin on the key rings to the workload service agents.

Professional Cloud Security Engineer

Enforce Cmek Org Policies Central Kms Iam

Related questions