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.

• ✓

  Grant authorized users the roles/cloudkms.cryptoKeyEncrypterDecrypter role.

  Why this is correct

  Granting authorized users the roles/cloudkms.cryptoKeyEncrypterDecrypter role on the Cloud KMS key is correct because this IAM role grants permission to call the Cloud KMS Encrypt and Decrypt operations, which are required for objects to be uploaded with and read from a CMEK-encrypted bucket. Even if a user has bucket-level permissions, they cannot create or read objects encrypted with that key unless they have this role on the key itself. This ensures only the intended authorized principals can use the customer-managed key for cryptographic operations.

• ✗

  Grant all users the roles/cloudkms.cryptoKeyEncrypterDecrypter role.

  Why it's wrong here

  Granting all users the roles/cloudkms.cryptoKeyEncrypterDecrypter role is incorrect because it would give every principal on the internet, including anonymous and untrusted users, the ability to encrypt and decrypt data with the CMEK key. This completely defeats the security team's goal of restricting access to the stored data, as any attacker could decrypt objects or encrypt arbitrary content. The principle of least privilege is violated, and the key becomes effectively public, making the CMEK control meaningless.

• ✓

  Create a bucket IAM policy that denies storage.objects.create without the encryption header matching the CMEK key.

  Why this is correct

  Creating a bucket IAM policy that denies storage.objects.create unless the encryption header matches the CMEK key is correct because it enforces that every new object must be encrypted with the specified Cloud KMS key resource name. You can use an IAM condition (for example, on the storage.objects.create permission) with a condition expression referencing the encryption resource to block uploads that use a different key or no key. This is a strong enforcement mechanism that prevents users from bypassing the intended CMEK by providing their own key or relying on default encryption.

• ✗

  Enable Uniform Bucket-Level Access.

  Why it's wrong here

  Enabling Uniform Bucket-Level Access is incorrect for this requirement because it only disables per-object ACLs and makes all access decisions controlled by IAM at the bucket level. It simplifies access management but does not enforce, require, or restrict encryption with a specific Cloud KMS key. Even with uniform access, objects can be uploaded without CMEK, and the security team's requirement to restrict access via key-based encryption is not addressed by this setting.

• ✓

  Create a Cloud KMS key and set it as the default key on the bucket using --kms-key.

  Why this is correct

  Creating a Cloud KMS key and setting it as the default key on the bucket using the --kms-key flag is correct because it configures the bucket to automatically encrypt newly written objects with the specified customer-managed key. This ensures that any object uploaded without an explicit encryption header is encrypted with that CMEK key, fulfilling the 'default' aspect of the encryption requirement. However, note that this default setting can be overridden by a user who specifies a different encryption key, so it must be combined with an IAM condition to truly enforce the restriction.

Go deeper

Related to this question