Encryption Use Cases, Object Lifecycle and Confidential Computing

What it is

Data exists in three states, and each needs its own protection. At rest it sits on disk, in transit it moves across a network, and in use it is in memory while being processed. Google encrypts the first two by default; Confidential Computing covers the third.

Lifecycle rules decide how long stored data exists at all, which is also a protection: data that has been deleted cannot leak.

How it works

Applying encryption methods to use cases

Inside Google's network, traffic between Google services is protected with Application Layer Transport Security (ALTS), and traffic from users to Google services terminates TLS at the Google Front End.

Encrypting at the application layer

When only some values need extra protection, encrypt them before storage with a Cloud KMS key. Use envelope encryption: generate a local data key, encrypt the data with it, and store the data key wrapped by Cloud KMS.

gcloud kms encrypt --key=app-key --keyring=app-ring --location=europe-west1 \
  --plaintext-file=card.txt --ciphertext-file=card.enc

Direct KMS encryption suits small values; the Tink library handles envelope encryption for larger data.

Object lifecycle policies for Cloud Storage

Lifecycle rules apply actions to objects when conditions are met.

{
  "lifecycle": {
    "rule": [
      {"action": {"type": "SetStorageClass", "storageClass": "COLDLINE"},
       "condition": {"age": 90, "matchesStorageClass": ["STANDARD"]}},
      {"action": {"type": "Delete"}, "condition": {"age": 365}}
    ]
  }
}

gcloud storage buckets update gs://audit-exports --lifecycle-file=lifecycle.json

Lifecycle deletes data; retention keeps it. A retention policy stops deletion or overwrite until objects reach a minimum age, and Bucket Lock makes that policy permanent. Object holds pause deletion for specific objects, and soft delete keeps deleted objects recoverable for a set period.

Confidential Computing

Confidential Computing encrypts data in memory, with keys generated and held by the CPU, so even the host cannot read it.

gcloud compute instances create secure-vm \
  --zone=europe-west4-a --machine-type=n2d-standard-4 \
  --confidential-compute-type=SEV --maintenance-policy=TERMINATE \
  --shielded-secure-boot --shielded-vtpm

Only some machine series support each technology, so choose the type and region first. The organization policy compute.restrictNonConfidentialComputing can require Confidential VMs for listed services.

Attestation proves to a remote party that a workload runs on genuine confidential hardware with the expected software, and is the basis for releasing keys to it.

A worked example

Two banks want to train a fraud model on their combined transactions without either seeing the other's data. The engineer uses Confidential Space: each bank encrypts its data with its own Cloud KMS key and lets only a workload whose attested image matches the agreed one decrypt it, through a workload identity pool with attestation conditions.

The combined results go to a bucket with a 7-year retention policy, locked, and a lifecycle rule moving objects to Archive after one year.

How the exam asks about this

• "Data must remain encrypted while it is being processed in memory." Confidential VMs or Confidential GKE Nodes.
• "Delete objects automatically 30 days after creation." A lifecycle rule with action Delete and condition age 30.
• "Records must not be deleted or changed for seven years, even by administrators." A retention policy with Bucket Lock.