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.