Google ACE Configuring Access and Security Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Set an organization policy constraint that requires CMEK for Compute Engine disks

  Why this is correct

  Setting an organization policy constraint (iam.disableServiceAccountKeyCreation is not relevant; here it's a custom constraint or the predefined compute.disableNestedVirtualization? Actually for CMEK, the relevant org policy is a custom constraint or the new `constraints/compute.requireCmek` that enforces CMEK on new Compute Engine disks at creation time. This is the only preventive control among the options because it blocks the disk-creation API call unless a valid CMEK key is supplied, making noncompliant instances impossible to create. It operates at the organization or folder level and is enforced by the resource manager before the Compute Engine API accepts the request.

• ✗

  Specify the CMEK key in each instance template used for managed instance groups

  Why it's wrong here

  Specifying a CMEK key in an instance template only defines the key to use when the template is consumed; it does not prevent someone from creating a VM or disk with a different template or via the plain `disks.create` API without any CMEK key. A managed instance group will happily use a template that omits the `kmsKeyName` field, resulting inGoogle-managed default encryption. Therefore, this is a configuration best practice, not an enforcement control, and it fails the requirement to 'enforce that all instances' use CMEK.

• ✗

  Grant the Cloud KMS Admin role to the project's compute service account

  Why it's wrong here

  Granting `roles/cloudkms.admin` to the compute service account gives it full management permissions over Cloud KMS resources, including creating new key rings and keys, rotating, disabling, and destroying keys. The compute service account only needs the `roles/cloudkms.cryptoKeyEncrypterDecrypter` role on the specific key to encrypt/decrypt disks — the admin role is grossly over-privileged and actually expands the attack surface. It neither enforces disk encryption nor restricts when disks are created; it merely allows the account to administer keys.

• ✗

  Create a Cloud Audit Logs sink to monitor instances without CMEK

  Why it's wrong here

  A Cloud Audit Logs sink routes log entries containing the resource data for Compute Engine activities, including `disks.insert` calls, to a destination like BigQuery or Pub/Sub. You could then query for disks that lack `kmsKeyName` in their request or resource metadata, but this is a detective control that only reports after the fact. It provides no prevention or enforcement mechanism, so noncompliant instances can still be created, and someone would have to manually respond to the logs.

• ✓

  Grant the Cloud KMS CryptoKey Encrypter/Decrypter role to the Compute Engine service account

  Why this is correct

  Granting `roles/cloudkms.cryptoKeyEncrypterDecrypter` to the Compute Engine service account (the service account that Compute Engine uses at the project level) is a required prerequisite for using a CMEK key with Compute Engine disks. It is not itself an enforcement mechanism — but it is necessary because when a VM is created with a CMEK, the Compute Engine service account must be allowed to encrypt/decrypt using that key. Without this IAM binding, any attempt to attach a CMEK-protected disk will fail with a permission denied error, so this is a valid component of a CMEK strategy even though it does not by itself force all disks to use CMEK.

Go deeper

Related to this question