Task 3.2: Managing encryption at rest, in transit, and in use.

• ACloud EKM keys, with a Key Access Justifications policy on them

  Correct

  With Cloud EKM, key material stays in the external key manager, and Key Access Justifications lets the bank approve or deny each request based on its justification code.

• BCloud HSM keys at the HSM protection level, with a Key Access Justifications policy on them

  Incorrect

  Cloud HSM keys live in Google-operated HSMs, so the key material exists inside Google's infrastructure.

• CSoftware-protected Cloud KMS keys in a dedicated key project

  Incorrect

  Software keys live in Google's infrastructure, which the regulator forbids.

• DCustomer-supplied encryption keys passed with each request to the service

  Incorrect

  Only Cloud Storage and Compute Engine accept CSEK (deprecated for Compute Engine), not BigQuery.

Cloud External Key Manager uses keys that live in a supported external key management partner and are reached over the internet or a VPC network. Key Access Justifications attaches a justification to each request to use such a key, and a policy can approve or deny requests by reason. Cloud HSM and imported keys both keep key material within Google Cloud.

• AApprove it, because rotation re-encrypts existing objects with the new primary version

  Incorrect

  Rotation creates a new version for new encryption only; existing objects stay encrypted with the version that was primary when they were written.

• BApprove it, because a destroyed version can be restored at any time from Cloud KMS backups

  Incorrect

  A version can be restored only while it is scheduled for destruction; once destroyed, the key material is gone for good.

• CKeep the earlier versions enabled until the objects they protect have been rewritten or deleted

  Correct

  Older objects can be decrypted only with the version that encrypted them, so a version must stay enabled until no data depends on it.

• DDisable automatic rotation and rotate by hand so that only one version ever exists

  Incorrect

  Manual rotation also creates new versions, and Google advises against relying on irregular manual rotation.

Rotating a Cloud KMS key creates a new primary key version, but data encrypted with earlier versions is not re-encrypted, and those versions stay active. Destroying a version that still protects data makes that data unrecoverable once the scheduled destruction period ends, so old versions are kept until the data is re-encrypted or deleted.

• AOne shared key ring in the central project, with Cloud KMS Admin granted to each team's Terraform service account

  Incorrect

  Granting Cloud KMS Admin to the teams' pipelines is exactly the privilege the requirement denies them.

• BCloud KMS Autokey enabled on the folder, with dedicated-project key storage in the central key project

  Correct

  Autokey creates key rings and keys on demand in the designated key project when a resource is created and sets up the access the services need, with no elevated roles for developers.

• CThe organization policy that requires CMEK for the three services, with no further setup

  Incorrect

  The constraint rejects resources created without CMEK but does not create any keys, so teams would still need someone to make them.

• DCustomer-supplied encryption keys generated by each Terraform run and stored in its state file

  Incorrect

  BigQuery does not accept CSEK, which only Cloud Storage and Compute Engine support, and keys kept in Terraform state are long-lived secrets in a file.

Cloud KMS Autokey automates CMEK: when a developer or IaC pipeline creates a compatible resource, Autokey creates a Cloud HSM key for it and sets up the permissions needed to use it. With dedicated-project key storage, enabled on a folder, the keys go into one designated key project; the permissions needed to request a key are part of ordinary resource creation roles.

• Agcp.restrictNonCmekServices, with both services' APIs on its deny list

  Correct

  Listing a service in this constraint makes it reject resources created without CMEK.

• Bgcp.resourceLocations, with only the location of kms-central allowed

  Incorrect

  Resource locations limit where resources are created; they say nothing about encryption keys.

• Cstorage.uniformBucketLevelAccess, enforced across the organization

  Incorrect

  Uniform bucket-level access turns off object ACLs; it does not require CMEK.

• Diam.allowedPolicyMemberDomains, with only the company's customer ID

  Incorrect

  Domain restricted sharing controls who can be granted roles, not which keys protect resources.

• Egcp.restrictCmekCryptoKeyProjects, with only kms-central allowed

  Correct

  This constraint limits which projects can supply CMEK keys, so a key from any other project is rejected.

Two organization policy constraints govern CMEK. gcp.restrictNonCmekServices lists services whose new resources must use CMEK, and gcp.restrictCmekCryptoKeyProjects limits the projects, folders or organization whose keys may be used. Together they enforce both that CMEK is used and where the keys come from.

• ACustomer-managed encryption keys for the VM's persistent disks

  Incorrect

  CMEK protects data at rest on the disks, not data in memory while it is processed.

• BShielded VM with Secure Boot and integrity monitoring turned on

  Incorrect

  Shielded VM verifies the boot chain against rootkits; it does not encrypt memory.

• CConfidential Space, running the application as a workload container image

  Incorrect

  That option means repackaging the vendor's application as a container workload, which is ruled out.

• DA Confidential VM

  Correct

  Confidential VM encrypts memory with hardware-based technology such as AMD SEV or Intel TDX, and existing applications run without changes.

Confidential Computing protects data in use. A Confidential VM keeps its memory encrypted with keys managed by the processor, using AMD SEV, AMD SEV-SNP or Intel TDX, so applications need no changes. CMEK covers data at rest and Shielded VM covers boot integrity.

• AChange the existing keys' protection level to HSM in the key settings

  Incorrect

  A key's protection level cannot be changed after the key is created.

• BCreate new keys at the HSM protection level and re-encrypt the data under them

  Correct

  Cloud HSM keys are kept in a cluster of FIPS 140-2 Level 3 certified HSMs; since the level is fixed, new keys are needed and data must be re-encrypted under them.

• CRotate the existing keys, because new versions are always created in hardware

  Incorrect

  New versions inherit the key's protection level, so they stay software keys.

• DKeep the software keys, because Cloud KMS software keys are already validated at Level 3

  Incorrect

  Software keys use a module validated at FIPS 140-3 Level 1, below the rule's level.

Cloud KMS protection levels are SOFTWARE, HSM, EXTERNAL and EXTERNAL_VPC. Software keys use a FIPS 140-3 Level 1 validated module, and Cloud HSM keys live in FIPS 140-2 Level 3 certified HSMs. A key's protection level is set at creation and cannot change, so moving to hardware means new keys and re-encrypting the data.

• ASplit each file into small chunks and send every chunk to the Cloud KMS encrypt method

  Incorrect

  Thousands of KMS calls per file add latency and cost, and Google's pattern for large data is different.

• BExport the key from Cloud KMS once and encrypt the files locally with it

  Incorrect

  Cloud KMS does not let key material be exported, and the master key must stay in it.

• CEncrypt each file locally with a data key, and send only that key to Cloud KMS for wrapping

  Correct

  In envelope encryption the data encryption key encrypts the file, and only the small data key is sent to Cloud KMS to be wrapped.

• DTurn on CMEK for the destination bucket instead of encrypting in the application

  Incorrect

  CMEK encrypts at rest inside the service, which does not meet the need for the application to encrypt files before upload.

Envelope encryption encrypts data with a data encryption key (DEK) and protects the DEK with a key encryption key (KEK) in Cloud KMS. Only the DEK travels to Cloud KMS, so large data can be encrypted locally while the KEK never leaves the service.

• ASet a retention policy of seven years on the bucket

  Correct

  A retention policy stops objects from being deleted or replaced until they reach the retention period.

• BTurn on Object Versioning so that overwritten records keep a noncurrent version

  Incorrect

  Versioning keeps old versions, but versions can still be deleted.

• CAdd a lifecycle rule that deletes objects older than seven years

  Incorrect

  A lifecycle rule removes data after the period; it does nothing to stop early deletion.

• DLock the retention policy

  Correct

  Locking makes the policy permanent: it cannot be removed or shortened.

• EExtend the soft delete retention period to its maximum

  Incorrect

  Soft delete keeps deleted objects for a while, but they can still be deleted and the period is far shorter than seven years.

Bucket Lock combines a bucket retention policy, which prevents deletion or replacement of objects younger than the retention period, with locking that policy, after which it cannot be removed or reduced. Together they give write-once, read-many storage for records rules such as seven-year retention.

• AIn the europe multi-region location of Cloud KMS, matching the dataset

  Correct

  A multi-regional dataset needs a key from the matching multi-regional location, and a dataset in EU must use a key ring in europe.

• BIn the global location, so that the key can serve any dataset

  Incorrect

  BigQuery requires the key location to match the dataset's location; a global key does not match EU.

• CIn europe-west3 again, but with the HSM protection level

  Incorrect

  The protection level is not the problem; the location still does not match the EU multi-region.

• DIn a key ring in each European region, with the dataset using all of them

  Incorrect

  A dataset uses one key, and regional keys do not match a multi-region dataset.

BigQuery checks that a CMEK key's location matches the dataset's location. Regional datasets use keys from the same region, and multi-regional datasets use multi-regional keys: datasets in US use key rings in us, and datasets in EU use key rings in europe.