Associate Data Practitioner

Identify use cases for customer-managed encryption keys (CMEK), customer-supplied encryption keys (CSEK), and Google-managed encryption keys (GMEK)

Encryption keys are like digital locks for your data. Google Cloud offers three main ways to manage these keys, giving you different levels of control. Google-managed encryption keys (GMEK) are the default and simplest option; Google creates, stores, and rotates the keys automatically. This is a good choice for general use when you want to avoid key management tasks. Customer-managed encryption keys (CMEK) give you more control: you create and manage the keys in Cloud KMS, and Google Cloud services use your keys to encrypt your data. Choose CMEK when you need to meet specific compliance rules, control key rotation schedules, or centrally manage keys across services. Customer-supplied encryption keys (CSEK) provide the highest level of control, where you generate and hold the key yourself and provide it to Google Cloud for each storage operation. Use CSEK when you have strict requirements to never let Google hold your encryption keys, but note that you are fully responsible for securing and backing up the key—if you lose it, you lose access to your data.

Understand the role of Cloud Key Management Service (Cloud KMS) to manage encryption keys

Cloud Key Management Service (Cloud KMS) is a central service for creating, storing, and using encryption keys. It acts as a secure vault and manager for your customer-managed encryption keys (CMEK). You use Cloud KMS to generate new keys, control who can use them through Identity and Access Management (IAM) policies, define automatic rotation schedules, and disable or destroy keys when needed. The service itself is designed to be highly secure and available. When a Google Cloud service like Cloud Storage or BigQuery needs to encrypt data using your CMEK, it sends a request to Cloud KMS. Cloud KMS verifies the request is authorized and then provides the key material for the encryption operation, without exposing the raw key to the service. This separation keeps your keys secure while allowing other services to use them.

Identify the difference between encryption in transit and encryption at rest

Data security involves protecting data in two primary states: when it is stored and when it is moving. Encryption at rest protects data while it is stored on a physical disk, like in Cloud Storage buckets or BigQuery tables. This ensures that if someone gains unauthorized physical access to the storage media, they cannot read the data. In Google Cloud, this encryption is automatic and always on, using either Google-managed or customer-managed keys. Encryption in transit protects data while it is moving across a network, such as when a user sends data to a cloud service or when services communicate with each other. This is typically done using protocols like TLS (Transport Layer Security), which creates a secure, encrypted tunnel for the data to travel through. You need both types: encryption at rest protects your stored archives, and encryption in transit protects data from being intercepted while it travels to and from that storage.