Encryption and Key Management

All data stored on Google Cloud is encrypted at rest automatically, with keys the provider manages. This happens whether or not you configure anything, and it requires no action from you.

Key management services exist for the cases where default encryption is not sufficient — usually because a regulation, a contract or an internal policy requires that your organisation controls the key rather than the provider.

Controlling the key gives you a control that permissions alone do not: the ability to make data unreadable everywhere at once by disabling or destroying the key. That is a meaningful guarantee for regulated data and for offboarding.

It also carries real risk. If you destroy a key, the data encrypted with it is unrecoverable — including your backups. Taking control of keys means taking responsibility for a new category of outage, and exams test whether you understand that trade-off rather than treating customer-managed keys as strictly better.

• Key ring — a container grouping keys in a location. Keys cannot be moved between rings or regions afterwards.
• Key version — keys have versions; rotation creates a new version for encrypting new data while old versions remain available to decrypt existing data.
• Rotation — replacing the active key version on a schedule, limiting how much data any single version protects.
• Destruction and scheduled deletion — destroying a version is deliberately delayed, giving a window to recover from a mistake.
• Envelope encryption — data is encrypted with a data key, and that data key is itself encrypted by the key management key. This is what makes rotation efficient at scale.
• Separation of duties — the identity administering keys should be distinct from the identity administering the data. This is a control the exams expect you to apply.
• Encryption in transit — separate from all of the above and applied automatically to traffic across the provider's network and to its APIs.

Key management protects data at rest. Secret management handles the credentials your application needs at runtime — API tokens, database passwords, third-party keys. These are related but distinct problems and the exams keep them distinct.

• Store secrets in a dedicated secret management service, never in source control, container images or environment variables baked into a build.
• Grant access to a specific secret version using IAM, so each workload reads only what it needs.
• Version secrets so rotation can happen without a simultaneous change across every consumer.
• Have the application fetch secrets at startup or on demand rather than receiving them through the deployment pipeline.
• Audit access — knowing which identity read which secret and when is often a compliance requirement.

• Encrypting a storage bucket or database with a customer-managed key to satisfy a regulatory requirement.
• Rotating keys automatically on a schedule to limit exposure from any single version.
• Revoking access to a dataset organisation-wide by disabling the key protecting it.
• Keeping key administration in a separate project managed by a security team.
• Storing database credentials in a secret manager and granting access only to the service that needs them.